🚀 go-pugleaf

Teoretycznie w modelu mógłbym zarejestrować obserwatora i wiedziałbym 
kiedy zmienia się model.
Ale jak połączyć taki TEdit z modelem?

W dniu 2017-09-28 o 12:21, konsul41@wp.pl pisze:
> Teoretycznie w modelu mógłbym zarejestrować obserwatora i wiedziałbym 
> kiedy zmienia się model.
Możesz, ale po co?

> Ale jak połączyć taki TEdit z modelem?
Dlaczego nie użyjesz LiveBindings?

-- 
wloochacz

W dniu 28-09-2017 o 13:46, wloochacz pisze:
> W dniu 2017-09-28 o 12:21, konsul41@wp.pl pisze:
>> Teoretycznie w modelu mógłbym zarejestrować obserwatora i wiedziałbym
>> kiedy zmienia się model.
> Możesz, ale po co?
>
>> Ale jak połączyć taki TEdit z modelem?
> Dlaczego nie użyjesz LiveBindings?
>

A czy TBindSourceAdapter nie jest dostępny dopiero w XE3?

W dniu 2017-09-28 o 14:38, konsul41@wp.pl pisze:
> W dniu 28-09-2017 o 13:46, wloochacz pisze:
>> W dniu 2017-09-28 o 12:21, konsul41@wp.pl pisze:
>>> Teoretycznie w modelu mógłbym zarejestrować obserwatora i wiedziałbym
>>> kiedy zmienia się model.
>> Możesz, ale po co?
>>
>>> Ale jak połączyć taki TEdit z modelem?
>> Dlaczego nie użyjesz LiveBindings?
>>
> 
> A czy TBindSourceAdapter nie jest dostępny dopiero w XE3?
Jest, ale co to ma do rzeczy?
Jak chcesz klikać, to kup nowsze Delphi.
Jak chcesz kodować, to wystarczy XE2.

A nawet XE, ale wtedy trzeba użyć np. tego:
https://bitbucket.org/sglienke/dsharp

-- 
wloochacz

W dniu 28-09-2017 o 14:50, wloochacz pisze:
> W dniu 2017-09-28 o 14:38, konsul41@wp.pl pisze:
>> W dniu 28-09-2017 o 13:46, wloochacz pisze:
>>> W dniu 2017-09-28 o 12:21, konsul41@wp.pl pisze:
>>>> Teoretycznie w modelu mógłbym zarejestrować obserwatora i wiedziałbym
>>>> kiedy zmienia się model.
>>> Możesz, ale po co?
>>>
>>>> Ale jak połączyć taki TEdit z modelem?
>>> Dlaczego nie użyjesz LiveBindings?
>>>
>>
>> A czy TBindSourceAdapter nie jest dostępny dopiero w XE3?
> Jest, ale co to ma do rzeczy?
> Jak chcesz klikać, to kup nowsze Delphi.
> Jak chcesz kodować, to wystarczy XE2.
>
> A nawet XE, ale wtedy trzeba użyć np. tego:
> https://bitbucket.org/sglienke/dsharp
>
wymaga springa
czy chodzi o tego https://bitbucket.org/sglienke/spring4d

On Thu, 28 Sep 2017 15:12:35 +0200, konsul41@wp.pl wrote:

>> A nawet XE, ale wtedy trzeba użyć np. tego:
>> https://bitbucket.org/sglienke/dsharp
>>
> wymaga springa
> czy chodzi o tego https://bitbucket.org/sglienke/spring4d

Tak, nie ma innego Springa dla Delphi.

-- 
pozdrawiam
Roman Tyczka

W dniu 28-09-2017 o 13:46, wloochacz pisze:
> W dniu 2017-09-28 o 12:21, konsul41@wp.pl pisze:
>> Teoretycznie w modelu mógłbym zarejestrować obserwatora i wiedziałbym 
>> kiedy zmienia się model.
> Możesz, ale po co?
> 
>> Ale jak połączyć taki TEdit z modelem?
> Dlaczego nie użyjesz LiveBindings?
> 
Testuje.

Jak w sposób alternatywny można to zrobić?

