Forum Debian Users Gang

3135

Ostatnio edytowany przez uzytkownikubunt (2016-12-01 01:43:35)

Może sprecyzuj co rozumiesz przez "kolorowanie się". Jeśli chcesz żeby co drugi wiersz był innego koloru to masz opcję "alternatingRowColors", a color główny możesz przez stylesheet ustawić ewentualnie, a jeśli coś bardziej złożonego to tak jak Huk pisze najlepiej przez delegaty.

@jezoo:

Dobrze @diabolic napisał - daj znać co chcesz osiągnąć przede wszystkim, bo jak tylko przeplot kolorów to opcja do tego jest. Natomiast jak coś poważniejszego to delegaty.

@uzytkownikubunt:

O ile dobrze rozumiem to proponujesz coś w stylu - w tabeli SQL umieścić kolumnę nazwijmy ją "Metadata" (albo referencję do tabeli o podobnym przeznaczeniu) i tam dać informacje o tym jak poszczególne komórki mają się narysować? Jeśli źle zrozumiałem to mnie popraw...

Powiem tyle że widziałem taki design i dobre to jest niestety tylko w teorii, w praktyce i tak wygląd aplikacji biznesowych dąży do jednego (per platforma oczywiście) - łatwiej tak ludziom działać po prostu i uzyskać pomoc kiedy apka wygląda wszędzie jedakowo - przez co benefity są zwykle na papierze, zaś trudność modyfikacji - w realu.

Przykładowo - w projekcie nad którym obecnie siedzę w pracy, ktoś zrobił coś podobnego - nie tyle dla wyglądu, co dla rozmieszczenia poszczególnych kolumn w tabeli. Miało to na celu kontrolę które kolumny na poszczególnym kliencie (na desktopie inne, na mobilce inne) się wyświetlają a które nie. Z założenia miało być łatwo modyfikowalne i miało się dać wprowadzać zmiany widokowe z poziomu bazy, bez konieczności ingerowania w kod - same zalety... tyle że realia są takie że modyfikacja tego to koszmar, za każdym razem kiedy dochodzi nowa funkcjonalności oparta o to ustrojstwo trzeba się konsultować z ludkami od wersji mobilnej czy chcą to pokazywać czy nie, podczas modyfikacji trzeba patrzeć czy wyłączenie jakiejś kolumny nie rozwali logiki biznesowej... Potrzebujesz dodać kolumnę pomiędzy istniejące A i B? Normalnie no problem, 5 minut roboty - ale tutaj trzeba się konsultować czy komuś coś to nie spieprzy i tracić czas, do tego logika działania mechanizmu pokazywania kolumn była (jak to zwykle bywa zresztą...) "rozwojowa" i z początkowej dość prostej opartej na indeksie numerycznym, z czasem doszły jakieś warunki które rozszyfrować potrafią tylko ich twórcy... - jednym słowem masakra.

Min. dlatego trend jest taki żeby dane były bytem całkiem oddzielnym od widoku - baza wypluwa Ci wynik, a to czy Ty to wyświetlisz jako tabelę, combobox, czy w formie trójwymiarowego sześcianu, bazę powinno kompletnie mącić. Potrzebujesz widok na stronkę? Tworzysz widok HTML, potrzebujesz dla iOS? Tworzysz natywny dla iOS itd. Dane dostajesz te same - Baza nie dba jak widok zostanie wyrenderowany.

Inna sprawa że jeszcze można działać na modelach pośrednich (widokowych) tak jak ma to miejsce w MVVM - wtedy faktycznie można poszaleć i tak jak w ASP.NET udekorować sobie odpowiednimi atrybutami model widokowy - tyle że model widokowy nie ma (a raczej nie powinien) wiele wspólnego z modelem bazodanowym...

Jeżeli chodziło o coś całkiem innego to rozwiń proszę myśl :)

Pozdrawiam.