kolonnu definēšana

[tomaac]

Man ir admin panelis, kurā principā ir daudz vienveidīgu tabulu-list, vienveidīgu edit-formu utt. (nu, kā jau katrā admin panelī...), kas atšķiras tikai ar datiem un izmantojamiem kontroļiem.

 

Piemēram,

lietotāju saraksts

dokumentu saraskts

xxx saraksts

yyy saraksts

utt.

 

Tie visi pēc būtības ir līdzīgi saraksti, bet atškiras ar

- queriju, kas ir apakšā

- kolonnu skaitu un nosaukumiem

- kolonnas vērtības tipa

(piemēram,

kolonna "registration date" ir datums un tā jāattēlo datumam specifiski;

vai kolonna "username", kas ir vienkārši teksts;

vai kolonna "user_image", kas ir attēls

vai citi tipi, t.sk., LOOKUPi uz citām tabulām utt.)

- dažām kolonnām ir arī "linki"

- ? varbūt vēl ko

 

Līdzīgi ir ar edit formām un new formām.

 

Gribētos uztaisīt mehānismu, lai varētu to visu veikt vienādi. Lai varētu kkur centralizēti pamainīt tabulas izskatu, viegli varētu pievienot tabulai jaunu kolonnu utt.

Kādas ir idejas, lai to panāktu?

 

1) Varētu uztaisīt tā, ka vispirms palaiž queriju un visus datus saliek masīvā-tabulā.

Tad izsauc funkciju, kurai padod

- šo tabulu,

- masīvu - db kolonnu nosaukumus, kuras grib rezultātā

- masīvu - kolonnu nosaukumus latviski

- masīvu - katras kolonnas datu tipu jeb kontrolis (date, image, text, lookup u.c.) un tipam specifiskus rādītājus (dateformat u.c.)

- masīvu - katrai kolonnai - vai tas ir links un ja ir links, tad uz kurieni

- vai tas ir saraksts, edit forma vai new forma

- ? vēl kko

 

Bet kkā baigi smagnēja funkcija ar daudz parametriem...

 

2) Varētu uztaistīt db tabulu, kurā būtu tādi kā meta dati par field-iem.

Nu, piemēram, tur būtu šādas kolonnas:

table (piem., users)

field (registration date)

field_name (Reģistrācijas datums)

type (date)

link

lookuptable

lookupfield

utt.

 

Un tad zīmējot formu vai tabulu vai ko citu, vajadzētu no SELECT-a nolasīt, kādas kolonnas mēs gribam, tās atrast šajā meta datu tabulā un nolasīt, ko mums īsti attēlot.

Šis jau arī tāds smagnējs izskatās. Un liekas, ka priekš new formām šis arī neder, jo nav tāda SELECTa + sarakstos, edit formās un new formās kontroļa tips arī var atšķirties un tas te nav iekļauts.

 

... neticu, ka kāds vispār šito izlasīt, bet ja nu :)

varbūt kādas idejas, kā Jūs to darāt?

[Gints Plivna]

Yep ir izlasīts :)

Yep darām apmērām tā kā esi aprakstījis 2 variantā ar meta tabulu. Tiesa gan tas tiek darīts tikai klasifikatoriem, bet to teorētiski var paplašināt arī vienkāršākiem un ne tik vienkaršiem sarakstiem, jo sevišķi ja tās ir tikai attēlošanas formas. Viss sākas no formas, kam ir definēta pamattabula un kolonas, kuras rādīt šai tabulā. Metatabulā tiek norādīts arī kā kolona jāattēlo kā teksts, izvēlne vai checkbox, vai kā citādi. Veidi, protams, predefinēti un formu ģenerators saprot ko ar tādu darīt. Nekā mega sarežģīta, datu apstrāde tikai vienai tabulai (t.i. insert, update, delete), bet strādā vismaz 80% klasifikatoriem, kas nav mega sarežģiti un ar savstarpējām saistībam un ierobežojumiem. Ar sarežģītu klasifikatoru es šeit domāju piemēram adresi ar visām tās sastāvdaļām.

Īsti nesapratu problēmu ar selectiem (vai arī pārējiem vaicājumiem) - nekas jau nekavē arī tos dinamiski ģenerēt atbilstoši tai pašai tabulai un atbilstoši konkrētai definētajai formai.

 

Gints Plivna

http://datubazes.wordpress.com/

 

P.S. Tiesa gan baidos, ka šī tomēra nav īsti iesācēja līmeņa tēma un uzdevums :)

Edited December 1, 2009 by Gints Plivna

[tomaac]

Paldies par atbildi un pacietību visu izlasīt :D

 

Par šo risinājumu vēl:

 

1) Ar "SELECT" mana prolblēma bija tāda:

 

Es nodefinēju manā meta tabulā kolonnas, piemēram, "username", "tbl_users", "text" utt.

Tālāk es kodā rakstīju select username from tbl_users

Tālāk es ar noteicu kādas kolonnas tika padotas selectā un pēc kolonnas+tabula atradu manā meta tabulā atbilstošo ierakstu.

Tātad manā risinājumā kolonnu nosaukumus es nolasu no SELECTa.

 