>> A czy TBindSourceAdapter nie jest dostępny dopiero w XE3?
> Jest, ale co to ma do rzeczy?
> Jak chcesz klikać, to kup nowsze Delphi.
> Jak chcesz kodować, to wystarczy XE2.
> 
> A nawet XE, ale wtedy trzeba użyć np. tego:
> https://bitbucket.org/sglienke/dsharp
> 

A czy nie jest on tylko dla VCL?
przerabiam sample i problemem jest unit DSharp.Bindings.VCLControls nie 
ma dla FireMonkey.
Na formie Firemonkey jest AccesViolation, a na VCL działa.

W dniu 28-09-2017 o 14:50, wloochacz pisze:
> W dniu 2017-09-28 o 14:38, konsul41@wp.pl pisze:
>> W dniu 28-09-2017 o 13:46, wloochacz pisze:
>>> W dniu 2017-09-28 o 12:21, konsul41@wp.pl pisze:
>>>> Teoretycznie w modelu mógłbym zarejestrować obserwatora i wiedziałbym
>>>> kiedy zmienia się model.
>>> Możesz, ale po co?
>>>
>>>> Ale jak połączyć taki TEdit z modelem?
>>> Dlaczego nie użyjesz LiveBindings?
>>>
>>
>> A czy TBindSourceAdapter nie jest dostępny dopiero w XE3?
> Jest, ale co to ma do rzeczy?
> Jak chcesz klikać, to kup nowsze Delphi.
> Jak chcesz kodować, to wystarczy XE2.
> 
> A nawet XE, ale wtedy trzeba użyć np. tego:
> https://bitbucket.org/sglienke/dsharp
> 
A co sądzisz o tym?
http://www.danieleteti.it/net-databinding-in-delphi-for-win32/

mniejsze.

> A co sądzisz o tym?
> http://www.danieleteti.it/net-databinding-in-delphi-for-win32/
> 
> mniejsze.
Ślepa uliczka tylko w jedną stronę.

On Fri, 29 Sep 2017 11:34:30 +0200, konsul41@wp.pl wrote:

>> A co sądzisz o tym?
>> http://www.danieleteti.it/net-databinding-in-delphi-for-win32/
>> 
>> mniejsze.
> Ślepa uliczka tylko w jedną stronę.

Teraz odkryj Columbusa tegoż samego autora :-)

-- 
pozdrawiam
Roman Tyczka

W dniu 29-09-2017 o 08:00, konsul41@wp.pl pisze:
> W dniu 28-09-2017 o 13:46, wloochacz pisze:
>> W dniu 2017-09-28 o 12:21, konsul41@wp.pl pisze:
>>> Teoretycznie w modelu mógłbym zarejestrować obserwatora i wiedziałbym
>>> kiedy zmienia się model.
>> Możesz, ale po co?
>>
>>> Ale jak połączyć taki TEdit z modelem?
>> Dlaczego nie użyjesz LiveBindings?
>>
> Testuje.
>
> Jak w sposób alternatywny można to zrobić?
Myślałem że w moim obiekcie zrobić obserwatora, a np TEdit podpiąć się 
pod OnChange .

W dniu 29-09-2017 o 12:13, Roman Tyczka pisze:
> On Fri, 29 Sep 2017 11:34:30 +0200, konsul41@wp.pl wrote:
>
>>> A co sądzisz o tym?
>>> http://www.danieleteti.it/net-databinding-in-delphi-for-win32/
>>>
>>> mniejsze.
>> Ślepa uliczka tylko w jedną stronę.
>
> Teraz odkryj Columbusa tegoż samego autora :-)
>
Moja wypowiedź oznacza ślepą uliczkę dla mnie.
Ponieważ dane są pobierane z mojego obiektu i pokazywane.
Brak połączenia w drugą stronę.
Moja wypowiedź w żaden sposób nie dotyczyła autora kodu ani samego kodu.

On Fri, 29 Sep 2017 12:57:32 +0200, konsul41@wp.pl wrote:

