Názory k článku
Seaside (1)

Tenhle dotaz je trosku mino , ale furt se to tyka Frameworku pro WEBiky, todle vsechno zni moc prima ale rad bych zustal u PHP a jelikoz tedka se blizi jeden biig projektik zajimalo by me jaky kdo ma zkusenosti s PHP Framework a co by kdo doporucil? Co treba Seagull ?

Dik
cerw

http://www.whoa-framework.org

Jestli chceš zůstat u PHP, tak ti není pomoci.

A proč jako? Copak v PHP nelze dělat projekty, dobré projekty? Pravda, moc jsem jich neviděl, ale ve firmě, kde jsem pracoval, nyní vyvinuli velký informační systém v Perlu. A to je daleko větší maso než PHP... Mají výborný objektový návrh, funguje jim to přes WWW/SOAP/MAIL prostě paráda.

Doporučil bych člověku, co se ptá, knihu DESIGN PATTERNS (vyšla v překladu). Po seznámení s OOP pak nějakou knihu o J2EE - ne pro to, aby se z toho učil programovat v J2EE, ale spíše pro přehled možností a vzorů pro webové programování. Skvělou publikací je třeba J2EE PROGRAMMING WITHOUT J2EE, na webu stačí hledat pojem "Spring Framework".

Rady typu "PHP je na houby" nejsou asi moc na místě, ne?

Jistě. I v PHP lze psát strukturovaně, případně objektově. I v PHP lze udělat pořádný návrh IS a napojit ho k webu, ale proč ho pak vlastně psát v PHP? I v Perlu jde napsat čistě hodně velký IS a napojit ho na cokoli, ale aspoň to nebudu psát přímo do html stránek ;-)

Jistě. I v Perlu lze psát strukturovaně, případně objektově. I v Perlu lze udělat pořádný návrh IS a napojit ho k webu, ale proč ho pak vlastně psát v Perlu? I v PHPu jde napsat čistě hodně velký IS a napojit ho na cokoli, a nemusim to vůbec psát přímo do html stránek ;-)

for (LANGUAGE lng1, lng2 in AllPossibleLanguages) {

SendToDiscussion ("Jistě. I v %s lze psát strukturovaně, případně objektově. I v %s lze udělat pořádný návrh IS a napojit ho k webu, ale proč ho pak vlastně psát v %s? I v %su jde napsat čistě hodně velký IS a napojit ho na cokoli, a nemusim to vůbec psát přímo do html stránek ;-)" format: {lng1, lng1, lng1, lng2});

}

prominte, neudrzel jsem se :)

V PHP lze ale narozdil od vetsiny jinych jazyku psat webove aplikace extreme rychle. Zejmena pri pouziti Smarty (http://smarty.php.net/) je PHP uplne o necem jinem. Od doby co pouzivam Smarty mam pocit v PHP, ze programuji a nikoli placam spagetovy kod. Zejmena mam udelane ve svem frameworku takove veci jako nahravani modulu a dokonce i zavislosti mezi modulama, a co se tyka vykonu jsem na tom hodne dobre, navic se da i vyuzit cache. Pokud clovek navic pouzije PHP5 je se s drzenim stavu funkci uplne za vodou.

Podle me je nejvetsi otazkou psani adminu. Frontend se nejlip napise v PHP, ale ty adminy jsou o uplne necem jinem. Tady je spis vubec na diskuzi, jestli je HTTP a HTML k tomuto ucelu dobre, ja myslim, ze ani nahodou. Nekde jsem cetl o napadu napsat admin ve Flashi, s cimz sice nemam zkusenosti, ale prijde mi to dobry napad, protoze Flash je opravdova aplikace a pres XML lze do nej a z nej rychle tahat data. Pripadne je take uzitecne napsat to jako Java aplet ci neco jineho, opravdu HTML je v tomhle ohledu hodne omezujici. Ja bych rekl, ze je takrka nemozne napsat modularni design adminu s tim, ze HTML zadnou modularitu nema.

A co takhle XUL?
Já vím jen GECKO, ale pro adminy je to buřt... :)

Vy jste ten článek nečetl, že?

PHP je vhodné na menší aplikace, kde hlavně není moc logiky. Při větší velikosti je projekt v PHP naprosto nespravovatelný. Taky je problém když k němu příjdeš za půl roku a chceš v něm něco dodělat.
My jsme například v Spring+Hibernate udělali http://www.chcispolubydlici.cz. U tohoto typu aplikace by se PHP mozna i hodilo, ale vzhledem k tomu ze mame v planu portal rozsirovat tak jsme se rozhodli pro Spring.

