🚀 go-pugleaf

Dzięki za informację (serdeczne)

----
pozdrawiam
   Paweł Rzoska 
   Polmos Toruń S.A.
   przos@polmos.torun.pl 
   www.polmos.torun.pl 
    Maciej Denisiuk napisał(a) w wiadomości: <7eerdl$7mj$1@newsfeed.onet.pl>...
    Stanowczo ODRADZAM.
    Nie mam Pervasive SQL - 7 używam tylko Paradoxa i MSSQL ale to nie zmienia kontekstu, że InfoPower jest do D..Y.
    Pisze tak ostro bo 5 miesięcy temu zakupiłem tę bibliotekę - nie bez problemów i z tygodniowym namawianiem mojego szefa. Całe szczęście, że nie były to moje prywatne pieniądze.
    
    Kupiliśmy to praktycznie dla jednego komponentu: TwwFilterDialog. Dostaliśmy właśnie zlecenie od klienta z wygórowanymi potrzebami wyszukiwania danych więc ten komponent zaspakajał w całości nasze potrzeby. Nie bawiliśmy się trialem bo nie było wtedy wersji dla Delphi 4 - i to był nasz błąd. Zaufaliśmy reklamie - dobrze by było posiadać "najlepszą", "profesjonalną", "komercyjną" bibliotekę do baz danych, wygrywającą wszystkie rankingi. Produkt znaliśmy po doskonałych recenzjach (dosłownie: "co warto zabrać na bezludną wyspę - InfoPowera") w Delphi Informancie.
    
    Konkretne zarzuty:
        a.. zamkniętość biblioteki
        "Dla zwiększenia niezawodność w wersji 4.0 wprowadziliśmy możliwość współpracy naszych komponentów edycyjnych wyłącznie z naszym wspaniałym TwwTable i TwwQuery". InfoPower i tylko InfoPower. Zupełnie odmienne podejście od np. TurboPowera autora Orpheusa czy SysToolsa. Z dobrodziejstw TwwTable nie da się zrezygnować. Całość komponentów jest mocno ze sobą zintegrowania i przez to praktycznie wyklucza się współużytkowanie innych bibliotek. W naszym przypadku konkretny problem: TRxQuery ze wspaniałymi  Makrosami czy TwwQuery bo konieczne do kontrolek edycyjnych? Całe szczęście, że 3 komponenty są wyłączone z tego ogólnego "dobrodziejstwa", między nimi i nasz TwwFilterDialog.
        a.. "cudowne" rozwiązanie: UseTFields i ControlInfoInDataSet
        W czystym Delphi definicje pól są przechowywane w TTable  i redagowane poprzez Fields Editor. Kontrolki bazodanowe przyjmują te definicje i rozszerzają o własne ustawienia (typowo TDBGrid może mieć własne definicje kolumn lub odczytuje z te z tabeli). Nikt jednak nie wpadła na tak rewolucyjny pomysł by definicje rozszerzające poszczególnych kontrolek (property Selected) przechowywać  w źródle danych. To po to by wprowadzić standard do okienek edytujących to samo źródło danych (TDataSet). Mam okienko grida ( oczywiście TwwDBGrida) i ustawiam które pola mają się pokazywać i jak a zmiany interferują automatycznie z ustawieniami w okienku edycyjnym. Pomysł może i nie głupi ale żeby od razu Delaultowo uznawać go za genialny. Z tym jest więcej kłopotu niż praktycznego pożytku. Trudno opisać dlaczego to rozwiązanie jest spaprane. Trzeba trochę z nim popracować zwłaszcza na etapie opracowywania aplikacji by uznać że jest to funkcja jak najbardziej szkodliwa, przeszkadzająca i niezgodna z kilkuletnimi przyzwyczajeniami w posługiwaniu się Delphi. Ogólnie musiałem o tej "cudowności" zapomnieć bo znudziły mnie telefony do mojego wspólnika z pytaniem "Czy masz dziś dobry humor? Bo trzeba coś przerobić w okienkach edycyjnych a nie chcę abyś zaczynał dzień od przekleństw, że po otwarciu tabeli znowu nie widać żadnych pól.".
        a.. TwwRecordViewPanel tylko na pierwsze spotkanie i wielowarstwowość - a po co?
        TwwRecordViewPanel wspaniale pomaga opracować okienka edycyjne na pierwszą prezentację programu. Niestety tylko na pierwszą. Gdy klient poprosi o możliwość wybierania standardowych wartości ze zdefiniowanego słownika należy usiąść do pracy i standardowo zaprojektować okienko edycyjne. Jeśli ktoś pójdzie na łatwiznę i pokusi się o dołączenie combobox itp. do TwwRecordViewPanelu to popełni ten sam błąd co my. Poprawnego, ręcznego projektowania okienka edycyjnego i tak nie da się uniknąć a przynajmniej od samego początku można trzymać się rozdzielania danych (na TDataModule) od ich edycji. Niestety dla Woll2Woll architektury wielowarstwowe to anachronizm lub wydumane teorie przemądrzałych filozofów. Przecież my dajemy takie wspaniałe automatyczne narzędzie dzięki któremu nie trzeba (czytaj: nie można) korzystać z chociażby TDataModule. Po co się męczyć, komplikować sobie życie - najlepiej tworzyć automatyczne okienka od razu z potrzebnymi tabelami. Bibliotekę otrzymałem akurat po powrocie z ostatniego szkolenia z SELECT Enterprise (narzędzie do budowania dużych aplikacji) i nijak nie mogłem wdrożyć świeżo nabytych teorii w praktykę. Pewnie namieszali mi w głowie. Ale jakoś bardziej ufam tym od Selecta niż autorom InfoPowera.
        a.. zawsze TDataSource? - niekoniecznie
        W czystym Delphi oczywiście zawsze kontrolki bazodanowe łączy się ze zbiorami danych poprzez TDataSource. Ale w InfoPowerze nie musisz się tym przejmować. My dajemy tak wspaniałe narzędzia jak np. TwwDBLookupCombo i łącząc się z LookupTable nie musisz używać jakiegoś kolejnego, zbędnego TDataSource. Wystarczy bezpośrednie odwołanie do TTable (o sorry - oczywiście chodziło o TwwTable). Tak genialne bo proste. Wręcz prostackie. Tu już moim zdaniem przegięli. "Profesjonalna biblioteka" nie rozumie potrzeby używania TDataSource. No cóż wzorzec projektowy: Obserwator to też wymysł tych przemądrzałych teoretyków. Całe szczęście, że przynajmniej Ci z Borlanda o nim słyszeli.
        a.. TwwDBLookupCombo jest prawie dobry
        Nie pamiętając o tym co napisałem powyżej można go z całą pewnością polecić jako panaceum na potrzeby MACIASA w tym względzie przedstawione parę tygodni temu jeszcze na starym pl.comp.lang.delphi. Umie prawie wszystko co Mu się wymarzyło tylko z tej mądrości źle się rozwija. To znaczy on może i robi to po swojemu dobrze tylko mu tak przy okazji brzydko wychodzi, że najpierw rozwija się na np. 8 pozycji do wyświetlenia a potem zwija do 4 bo tylko tyle na razie występuje w LookupTable. No ale "profesjonalnej bibliotece" można taki niedociągnięcia wybaczyć.  Z przyczyn opisanych wcześniej zaprzestałem już rozgryzania tego produktu ale jakoś tak podejrzewam, że wywołany do tablicy nie miałbym problemów z odnalezieniem kolejnego bugu.
        a.. nabywca otrzymuje świeżutkie źródła
        Poprawienie tej uciążliwości TwwDBLookupCombo nie nastręczało dużo problemów. Ale przy okazji przyjrzeliśmy się trochę źródełko które otrzymaliśmy nabywając wersję Proffesional. Rozumiem, że "profesjonalna biblioteka" ma wielu użytkowników, którzy niecierpliwie wyczekują kolejnych jej wersji i upgradów. Ale to chyba nie tłumaczy faktu że źródła są  świeżutkie jakby dopiero co wyszły od ostatnich testerów. Pełno tu zaremowanych linii, które bynajmniej nie są komentarzami tylko zaremowanymi poprawnymi składniowo instrukcjami które miały w zamyśle autorów coś wykonywać ale do końca nie działały Ok. Niestety poza wrażeniami bałaganu i niechlujstwa rodzi to obawy, że biblioteka była tworzona za szybko a innowacje wprowadzane doraźnie. Ciekawe jakie jeszcze perełki odkryją rzesze użytkowników tego knota i czy czasem upgrady nie będą zaleceniami typu: "odremuj sobie linię .. w pliku ...".
        a.. Delphi 4 to taki Delphi 3 tyle że nowszy
        InfoPower w wersji 4.0 instaluje się zarówno w Delphi 3 jak i 4. W związku z tym nie zauważa nowych natywnych cech Delphi 4 takich jak dokowanie czy ActionList. To mało istotne innowacje. Kto tego używa? Po co to wspierać? No ale na tym polu Woll2Woll nie jest osamotniony. TurboPower jest równie kompatybilny wstecz, że najnowszy długo oczekiwany Orpheus 3 też nie wie co to są Actions. Aż żal człowieka  ściska. To tak jakby do komputera z Windows 98 można było zakupić tylko monitor monochromatyczny bo te gradientalne paski tytułowe to tylko taki bajer.
        a.. własny, lepszy TwwDBGrid
        Oczywiście współpracuje wyłącznie z TwwTable itd. Znowu: nasz grid umie wszystko, ale po swojemu. Po prostu nie dziedziczy z TCustomDBGrid. Ale przecież chłopaki potrafią "lepiej", "inaczej".
        a.. nawet help mamy własny
        Tak Help też jest własny. Instaluje się w menu IDE Delphi 4 przed standardowym Helpem, przy okazji psując indeks tamtego. A we własnym helpie nie musimy pokazywać poszczególnych property naszych wspaniałych komponentów w kolejności alfabetycznej. A po co to użytkownikowi przecież i tak bardzo sporadycznie korzysta z helpu bo nasze narzędzia są przecież tak nieskomplikowane i wszystko robią za niego automatycznie.
    Kończąc już - krótkie podsumowanie: 
    Wspaniałe narzędzie dla początkujących i tych zaczynających dopiero używania Delphi. Starsi stażem i doświadczeniem nie potrafią niestety docenić prostoty, innowacyjności  i zautomatyzowania komponentów biblioteki InfoPower. A programy trzeba robić łatwo, szybko i automatycznie. I to nam zapewnia InfoPower. Wszystko w jednym. Tylko wash and go. 
    Osobiście nie mogę się przyczepić tylko do jednego komponentu: TwwIntl. Totalna internacjonalizacja napisów w bibliotece. Takie rozwiązanie przydałoby się w np. Orpheuszu.
    
    Jeśli nadal czujesz się nieprzekonany do niekupowania InfoPowera to chętnie odstąpimy go na coś niekoniecznie zajmującego szczyty list rankingów w delphiowych czasopismach.
    
    -- 
     Przyjemności
     Maciej Denisiuk
    
    PS. 
    Pisze w HTMLu bo jeśli kogoś interesuje specjalistyczna biblioteka za 299$ to zapewne stać go na w miarę świeżego newsreadera obsługującego HTML.
    
    Paweł Rzoska napisał(a) w wiadomości: <7e1nl3$cd2$1@flis.man.torun.pl>...
    |Czy warto InfoPowera kupić i jakie są jego najwazniejsze wady. Testuje