>>>> A co sądzisz o tym?
>>>> http://www.danieleteti.it/net-databinding-in-delphi-for-win32/
>>>>
>>>> mniejsze.
>>> Ślepa uliczka tylko w jedną stronę.
>>
>> Teraz odkryj Columbusa tegoż samego autora :-)
>>
> Moja wypowiedź oznacza ślepą uliczkę dla mnie.
> Ponieważ dane są pobierane z mojego obiektu i pokazywane.
> Brak połączenia w drugą stronę.
> Moja wypowiedź w żaden sposób nie dotyczyła autora kodu ani samego kodu.

No i co z tego, że Twoja nie dotyczyła? 
Moja dotyczyła, chyba jasno napisałem.
Szukasz rozwiązania i pewnie trafisz także na Columbusa, więc wyprzedziłem
fakty. 

-- 
pozdrawiam
Roman Tyczka

W dniu 28.09.2017 o 11:51, konsul41@wp.pl pisze:
> Interesuje mnie jak w Delphi wykonuje się MVC
> 

Wszystko zależy co potrzebujesz. Gotowego Fremworka bazującego na MVC ci 
nie podsune w Delphi ale powiem swoje spostrzeżenia nt MVC

Teoria mówi by wszystkie trzy elementy były ze sobą luzno powiązane - 
znaczy to tyle że w teorii każdy z tych elementów powinien być wymienny

To napewno znasz - ale teraz musisz zdać sobie sprawę co ci tak naprawdę 
jest potrzebne - gdzie zaczyna się tak naprawdę Model - Widok - Kontroler

> 
> 
> Mam model który ma takie właściwości i jest fakturą.
> 
> property dok_id: Integer read Getdok_id write Setdok_id;
>      property OkresKsiegowy: TOKres read GetOkresKsiegowy write 
> SetOkresKsiegowy;
>      property NazwaDziennika: string read GetNazwaDziennika write 
> SetNazwaDziennika;
>      property NumerDziennika: Integer read GetNumerDziennika write 
> SetNumerDziennika;
>      property NumerDokumentu: string read GetNumerDokumentu write 
> SetNumerDokumentu;
>      property DataRej: TDate read GetDataRej write SetDataRej;
>      property DataDok: TDate read GetDataDok write SetDataDok;
>      property DataPodatkowa: TDate read GetDataPodatkowa write 
> SetDataPodatkowa;
> 
> Jak teraz do niego dorobić pozostałe dwie części
> Kontroler i Widok.
> 

Bazując na podanej klasie sprawa jest prosta w kontroler wsadzasz 
wszystkie operacje jakie możesz wykonać na tej fakturze i tyle

Ja jak pisałem jeszcze w Delphi stworzyłem sobie komponent do Faktur 
gdzie opierał on się o MVC tylko ja to miałem podzielone troszkę wyżej 
nuż ty tutaj próbujesz zrobić u mnie modelem było wszystko to co było 
związane z bazą danych - kontroler był też dość rozbudowany bo posiadał 
i zarządzanie bazą (wszystkie operacje wykonywane na bazie itp nawet 
formatki niektóre tak by łatwo wymieniać pewną funkcjonalności) a jako 
widok obrałem sobie poszczególne wzory faktur.

Z tego co napisałem wyżej były jeszcze wydzielone pakiety odpowiedzialne 
m,in za działanie na poszczególnych silnikach bazodanowych

Podsumowując nie traktuj MVC jako 1:1 czyli jedna klasa to pojedynczy 
element problemu. Głownym zadaniem MVC jest podzielenie tego na 
odpowiednie elementy

możesz oczywiście podchodzić tak ze jedna klasa jedna czynność z MVC ale 
wtedy się łatwo po gubić

We wspomnianym komponencie do fakturowania miałem w ten sposób łatwą 
możliwość wymiany wzorów dokumentów oraz silników baz danych wszystko 
sprowadzało się do tego że kładłem wybrane elementy na formę.
Bez skrobania jakiegokolwiek kodu

Pozdrawiam