-----
Jakub Maléř
www.simpleway.cz

Pozor, i v PHP lze psát pěkně. Na PHP spousta lidí začíná a kód většinou bývá nepřehledný, web je tvořen systémem "vlaštovčí hnízdo" a po několika úpravách je velmi obtížné se v něm upravovat. Sám jsem to tak dělal.

Podíval jsem se na Javu, chvíli jsem si hrál s Ruby on Rails a zjistil, že i v PHP jde psát pěkně, stačí jen chtít. Používám Zend Framework a jsem naprosto spokojen. Dodržuji (a snažím se k tomu přimět i ostatní) zend coding standards a snažím se hojně komentovat. Na nástroje jako je Java nebo .NET sice PHP nemá, ale občas jiná volba není a nedá se říci, že projekty v něm jsou nespravovatelné. V Javě lze taky psát jako prase.

Dot net není jediným frameworkem pod sluncem. Například technologie Struts/JSF podporují vše co .NET a ještě přidávají hromadu věcí navíc. Pokud programátor postupuje podle správných vzorů, na žádné problémy nenarazí.

Osobně proti Seaside nic nemám, určitě je to skvělý framework. Text ale vyznívá způsobem, jako že je zde konečně něco pořádného, co je dotažené do konce. To není pravda.

Zvažoval jsem, jestli Struts zmínit. K problémům se staví prostě jinak a řeší je méně elegantně. Raději jsem se chtěl vyvarovat píchání do vosího hnízda.

pichnuti do vosiho hnizda se nevyhnes, at reknes, co reknes, vzdycky se najde nekdo, komu tim neudelas radost.

z celeho srdce a na svych starych odrenych kolenou PROSIM prispevatele, aby se navzdycky vykaslali na flamovani a snazili se hledat to, co je pro ostatni i pro ne nejlepsi, to, co nam vsem usnadni zivot a pomuze ziskat volny cas. hrozne moc me mrzi, kdyz inteligentni lide (a tech je tu drtiva vetsina) nechaji emoce cloumat svym majestatem a podlehnou pokuseni nekomu ublizovat.

kdyz nekomu napisu, ze je vul, protoze ma jiny nazor nez ja, tak se mi fakt neulevi. lepsi je mu rict, ze mam jiny nazor a hlavne PROC ho mam (a ne proto, ze PHP, C#, Smalltalk, Windows, Linux, Oracle, MySQL je na houby, to NENI duvod, ono totiz na houby je ve skutecnosti vsechno). tim dotycneho obohatim a sam mam dobry pocit, ze jsem se zasadil o spolecne poznavani. a treba se dozvim neco, co jsem nevedel, co zase obohati me. prospech pro vsechny.

Pavle, zkus dat prosim nejaky priklad, co konkretne myslis, ze Struts resi hure nez Seaside.

Dovolím si citovat povolanější (Ducasse):

"Struts purpose is to bring the MVC pattern to the J2EE platform. The Struts architecture acts as a wrapper for Java applications and divides its code into a Model, View and Controller. Although Struts manages to add a layer of abstraction to model control flows, the costs are high. Compared to Seaside a form validation requires rewriting several parts of the application: the form class, an XML file and the JSP code to display validation error messages. Adding validation to an existing application even requires changing the inheritance trees. In Seaside a validation can be done by adding a decorator around the component."

+ další porovnání, co jsem někde vyšťoural. Ale za to mě nekamenujte, nedělal jsem ho já a ani si nemyslím, že je fér.

First the total size of what one downloads for each version. Yes the Java Struts download is ~160 times larger.
Size (uncompressed)
Java Struts Version 4.1MB (yes MB)
Seaside version 26,759 B (yes bytes)

# of Files
Java Struts Version 155
Seaside version 1

Here is the total size of the source files. The java struts version is 8.9 times larger.
Source Size
Java Struts Version 239,330 B
Seaside version 26,759 B

Most of the Java struct version files contain a copyright notice. When I remove the copyright we get that the Java struts version is 5.9 times larger.
Source w/o copyright notice
Java Struts Version 159,554 B
Seaside version 26,759 B

Finally there is the number of classes.
Classes
Java Struts Version 36
Seaside version 12

Tak z tohoto, aspon pre mna, vysiel vitazne Struts - je robustnejsi.

Velkost (co sa tyka B, KB a MB) pre mna zacne mat vyznam az ked to budem chciet narvat do PDA alebo mobilu :-)

Promiňte, ja neuvedl, že se jedná o porovnání výsledných ekvivalentních aplikací v tom zhotovených (nějaký blog) ;-)

Ospravedlnenie sa prijima ;-)

