Wysota
7/3/2007 8:12:00 PM
Zbyszek Malec wrote:
>
> Ale widok z nich nie skorzysta. Ja nie chce dodawaa do modelu metod, ja
> chce odj?a.
Czemu?
>
>> A jeden
>> uniwersalny interfejs pozwala na wy?wietlenie modelu drzewiastego zarówno
>> w widoku drzewiastym, tabelarycznym jak i listowym.
>
> I to jest z3e.
Nie zgodze sie. Jest wiele przypadków, gdzie to jest po prostu niezbedne.
We?my za przyk3ad QDirModel. Wyobra? sobie, ?e musia3by? miea
QTreeDirModel, QTableDirModel i QListDirModel, ?eby w ró?nych widokach
ogl?daa drzewo katalogów. O wspó3dzieleniu zaznaczen ju? w ogóle by mo?na
zapomniea...
>
>> Gdyby ka?dy z nich mia3
>> inny interfejs, nie by3oby to mo?liwe.
>
> Gdyby twoja klasa modelu by3a tak uniwersalna, to mog3a by implementowaa
> ka?dy z tych specyficznych interfejsów osobno.
Podobno chcesz zmniejszya liczbe metod :)
>
>
>> Co wiecej metody dostepu posiadaj?
>> domy?lne parametry, co pozwala np. na pominiecie parametru rodzica przy
>> tabelarycznym modelu. Dodatkowo mamy abstrakcyjne specjalizacje
>> najogólniejszej klasy modelu, które dostarczaj? od razu prawid3owej
>> implementacji metody index() dla modeli poszczególnych kszta3tów.
>
> Czyli dostajemy metody które musz? robia wszystko, przy czym najcze?ciej
> wykorzystuje sie jedynie u3amek tej funkcjonalno?ci (bo akurat
> implementujemy model tabeli a nie drzewa).
Nie. Je?eli implementujesz model tabeli, to dziedziczysz po
QAbstractTableModel i nie przejmujesz sie pojeciem rodzica, bo domy?lna
implementacja za3atwia to za Ciebie, a rodzic jest w ka?dej metodzie
argumentem z warto?ci? domy?ln?. A dodatkowo widok drzewa taki model
równie? wy?wietli poprawnie.
>
>>> Moim zdaniem to jest tylko dodatkowe zaciemnianie. Podejrzewam ?e da sie
>>> to zrobia pro?ciej.
>>
>> Mo?liwe, ?e sie da - pytanie, co sie wtedy traci.
>
> Nic? Wszystko? Zale?y jakie sie rozwi?zanie zastosuje.
Podaj konkretn? propozycje.
>
>>> Qtwego MVC te? mi nikt nie ka?e u?ywaa, tak wiec ten argument odrzucam.
>>
>> Oczywi?cie, ?e nie ka?e, natomiast u?ywanie go zwieksza drastycznie
>> kompatybilno?a i reu?ywalno?a raz napisanego kodu, co jest, my?le,
>> argumentem istotnym, szczególnie dla a) pocz?tkuj?cych programistów i b)
>> jednostek, które zawodowo zajmuj? sie tworzeniem oprogramowania.
>
> Ja chce mvc, ja nie chce qtwego mvc.
Ale? nie u?ywaj, nikt Ci nie ka?e. Tylko nie mów, ?e jest "be", bo Ci sie
nie podoba jego uniwersalno?a.
>
>>> Co
>>> do potrzebno?ci - w przyjetym rozwi?zaniu s? potrzebne. W innym nie
>>> musia3yby bya potrzebne.
>>
>> Wcale nie s? potrzebne... Wystarczy zmodyfikowaa QItemDelegate i hulaj
>> dusza piek3a nie ma. Domy?lny delegat jest jedyn? encj?, która w ogóle
>> pobiera dane z tych ról.
>
> Teraz mamy taki bardzo ogólny twór który robi absolutnie wszystko. To nie
> jest dobre.
Nie robi wszystkiego, robi du?o w spójny i 3atwo rozszerzalny sposób (vide
QDataWidgetMapper). Domy?lne zachowanie praktycznie ka?dego komponentu jest
intuicyjne, tak?e je?eli nie potrzebujesz jakiej? funkcjonalno?ci, po
prostu jej nie dotykaj, bedzie dzia3aa sensownie samo z siebie.
>>> Rozwi?zanie z rolami nie jest najgorsze, ale
>>> pozostawia troche do ?yczenia.
>>
>> np?
>
> To co ju? pisa3em wcze?niej plus pare innych.
Tzn? Pytam nie po to ?eby j?trzya, tylko ?eby ewentualnie podchwycia pomys3
i zasugerowaa odpowiedni? modyfikacje Interview.
>
>> My?le, ?e niedogodno?a wywo3ania tej metody w jednym (!) miejscu w modelu
>> jest niewielk? cen? w zamian za mo?liwo?a posiadania trwa3ych indeksów i
>> precyzyjnej kontroli rozmiaru modelu (bo jak inaczej zagnie?dzia
>> wywo3ania insertRows()?
>
> A co je?li ja nie mam gdzie tej metody wykonaa?
To j? olej. Je?eli twój model jest statyczny (tzn. inaczej, je?eli ma
statyczy wymiar), to domy?lna implementacja insertRows wystarczy. Minimalna
implementacja trójwymiarowego modelu wymaga jedynie zaimplementowania metod
data(), parent(), index() oraz rowCount() i columnCount(). Przy modelach
dwu i jednowymiarowych odpada od tego metoda index(), a parent jest
trywialne (return QModelIndex()). Czyli zostaje data() do zwrócenia danych
oraz rowCount() i columnCount() do zwrócenia wymiarów modelu.
>
>> Je?eli kto? chce pisaa w3asne architektury do wszystkiego, to droga
>> wolna. Je?eli kto? chce wykorzystywaa
>> Swoj?Ulubion?ArchitektureModelWidok, to te? nie ma problemu, tyle, ?e nie
>> skorzysta wtedy z ?adnej zalety Qt.
>
> Po prostu uwa?am ?e MVC da3o by sie zrobic pro?ciej i lepiej ni? to jest
> zrealizowane tutaj.
Mo?esz zasugerowaa jaki? kierunek poszukiwan? Je?eli dobrze rozumiem, to
sugerujesz oddzielne interfejsy dla listy, tabeli i drzewa. Tylko, ?e to
raczej skomplikuje a nie upro?ci sytuacje. |wiat informatyki (i nie tylko)
ma tendencje do abstrachizacji wszystkiego, co sie da. Tendencja ta wydaje
sie utrzymywaa ju? do?a d3ugo (na moje oko minimum od pocz?tku lat 90-tych
zesz3ego stulecia, chocia? zdecydowanie mo?na sie doszukiwaa jej prekursora
co najmniej w systemie Unix, czyli 20 lat wcze?niej) i ma do?a mocn?
pozycje i ogromne grono zwolenników (z ruchem FOSS i Microsoftem na czele,
poprzez ?wiat teleinformatyki, nie wiadomo w3a?ciwie na czym koncz?c).
Dlatego nie widze powodu, ?eby akurat w przypadku MVC odstepowaa od tej
(chyba niepisanej, choa ogólnie znanej i "przestrzeganej") regu3y. Ca3y
paradygmat programowania obiektowego opiera sie w3a?nie o abstrakcyjno?a i
uogólnianie i wydaje mi sie, ?e ca3e Qt (mo?e z drobnymi wyj?tkami w paru
bardziej ukrytych miejscach) doskonale wpisuje sie zarówno w ten
paradygmat, jak i te tendencje. Je?eli co? u?ci?lisz (tak jak, je?eli
dobrze rozumiem, proponujesz), to ograniczasz obszar zastosowan (czysta
matematyka). Zgodze sie, ?e nie mo?na w ten sposób rozumowaa w
nieskonczono?a (chocia? fizycy od zarania dziejów twierdz? co? przeciwnego
i chyba w swojej dziedzinie maj? racje), bo abstrachowanie to jednocze?nie
komplikowanie (wystarczy spojrzea np. na biblioteke Crypto++). Natomiast
uwa?am, ?e Interview jest dalekie od osi?gniecia tej nieprzekraczalnej
granicy - w koncu jedyne, co _trzeba_ zrobia, to zaimplementowaa trzy
proste metody, a to i tak jedynie w przypadku, gdy QStandardItemModel oka?e
sie niewystarczaj?cy.
>
> Dla mnie EOT. Pozdrawiam.
Eee... uciekasz od dyskusji a temat sie nie wyczerpa3. Bardzo mnie
interesuj? Twoje uwagi, dlatego nalegam, aby?my jeszcze troche
podyskutowali, a mo?e i kto inny sie pod3?czy do dyskusji.
Pozdrawiam serdecznie,
W.