> Bazując na podanej klasie sprawa jest prosta w kontroler wsadzasz 
> wszystkie operacje jakie możesz wykonać na tej fakturze i tyle
> 
> Ja jak pisałem jeszcze w Delphi stworzyłem sobie komponent do Faktur 
> gdzie opierał on się o MVC tylko ja to miałem podzielone troszkę wyżej 
> nuż ty tutaj próbujesz zrobić u mnie modelem było wszystko to co było 
> związane z bazą danych - kontroler był też dość rozbudowany bo posiadał 
> i zarządzanie bazą (wszystkie operacje wykonywane na bazie itp nawet 
> formatki niektóre tak by łatwo wymieniać pewną funkcjonalności) a jako 
> widok obrałem sobie poszczególne wzory faktur.
Tylko u mnie model nie wie nic o sposobie utrwalania (baza danych) od 
tego jest repozytorium. W modelu nie ma ani jednej linijki SQL.

W dniu 02.10.2017 o 08:05, konsul41@wp.pl pisze:
> 
>> Bazując na podanej klasie sprawa jest prosta w kontroler wsadzasz 
>> wszystkie operacje jakie możesz wykonać na tej fakturze i tyle
>>
>> Ja jak pisałem jeszcze w Delphi stworzyłem sobie komponent do Faktur 
>> gdzie opierał on się o MVC tylko ja to miałem podzielone troszkę wyżej 
>> nuż ty tutaj próbujesz zrobić u mnie modelem było wszystko to co było 
>> związane z bazą danych - kontroler był też dość rozbudowany bo 
>> posiadał i zarządzanie bazą (wszystkie operacje wykonywane na bazie 
>> itp nawet formatki niektóre tak by łatwo wymieniać pewną 
>> funkcjonalności) a jako widok obrałem sobie poszczególne wzory faktur.
> Tylko u mnie model nie wie nic o sposobie utrwalania (baza danych) od 
> tego jest repozytorium. W modelu nie ma ani jednej linijki SQL.

No ok, tylko to co ja ci opisałem miało na celu przedstawić że MVC może 
przybierać różne postaci w zależności od warstwy w jakiej chcesz użyć MVC.

Tak jak pisałem wcześniej odnosząc się do klasy którą podałeś jeśli tą 
klase potraktujesz jako model to kontrolerem powinny być operacje na tej 
klasie (możliwe do wykonania) a widokiem wynik tych operacji.

Jednak jak widzisz taki podział może być nie wystarczający lub 
wymagający dodatkowych warstw by coś sensownego z tego powstało lepiej 
myśl o tym w ten sposób by każdy element wzorca zamykał w sobie jakąś 
konkretną funkcjonalność wtedy ci będzie łatwiej to zrozumieć.

Pozdrawiam
J-23

W dniu 2017-10-02 o 16:54, J-23 pisze:
> W dniu 02.10.2017 o 08:05, konsul41@wp.pl pisze:
>>
>>> Bazując na podanej klasie sprawa jest prosta w kontroler wsadzasz
>>> wszystkie operacje jakie możesz wykonać na tej fakturze i tyle
>>>
>>> Ja jak pisałem jeszcze w Delphi stworzyłem sobie komponent do Faktur
>>> gdzie opierał on się o MVC tylko ja to miałem podzielone troszkę
>>> wyżej nuż ty tutaj próbujesz zrobić u mnie modelem było wszystko to
>>> co było związane z bazą danych - kontroler był też dość rozbudowany
>>> bo posiadał i zarządzanie bazą (wszystkie operacje wykonywane na
>>> bazie itp nawet formatki niektóre tak by łatwo wymieniać pewną
>>> funkcjonalności) a jako widok obrałem sobie poszczególne wzory faktur.
>> Tylko u mnie model nie wie nic o sposobie utrwalania (baza danych) od
>> tego jest repozytorium. W modelu nie ma ani jednej linijki SQL.
>
> No ok, tylko to co ja ci opisałem miało na celu przedstawić że MVC może
> przybierać różne postaci w zależności od warstwy w jakiej chcesz użyć MVC.
>
> Tak jak pisałem wcześniej odnosząc się do klasy którą podałeś jeśli tą
> klase potraktujesz jako model to kontrolerem powinny być operacje na tej
> klasie (możliwe do wykonania) a widokiem wynik tych operacji.
>
> Jednak jak widzisz taki podział może być nie wystarczający lub
> wymagający dodatkowych warstw by coś sensownego z tego powstało lepiej
> myśl o tym w ten sposób by każdy element wzorca zamykał w sobie jakąś
> konkretną funkcjonalność wtedy ci będzie łatwiej to zrozumieć.
>
Ale to co Piszesz jest niezgodne z DDD i trudne do testowania.