Ale vysvetlite mi prosim, co za hovado urobilo v Struts blog, co ma 4.1MB a 155 suborov? Nemam dovod sa zastavat Struts, ale to porovnanie je velmi subjektivne a pritiahnute za vlasy. Urobit v hociakom frameworku 50MB webovu aplikaciu dokaze hocikto. Urobit to iste na 50KB uz chce niekoho, co ten framework ovlada trochu viac a vie co robi.

Jak jsem psal výše, mně se to porovnání také nezdá moc fér. Linky na stáhnutí obou řešení už bohužel nefungovaly.

Co tohle? Mně to funguje :)

http://lists.squeakfoundation.org/pipermail/seaside/attachments/20030808/c411a24b/Wafer.obj

Pokud potrebuji pridat do Struts projektu novou validaci, tak mi staci napsat Java tridu s jedinou metodou (x sekund), pridat do jednoho XML souboru definici nove validace (10 radku, kde asi 9 je cut&paste, takze asi max 30 s) a pridat do druheho XML souboru pouziti nove validace (pridat do atributu depends jedno slovo s nazvem validace, takze asi max 30 s).

Ani Seaside nemuze znat treba validaci na rodne cislo, takze at mate framework jakykoliv, tak ten kod validace vzdy musite napsat rucne a onech x sekund predstavuje vzdy velmi podobne cislo (rozdil muze byt snad pouze v moznostech ruznych jazyku, knihoven apod.). Jestli je Seaside v tomto prikladu lepsi/vyhodnejsi nez Struts, tak pouze v miste tech dvou XML souboru, jejichz uprava mi ve Struts aplikaci zabere asi 1 minutu. Mozna mi neco nedochazi, ale podle me je uprava dvou XML souboru dobra cena.

A já copak něco takového psal? Konstatoval jsem, že článek tak trochu vyznívá, že Seaside je spása. Není tomu tak. Stejně dobře komponentově mohu navrhovat aplikaci v JSF, WebWorku, Strutsech, Perlu nebo Smalltalku. Seaside nevnáší do webového programování žádnou převratnou novinku. Přiznávám, že jsem nevhodně zvolil titulek threadu, který se bohužel rozrostl... Takže to opravuji: "Seaside není spása, je to jeden z mnoha..."

Shrnu to: nevidím žádný velký přínost tohoto frameworku, alespoň z toho, co jsem pochopil z tohoto dílu. Budu rád, když mě autor vyvede z omylu. Sice zřejmě nezačnu programovat ve Smalltalku (jakkoliv velký respekt mám k tomuto praotci objěktového programování), ale zřejmě bych si nové nápady promyslel, jak z nich vytěžit maximum ve svém (jiném) přístupu.

ps - k té velikosti - já programuji v Javě a musím přiznat, že mi opravdu začíná vadit. takový Cocoon framework je takový moloch, že z toho jde až hlava kolem. a přičina? velké množství abstrakce, v Javě se téměř na všechno vytvářejí rozhraní, vytvářeji se knihovny na každou pitomost (např. logování - log4j, to se zapouzdří do jakarta-logging-commons a hnedka máme 0.5MB - a tak je to se vším). nicméně si nemyslím, že tohle jádrem problému

Navíc i v Javě se dá dělat tzv. "light programming", viz Google:

Pico Container
Nano Container

(knihovny co mají pár kilo...)

Nicméně stejnak to u velkého projektu dopadá takto:

Spring Framework

Přitažlivost Seaside nespočívá jenom v tom, co umí, ale také jak to dělá. Přívětivost, s jakou dokáže řešit problémy návrhu webových aplikací, rozhodně není samozřejmost. Za povšimnutí stojí fakt, že Seaside nebyla portována do všech implementací Smalltalku. Pro to, aby bylo možné ji napsat co nejsnáze použitelnou, vyžaduje od hostitelského prostředí takové vlastnosti, jako je např. možnost vytváření mělkých kopií zásobníku apod.

Ano, Seaside samozřejmě není jediný framework ve své kategorii, ale jak sám píšete, je užitečné vědět, jak se dají věci řešit i jinak a vytěžit z nich to nejlepší. I u autorů jiných frameworků se, pokud ji znají, těší velké vážnosti a je bohatým zdrojem inspirace. A rovněž autoři Seaside bedlivě sledují vývoj a snaží se adaptovat dobré nápady kolegů.

Pokud se zkoumají výhody a nevýhody Seaside, je nutné k nim také přičíst vlastnosti, které získává během ve Smalltalku (popř. Ruby). Ty hrají při rozhodování o nasazení tohoto frameworku často rozhodující roli.