Tagad, jaman ir NEW forma, tad kkjā šitais risinājums vairs nestrādā, jo man nav no kurienes nolasīt, kādas kolonnas skatīt.

 

 

No tavējā posta saprastu, ka kkur atsevišķi varētu definēt, kādas kolonnas es gribu redzēt, nevis kā es iedomājos - nolasīt no SELECTa.

 

 

2) Otra problēma - vai šāds risinājums parasti strādā arī tad, ja kkā kolonnām vajadzētu piesiet linkus? Piemēram, spiežot uz "username" vai "klasifikatora_nosaukums" aiziet uz VIEW formu vai EDIT formu.

 

3) Vajadzētu arī tādas iepriekšnotiktas kolonnas, kā "Delete", "Edit" (iconiņas, kas ar padoto rindiņu dara šo un to). Liekas, ka ar šo risinājumā nav problēmas.

 

4) Un pēdējā problēma - ko tad īsti darīt, ja vienai Kolonna + Tabula kombinācijai ir paredzētas dažadi tipi. Piemēram, sarakstā tas parādās kā vienkāršs TEXT, bet NEW formā tas ir editbox. Vai, piemēram, sarakstā laukam ir LINKs uz dotā ieraksta VIEW formu, bet VIEW formā šim te laukam vairs nevajaga LINKu. Sanāk, ka tai meta-tabulā būtu jāparedz dažādas kolonna - view_kontrolis, saraksta_kontrolis, edit_kontrolis...?

[Mr.Key]

Darīju tā, ka padevu datu array uz skatu (templeitu), skatā ir f-ija, kas zīmē sarakstu, f-ijas parametrs ir saraksta definīcija - kolonnu saraksts, virsraksti un dažādas īpašības. Standarta kolonnas vienkārši atzīmēju (edit, check, move up/dn ..)

 

Tagad daru tā, ka pārtaisu uz objektu, kura init() f-ijā nodefinē saraksta kolonnas, bet render() f-ija uzzīmē viņu. Dati tiek padoti rowsetā (izmantoju Zend Framework).

 

Kolonnu ietveršanu / noņemšanu domāju realizēt tā, ka datubāzē ir metadatu tabula, kurā ieķeksē / noņem ķeksi tiem laukiem, kas definējami kā pievienojami / noņemami. Tas tad kaut kur ielādēsies un glabāsies, nav svarīgi kur, to izdomāšu vēlāk un pierakstīšu dažas rindiņas klases kodā pie render() f-ijas.

 

Respektīvi, tāds kā kopējs variants no tevis aprakstītajiem, taču idejiski darbs ar listēm manā gadījumā būs līdzīgs Zend_Form, attiecīgi sastrukturēts kods. Droši vien ka drīz zends piedāvās savu Zend_List...

Edited December 1, 2009 by Mr.Key

[Gints Plivna]

Ā BTW īstenībā šeit prasās pēc 2 tabulām. Metaformas/tabulas un metakolonas. Kur metatabulās raksti kurai tabulai tas būs (no šīm vari noģenerēt formu sarakstu), metakolonās savukārt ir ieraksts katrai kolonai, ko gribi attēlot/rediģēt.

Tad veidojot selektu protams to veido tā, ka FROM klauzas tabulu ņem no metatabulas ieraksta, bet visu kolonu sarakstu ņem no ierakstiem metakolonu tabulā. Tas ģenerējot vaicājumus.

Ģenerējot formu, tu ņem info no metakolonu tabulas un skaties kādā veidā katrs ieraksts jāattēlo, vai tam jāliek kaut kāda izvēlne (kura atkal kaut kā jādefinē) vai nē.

 

>2) Otra problēma - vai šāds risinājums parasti strādā arī tad, ja kkā kolonnām vajadzētu piesiet linkus?

>Piemēram, spiežot uz "username" vai "klasifikatora_nosaukums" aiziet uz VIEW formu vai EDIT formu.

nu pieliec metakolonu tabulā jaunu lauku, kurā ieraksti uz kurieni iet (ja vispār iet).

Tātad šeit ir tā, ka visas dažādās lietas, ko kolonām vajag, to vari tai tabulā norādīt. Kā hintu varu iedot, piemēram, šādas kolonas:

kolonas nosaukums tabulā

kolonas virsraksts formā

kolonas tips tabulā

kolonas ievadtips formā

ievadlauka garums

ievadlauka kārtas numurs

kārtas numurs order by klauzā

vai kolona obligāta?

ierobežojums (kā regexps piemēram)

noklusētā vērtība

vai tikai lasāma?

css klase

 

Par trešo jautājumu - jā ja tu ar vienu metakolonas ierakstu taisies definēt gan to kā reālā kolona izskatīsies sarakstā, gan ievadformā, tad iespējams vajag dažādus atribūtus sarakstam un ievadformām. Vēl teorētiski pastāv iespēj, ka iekš mnetatabulām/formām definē 2 ierakstus vienu sarakstam, otru rediģēšanas formai un tad katram kolonas definē atsevišķi ar saviem atribūtiem.

 

Gints Plivna

http://datubazes.wordpress.com