W dniu 02.10.2017 o 20:22, Karol pisze:
> W dniu 2017-10-02 o 16:54, J-23 pisze:
>> W dniu 02.10.2017 o 08:05, konsul41@wp.pl pisze:
>>>
>>>> Bazując na podanej klasie sprawa jest prosta w kontroler wsadzasz
>>>> wszystkie operacje jakie możesz wykonać na tej fakturze i tyle
>>>>
>>>> Ja jak pisałem jeszcze w Delphi stworzyłem sobie komponent do Faktur
>>>> gdzie opierał on się o MVC tylko ja to miałem podzielone troszkę
>>>> wyżej nuż ty tutaj próbujesz zrobić u mnie modelem było wszystko to
>>>> co było związane z bazą danych - kontroler był też dość rozbudowany
>>>> bo posiadał i zarządzanie bazą (wszystkie operacje wykonywane na
>>>> bazie itp nawet formatki niektóre tak by łatwo wymieniać pewną
>>>> funkcjonalności) a jako widok obrałem sobie poszczególne wzory faktur.
>>> Tylko u mnie model nie wie nic o sposobie utrwalania (baza danych) od
>>> tego jest repozytorium. W modelu nie ma ani jednej linijki SQL.
>>
>> No ok, tylko to co ja ci opisałem miało na celu przedstawić że MVC może
>> przybierać różne postaci w zależności od warstwy w jakiej chcesz użyć 
>> MVC.
>>
>> Tak jak pisałem wcześniej odnosząc się do klasy którą podałeś jeśli tą
>> klase potraktujesz jako model to kontrolerem powinny być operacje na tej
>> klasie (możliwe do wykonania) a widokiem wynik tych operacji.
>>
>> Jednak jak widzisz taki podział może być nie wystarczający lub
>> wymagający dodatkowych warstw by coś sensownego z tego powstało lepiej
>> myśl o tym w ten sposób by każdy element wzorca zamykał w sobie jakąś
>> konkretną funkcjonalność wtedy ci będzie łatwiej to zrozumieć.
>>
> Ale to co Piszesz jest niezgodne z DDD i trudne do testowania.
> 
W którym punkcie niezgodne? Niezgodne jeżeli w jednym z tych elementów 
nie będzie kolejnych warstw. A ja nie napisałem że każdy z tych 
elementów ma być w tej samej warstwie

Ja przedstawiłem MVC w warstwie "funkcyjnej" a to nie oznacza że każda z 
tych elementów MVC  nie ma kolejnych aż po sam obiekt

Pozdrawiam
J-23

> W którym punkcie niezgodne?
" u mnie modelem było wszystko to co było związane z bazą danych"
Model nie powinien nic wiedzieć o sposobie jego utrwalania.

W dniu 03.10.2017 o 08:07, konsul41@wp.pl pisze:
> 
>> W którym punkcie niezgodne?
> " u mnie modelem było wszystko to co było związane z bazą danych"
> Model nie powinien nic wiedzieć o sposobie jego utrwalania.
> 

Nie koniecznie to wszystko zależy w której warstwie użyjesz MVC

napisałem to zdanie bo chciałem Ci pokazać że można MVC używać w różnych 
warstwach

Model u mnie też składał się z kilku warstw i też na każdej był użyty MVC

Podsumowując oprócz samego podziału na Model - Widok - Kontroler ważny 
podział na warstwy. Wtedy osiągamy pełną zgodność z dogmatem DDD i nie 
ma ani problemu z testowaniem tego jak zaznaczył Karol ani problemu z 
podmianą któregoś elementu

Pozdrawiam
J-23