Pusobi to na me jako "trochu" lepsi MVC framework, nic vic nic min. Kdyz uz jsem u toho porovnani se Strutsem, tak i samotni tvurci Struts priznavaji, ze by to chtelo v nekterych castech prekopat viz http://www.theserverside.com/news/thread.tss?thread_id=31509.

Dříve jsem pracoval s PHP, které je dobré na rychlé věci (tzv. naprasení stránek za hodinu). V PHP však lze udělat i velké projekty (centrum.cz, atd.) Přesto mi objektový model PHP nevyhovuje, pročež se snažím používat jiné frameworky, konkrétně http://www.rubyonrails.com/

1. zcela objektový návrh (používá jazyk Ruby), i k sql databázi se přistupuje jako k objektu, např.:

clovek = Lidi.new
clovek.jmeno = 'martin'
clovek.prijmeni = 'novak'
clovek.save

2. template engine nepoužívá žádné nové, skvělé, speciální XML šablony, nýbrž jen obyčejné rhtml (což je Ruby vkládané do HTML ve stylu PHP - někdy se logice v šabloně prostě nevyhnete, např. při opakování elementu na základě předaného pole, ale není k tomu přeci nutné vytvářet specialni jazyk jak to dělá konkurence)

RubyOnRails za mě prostě neděla 1001 věcí, jejichž používání bych se musel učit rok. Nejde o předpřipravené formuláře, jen o framework, který elegantně řeší to, co se dělá v PHP neohrabaně. Příklad aplikace v Rails napsané: http://www.43things.com (doporučuji, je to docela dobrý nápad :-))

To, co zde tak vychvalujete ("databázové objekty"), má ve světě OOT už léta jméno. Říká se tomu ADO - Active Domain Object, a můžete tak programovat v libovolném programovacím jazyce. Tohle celé se mi jeví jako krok zpátky (opět nic nového + kód míchaný v HTML)...

hlavně ty zkratky, ty jsou důležitý :-))

Problém je, že nikdy úplně neoddělíme šablonu a logiku. Občas mám pocit, že spousta projektů stráví většinu času vývojem superspeciálního šablonového jazyka, který bude mít nejlépe stejné možnosti jako každý skriptovací jazyk (a samozřejmě ho pochopí i sekretářka).

Na PHP se ukazuje, že právě toto vkládání kódu přímo do stránky není zas tak špatné, pokud se dělá s mírou ("uvaří" se to nahoře a pak jen vkládá na patřičná místa).

Spousta projektů je plná specialit, ale ve výsledku jde pořád o totéž Hello world.

Objektový princip je mi blízký, přesto ho ale raději dělám v jiném jazyce než v PHP, a to především kvůli ušetřenému času a klávesovým úhozům.

Sablona a logika uplne oddelit nejde to je pravda. Nicmene, spojovat PHP a 'sablonu' dohromady mi prijde zvrhlost - mam na mysli u rozsahlych projektu. Tam je kvalitni templata zaklad. A ze se jich moc dobrych na netu nevali (vim o jedne :)

Jesli umi ta sablona objekty a 'vsechno co PHP' neni az tak dulezite, dulezite je to, kolik prave usetri 'uhozu' a toho casu, nez lepit dohromady PHP a HTML/XML/... A jake prave poskytuje nastroje k tomu, aby byla vykonna a rychla na beh.

Presunout logiku UPLNE do templaty z PHP vrstvy je to, co se mi v PHP osvedcilo nejvic. Daji se tak pouzivat obrovske casti kodu. Za cenu 'slozitejsich' templat, ale ty jsou vzydcky u velkych veci rozsahle, at clovek chce nebo ne. A to je prave ta cast 'one-shot'.

ps: videl jsem tady dohadovani o (ne)velikosti projektu v PHP. Nas nejvetsi projekt v PHP ma radove ~50-60 tisic radku (to je ~2.5-3 mega na zdrojacich) + hafo veci v C/C++ (jako extension do PHP napr.)... A videl jsem i vetsi :)

To je jasne, ze nemam sablony a logiku v jednom souboru. Treba zde je kus sablony v rhtml - pochopitelne, prehledne, a porad je to Ruby:

<div class='polozky'>
<% @polozky.each do |jmeno,datum,mesto| %>
jmeno: <%= jmeno %><br />
datum: <%= datum %><br />
mesto: <%= mesto %><br />
<% end %>
</div>

...Problém je, že nikdy úplně neoddělíme šablonu a logiku. ...

Nejen že ji lze oddělit, ale u velkých projektů to ani jinak nejde. Model-View-Controller je defacto standardem pro psaní webových aplikací. Plácat logiku do "šablony" prostě nelze. Jde jen o to, jak naprogramovat prezentační část.

