Portál AbcLinuxu, 2. května 2025 17:40
Pred casom som pisal zapis, v ktorom som nadhodil zopar otazok ohladom Zope/Plone a ich pouzitelnosti na intranetove CMS, ktore by malo umoznit aj tvorbu databaz (resp. databazovych rozhrani). Na uvod tohto zapisu by som sa chcel podakovat vsetkym, ktori prispeli do diskusie. A ako moje rozhodovanie dopadlo?
Aplikacia, ktoru si kladiem za ciel svojho snazenia, sa da strucne popisat asi nasledovnym sposobom: intranetove CMSko, ktore by v principe fungovalo z pohladu pouzivatela podobnym sposobom ako klasicky filesystem, s tym, ze okrem "objektov" typu "subor" a "adresar", bude poskytovat napriklad typ "clanok", "diskusia", ale aj zlozitejsie moduly (vytvorene objekty volajme "nody"), ako napr. rozne databazy pre evidenciu neviem coho. Z tychto nodov si uzivatel bude moct vystavat, pouzitim weboveho rozhrania, strukturu webu, aka sa mu len zachce. Priklad: zacne od nejakeho "root nodu", ktory bude povedzme defaultnou strankou, pod nim si vytvori node typu "adresar" pod nazvom "Dokumenty", pod nim dalsi, povedzme "Vseobecne", kde si bude vytvarat zasa co sa mu zachce. Z tejto struktury sa bude automaticky generovat menu atd. Pristupove prava - opat podobne ako to uz uzivatel pozna, subor bude mat "download", "update", clanok zasa "view", "edit", pricom tieto prava bude mozne pridelovat podla lubovole a hlavne "per node", teda nie globalne pre urcity typ nodu, ale pre kazdy konkretny node.
Aby som bol presny, takuto aplikaciu (ci skor prototyp) som uz zbuchal v PHP, za pouzitia nejakych externych veci, ako napriklad templating engine a podobne. Je to funkcne, zatial to robi co potrebujem. Je to dobre ako "proof of concept", ale ako ostru aplikaciu by som to neoznacil. Z pohladu pouzivatela funkcne, z pohladu programatorskeho pomerne neciste. Ako priklad uvediem pracu s SQL databazou - v kazdom "module" je potrebne vytvorit CRUD funkcie. Okrem toho nakodovat prijimanie a validaciu dat od uzivatela, pritom by sa to pre typicke pripady vyriesit zadefinovanim jednotlivych datovych poloziek. Priklad: poviem, objekt typu "clanok" sa bude skladat z tychto casti:
Presne tymto sposobom to robi Plone a velmi sa mi to paci, okrem toho ponuka aj nejake dalsie vymozenosti, ako napriklad workflows. Uplne idealne na tvorbu typickych webov. Problemom su vsak prave spominane "zlozitejsie nody", napriklad aplikacia typu "databaza elektronickych suciastok". Som zvyknuty riesit tieto veci cez relacne databazy, avsak Plone pouziva objektovu ZODB, na com nie je nic zle (vo vacsine pripadov skor naopak), avsak nepodarilo sa mi najst vela informacii o tom, ako ziskat vsetky agregacne funkcie (resp. nieco ekvivalentne), ktore pouzivam v relacnych databazach. Existuju sice moznosti, ako ho prinutit ukladat data napriklad do PgSQL, ale ten sposob mi prisiel ako nie celkom cisty (zrejme len moj osobny problem, ale co uz). Vo vysledku by boli nejake data v ZODB, nejake v xSQL, co mi nepride ako idealne.
Takze zaver (moj osobny nazor): ak hladate nieco na web a zaobidete sa bez SQL, kludne sa dajte do studia Zope/Plone, podla mna sa to vyplati, ma to vela krasnych vlastnosti, ktore vam velmi ulahcia zivot. Ak ste vsak relacny typ :), zrejme narazite na veci, ktore tak lahko neprekusnete.
Kam povedie dalsie patranie? Bude o tom nasledujuci zapis, nedockavcom prezradim, ze uz nejaky ten tyzden sledujem stopy javovskeho Strutsu. Aby nedoslo k omylu, dvojica Zope/Plone sa da so Strutsom len tazko porovnavat, to prve je framework s vlastnou objektovou databazou+hotove CMS s rozhranim pre tvorbu vlastnych "typov nodov" a vela dalsieho, zatialco Struts je "len" MVC framework. Zda sa mi vsak, ze pre moje ucely bude vhodnejsi prave dobry MVC framework, na ktorom si tu aplikaciu postavim sam, sposobom aky mi vyhovuje.
Poznamka: ked toto pisem, som uz zrely do postele, budem si to musiet este po sebe precitat, ci som nezamiesil na nejaky flame, resp. nenapisal tam z nepozornosti nejaku hlupost. Rovnako sa mohlo stat, ze som tam napisal nejaku hlupost z nevedomosti. V kazdom pripade budem rad, ak ma na to v diskusii upozornite.
Tiskni
Sdílej:
No, ja bych jen pro objektivitu doplnil, ze admin rozhrani je pro opravdu standartni situace -- nekdy clovek potrebuje v adminovi takovou funkcionalitu, ze hackovat generovane rozhrani je zdlouhavejsi nez to napsat.naprosty souhlas, admin je neco, co clovek pouziva u blgu ci cms k zadavani dat, ne co ukazuje uzivatelum...
To mi radili i lide z Django-users na Google Groupsale hlavne to neni nutne - na skutezne zakladni veci (CRUD) existuji ty generic view, u kterych staci jen dodat HTML, pripadne napsat jednoduchyy wrapper, ktery naplni/schova nejake fieldy atd... jinak se samozrejme hodi poznamka, ze django ma skvelou komunitu (muj fanatismus je toho jiste prikladem ;) )A napsat si relativne univerzalne pouzitelne CRUD metody neni problem.
Btw: vypada to nejak realne s nejakym slusnym ceskym hostingem zamerenym na tyto frameworky?premyslim o tom, zatim resim nejake problemy spojene s behem pythonu v zabezpecenem prostredi... urcite dam kdyztak zpravicku, nebo minimalne poslu mail do skupiny (existuje i ceska, i kdyz ponekud neaktivni)
ale hlavne to neni nutne - na skutezne zakladni veci (CRUD) existuji ty generic view, u kterych staci jen dodat HTML, pripadne napsat jednoduchyy wrapper, ktery naplni/schova nejake fieldy atd...Ja jsem si je v TurboGears napsal, i kdyz myslim, ze tam neco na zpusob generic views taky je.
premyslim o tom, zatim resim nejake problemy spojene s behem pythonu v zabezpecenem prostredi... urcite dam kdyztak zpravicku, nebo minimalne poslu mail do skupiny (existuje i ceska, i kdyz ponekud neaktivni)No kdyz ty apps nebudou primo v adresari kam ma Apache pristup, tak by to nemel byt problem zabezpecit, ne? Kazdopadne ten hosting by sednul. Inspiraci bych videl ve WebFaction -- videl jsem ty jejich screencasty a je to hukot
me slo spise o zabezpeceni serveru proti klientum - aby si kazda aplikace nemohl spoustet jakekoliv prikazy pythonu atd... navic nevim jestli by slo udelat, aby kazda aplikace bezela pod jinym userem (aby si prave navzajem nemohly skodit) a spol - to by ale mozna resilo fastcgi... uvidime...premyslim o tom, zatim resim nejake problemy spojene s behem pythonu v zabezpecenem prostredi... urcite dam kdyztak zpravicku, nebo minimalne poslu mail do skupiny (existuje i ceska, i kdyz ponekud neaktivni)No kdyz ty apps nebudou primo v adresari kam ma Apache pristup, tak by to nemel byt problem zabezpecit, ne?
save
/update
nezačal používat merge
. Implementaci otevírání a zavírání session v tuto chvíli řeším cachováním otevřených session v ThreadLocal, pak jen stačí před ukončením zpracování funkce service
v příslušném servletu zkontrolovat, jestli není nějaká session otevřená, a případně ji zavřít.
merge
kouknu, díky za tip.
merge
vypada zajimave... na to bych se mel podivat...
jak resite lazy-bindings? ja to zatim resim otevrenou sessnou, ale neni to uplne idelani... pouzivate nekdo transport objeky bez vezeb mezi sebou?
jinak posledni dobou se mi hodne libi EJB3, tam to donuti cloveka vyresit tak nejak definitivne (stateless/stateful session beans)... dale se mi zde libi veci jako persistentni a transakcni kontext - no uz se tesim az budu mit moznost v tom neco delat
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.