Naprawdę? Ile Ty masz lat, że wierzysz we wszystko co na konferencjach mówi producent? A co ma powiedzieć, że nie działa?
Dam przykład (kto był w tym roku w Rawie Mazowieckiej, ten może pamięta); Moskwa opowiadał o FMX, w pewnym momencie wspominał o klasie TLocation (tak to się chyba nazywa, chodzi o obsługę GPSa w urządzeniach) i mówi, że to generalnie nie zawsze działa. Na dodatek potrafi zawiesić urządzenie. Mina przedstawicieli producenta - bezcenna, zwłaszcza jak głosy na sali potwierdzają - "tak ja też spotkałem się z tym problemem"....
OK, pokazywali na FMX i działało normalnie. Tyle, że to były dość proste rzeczy.
Własnie, proste. Jak prototyp. Tylko ma to służyć nie tylko do prototypowania...
Nie wierzysz, to proszę tutorial:
http://docwiki.embarcadero.com/RADStudio/Berlin/en/Programatically_Binding_Created_Objects
I pierwsze zdanie:
"Caution: The programmatic method described here is NOT the standard way to implement binding expressions."
No nie jest to miłe, ale nie jest też wyjątkiem. Przykładu nie trzeba szukać daleko. MFC i ręczna edycja plików RC. Da się? Jasne. Ale jak potem zrobisz coś w designerze (chociażby przesunięcie kontrolki o 1 piksel), to Ci rozwali wszystkie Twoje zmiany i tak naprawdę nie wiadomo, co zostanie.
OK, ale tego nie da się porównywać. To zdecydowanie nie ten ciężar gatunkowy, bo dlaczego niby biblioteka realizująca binding ma być używana tylko przez klikane wizualne edytory?
Pewnie, można powiedzieć - przecież to nic i czepiam się. Można. Tylko dla mnie programowanie to nie zabawa, tylko podstawa egzystencji.
Myślę, że jak dla większości ludzi tutaj :)
A więc jak mi producent pisze, że to da się ale de-facto jest to hack, to ja się zaczynam poważnie zastanawiać, od której wersji się nie da.
Bo tak, przecież ostrzegali...
Tak, jak mówię. To nie jest kwestia jedynie Delphi. Takie rzeczy ("da się, ale nie jest to zalecane w taki sposób") są w wielu językach. Pisałem wyżej o C++ i MFC, są też podobne cuda w C#.
Ale to są rzeczy ciągnięte, jak sam zauważyłeś, od wielu lat. I teraz byłoby lekkim strzałem w kolano np. usunięcie funkcji format. Chociaż mogliby utworzyć np. klasę String.
Mówiłeś, że w której wersji piszesz? Ostatnio na XE5, dobrze pamiętam?
Musze Cię zmartwić, nie znasz narzędzia którego używasz, ponieważ jest to od wersji XE3.
Co jest od wersji XE3? Format w postaci metody? Możliwe, że nie znam XE5, bo ostatnio pisałem w Delphi jakieś 2, 3 lata temu i to dość krótko w XE5 :)
Class Helper dla typów prostych. Mam nadzieję, że wiesz co to jest class helper (w Delphi od wersji 2006)?
I nie, nie jest tak że String jest klasą (to by był dopiero hardcore - tworzyć i zwalniać każdego stringa :D), ale jest tak, że dla typów prostych można utworzyć class helper.
No zgoda, ale nigdzie nie pisałem, że string jest klasą.
Nigdzie nie napisałem, że tak napisałeś.
Niemniej jednak do takiego miana pretenduje przynajmniej od wersji XE2, gdzie stringi zaczęły być (możliwe, że wcześniej) bardziej skomplikowaną strukturą w pamięci niż do tej pory. Doszło kodowanie, reference counting i kilka innych rzeczy.
Sprostowanie; RefCounting dla stringów (i nie tylko dla nich) jest w Delphi od zawsze. Kodowanie jest od bardzo dawna, tylko intysywnie wykorzystywane od wersji 2009. Ale wczesniej tez było obsługiwane.
Inne rzeczy są widoczne dla stringa, ale to nie jest nierozerwalna część stringa, zrobione jest to nieco inaczej. Właśnie przez class helper dla typów prostych.
BTW - wiedziałeś, że od wersji XE3 w Delphi jest zero-based-string? Domyślnie OFF :D
Nie wiedziałem, ale gdyby to było włączone domyślnie, to dopiero apki by się zaczęły sypać :)
Poza tym porządny wsparcie dla porządnego namespace bardzo by pomógł, a nie takie nie wiadomo co to jest, co jest.
Prawda jest taka, że rozwój samego języka i RTLa napędza FMX, ponieważ kod wieloplatformowy to naprawdę poważny problem do rozwiązania.
No i pchają tego FMX na siłę... Zastanawiam się tylko kiedy to zdechnie na amen :D
Tu mamy podobne podejście :)
Po prostu dostarczenie do obiektu poprawnych danych. Co do przeliczania w DataSet. Jeśli to jest mało skomplikowane (załóżmy dosłownie kilka warunków), to można to zrobić bezpośrednio w zdarzeniu. Natomiast, jeśli jest coś bardziej skomplikowanego, to nikt Ci nie broni napisać sobie odpowiednich klas do tego z całą hierarchią dziedziczenia i w ogóle. Wszystko może sprowadzić się do wywołania w zdarzeniu jednej metody, obiektu który to wszystko ogarnie.
I to jest właśnie Delphiowe podejście... raz tak, a raz siak. To jest drogi Kolego bardzo zły nawyk.
I tak, i nie. To zależy głównie od sytuacji. Jeśli masz do zwalidowania jedną zmienną, to nie będziesz tworzył do tego jakiegoś jebitnego mechanizmu, bo nie ma to sensu. Więcej czasu stracisz na tym, niż co warte. Ale, gdy takich rzeczy zaczyna dochodzić, wtedy trzeba przemyśleć lekkie przeprojektowanie. Ale to nie jest kwestia języka, tylko indywidualnego podejścia do projektu, jego wymagań, założeń itd. Przecież w C# też możesz takie rzeczy robić w zdarzeniu na formie. Nikt Ci tego nie broni.
Jasne, to nie jest problem Delphi tylko programowania w ogóle - jak coś robić, a jak nie i dlaczego nie.
No też właśnie :)
Kopiuj
try
conn.BeginTransaction;
if dsMaster.State in dsEditStates then
dsMaster.Post;
if dsDetail.State in dsEditStates then
dsDetail.Post;
conn.Commit;
except
conn.Rollback;
raise;
end;
I powtarzamy taką wyliczankę na każdym okienku liczonym w setkach.
Wypas :)
No tu jest już kwestia programisty i architektury systemu. To nie jest kwestia języka.
No to pytam, jak to robisz jako programista?
Bo Delphi nie daje żadnego wzorca, wsparcia, techniki, whatever na pokładzie do tego. A szkoda.
Wyobraź sobie, że masz główny obiekt w Twoim systemie i zaistniała potrzeba dodawania nowego atrybutu (niech będzie, że to pole w tabeli).
Banał prawda? Prawda.
A teraz ten obiekt jest wykorzystywany na 20 albo i 100 formatkach i na każdej z nich ma być dodane to nowe pole + dodatkowa logika zależna od wartości tego pola, która ingeruje w logikę na innych formatkach.
No to mamy bagno...
Zrobienie tego jest proste, ale cholernie żmudne i na pewno urodzą się nowe błędy.
Tak, dlatego możesz dziedziczyć formularze przecież.
Mogę. A potem muszę cierpieć przez to dziedziczenie, kiedy trzeba podejść do tego elastycznie.
OK, to nie wina Delphi ;-) Chodzi mi o to, że to wcale nie jest takie dobre rozwiązanie jak się wydaje. Słabości tej techniki wychodzą przy dużych projektach z dużą dynamiką "customizacji" i małym zespołem.
Poza tym nie musisz tego robić na każdej formie. Możesz mieć frame, możesz mieć dodatkową formę, którą kładziesz na panelu na innej formie. I tak naprawdę robisz to TYLKO w jednym miejscu.
Problem zaczyna się wtedy, kiedy ten frame działa ciut inaczej od kontekstu. Poza tym ramki?
Nie cierpię ramek (przecież to nawet nie ma zdarzenia OnCreate) kolejne narzędzie dla klepacza :D, zdecydowanie lepszym rozwiązaniem są dokowane okna na kontenerze. A kontenerem może być cokolwiek (okno, panel, PageControl (który z automatu tworzy zakładkę dla dokowanego obiektu)), itd.
A nie lepiej by było dodać ten atrybutu do modelu danych + dopisać te kilka linii kodu do logiki i koniec?
Reszta, włącznie z rozbudową wszystkich formatek, robi się sama.
No i właśnie tak można zrobić, robiąc jak napisałem powyżej.
Tak jak napisałeś powyżej to jest żadne rozwiązanie. To jest kolejny drut, do zrobienia na szybko by działało.
Wydaje się wygodne i fajne, do momentu jak trzeba to utrzymywać przy skomplikowanej customizacji...
Raczej typowe. Natomiast ja jestem absolutnie przeciwny takiemu postępowaniu.
Wolę kod, ponieważ wszystko widzę w jednym miejscu. Zmieniam w jednym miejscu i działa.
Tak jest prościej i bezpieczniej.
Ale nie zawsze tak robiłem, kiedyś tez uważałem to za swego rodzaju fanaberię; do czasu...
Ale nikt Ci tego nie broni. Możesz poustawiać w kodzie WSZYSTKIE właściwości. Tylko po co? Nie ma to sensu.
Nie, nie jest to bez sensu - to zdecydowanie ma sens.
Po to wymyślono konwencje, aby nie trzeba było się za każdym razem zastanawiać jak to działa, tylko używać poprawnie i zgodnie z konwencją.
Naprawdę chciałbym je zobaczyć, jakiego miałbyś pomysła na rozwiązanie pewnych kwestii. To byłoby szalenie ciekawe :)
Z dodaniem nowego pola już Ci napisałem wyżej. Podejrzewam, że z każdym Twoim problemem (a przynajmniej z większością) można się uporać. Natomiast widzę, że problemy o których piszesz nie dotyczą w ogóle problemów środowiska (poza rzeczami w stylu: "ręcznie lepiej tego nie robić", bo z tym nie ma co dyskutować), tylko problemów z architekturą systemu, który tworzysz.
Problem polega na tym, że ja nie mam problemów z architekturą, tylko z Delphi które mnie ogranicza. Z ograniczeniami da się żyć, to normalka. Ale z krytycznymi błędami tam gdzie powinno to działać, to już nie.
A co jak robię to możesz poczytać sobie w tym wątku, jak masz ochotę:
http://4programmers.net/Forum/1253574