A o to u programování webových aplikací jde. Jakým způsobem zobrazíte data na stránce. Seaside nabízí velmi atraktivní komponentový model s dekorátory. V JSP máte možnost využít JSTL nebo JSF atd....

Potom uz je to ale slovickareni 'co' je sablona - resp. kde jsou jeji hranice. Ale odeleni kodu a logiky je zaklad, souhlas.

R.

Chcem podakovat autorovi za squeak serial a
ze uz sa tesime vsetci na seaside.
troska som sa v nom hrabal, seaside je perfektny framework na smalltalk, len je malo dokumentacie.( ja viem, su tam zdrojaky, :-))

tak sa nechajme prekvapit!!!

otazocka: co robit aby bol search friendly?

Pokud hledate seaside a delate v Ruby, podivejte se na
http://www.ntecs.de/viewcvs/viewcvs/*checkout*/Wee/trunk/doc/rdoc/index.html

autor pise, ze to je inspirovane seaside2, ale psane from scratch. Jinak seaside vypada zajimave.

borges je seaside na Ruby, wee se snazi jit trochu jinou cestou, pouze se Seaside inspiruje.. nicmene jde o velmi zajimavou zalezitost, ktera mi VELMI vyhovuje, je to opravdu parada oproti hodinam s php

Něco jsem v Seaside dělal, tak jenom pár postřehů. Musím se přiznat, že němám přehled jak se to dělá v jiných frameworks. Takže nejdříve šablony. Ty prostě skutečně nejsou, 90% všeho se generuje pomocí kódu, který poskládá HTML stránku. Takže např.

renderContentOn: html
   html paragraph: [
      html text: 'Hello world'
   ].

vyrobí <p>Hello world</p>. Podívejte se na WAAbstractHtmlBuilder co všechno se dá podniknout. Pokud nějaká značka chybí, tak se dá udělat třebas:

   html tag: 'strong' do: [html text: 'Hello world'].

což vyrobí <strong>Hellow world</strong>. Jsme v OOP, takže není problém si podědit tenhle builder a vyrobit vlastní, kde budeme mít vlastní specialitky. Můj vlastní dělal překlad vkládaného textu. Otázky designu co se týče barvy, písma, všechno je ponecháno na CSS a taky je to ještě ve vývoji.

Další věc je logika. Např. každá komponenta (ta vaše vlastní taky) umí něco jako

   self inform: 'Jsem v pohode'.

Tohle vykreslí stránku s daným textem a jedním tlačítkem OK. Je to už předefinováno, ale tím že ve smalltalku je všechno dost plastický, tak se to dá upravit nebo podědit. Takže třebas stránka kde je odkaz co vede na nějakou akci je:

renderContentOn: html
   html paragraph: [
      html
         anchorWithAction [self inform: 'Jsem v pohode']
         text: 'Cau, jak se mas'
   ].

Tohle udělá odstavec s linkou která vede "někam" a po jejím kliknutí se objeví stránka s tlačítkem OK a to vede zpět. Teď například nějaký hlasovátko:

renderContentOn: html
   html anchorWithAction: [self answer: #yes] text: 'Jsem za'.
   html break.
   html anchorWithAction: [self answer: #no] text: 'Jsem proti'.
   html break.
   html anchorWithAction: [self answer: #dunno] text: 'Nevim'.
   html break.
].

Mít takovou komponentu v proměnný "hlasovac", tak stačí jí zavolat odněkad z programu:

html
   anchorWithAction: [vysledek := self call: hlasovac]
   text: 'Co si myslite o....'

Samozřejmě i když je tady snaha o lineární flow control, pořád jsme v zajetí request-response, takže musí mít napaměti kdy ta aplikace se bude vykreslovat kdy podnikne nějakou akci a opět dojde k vykreslování.

třeba u www.espolubydlici.cz to bylo použito

Zajimal by me odkaz na nejake stranky, ktere se pokousi sumarizovat vetsinu "podobnych technologii"
J2EE, Struts, Seaside a zrejme tisice dalsich architektur, frameworku a vubec vseho.

Mam formular, v nemz jsou textove inputy. Do nejakeho neco napisu, pak kliknu na odkaz. Potrebuji, aby i pak zustal input vyplnen (aby se nesmazal). Jak lze toto udelat?

Totez plati, pokud mam vice formularu na jedne strance a stisknu submit jineho.

Dekuji

To je omezení ze strany HTML a řeší se to podobně jako všude jinde. Viz třída WAHtmlRenderer a v ní anchorWithScript: aString do: linkBlock