Zend Framework Preview

Ik heb even vluchtig de manual doorgenomen, kortweg ziet het er netjes uit. Ik probeer het een van de dagen wel eens uit als er even tijd is.

Wat ik inderdaad ook spijtig vind, is het niet toelaten van hulp e.d.

Potentie heeft het denk ik wel, maar er is eerst nog een lange weg te gaan.

Ik ga er later nog eens uitgebreid voor zitten, maar op het eerste oog haalt het het niet bij RoR . Aangezien ik hem met Google niet in een keer kon vinden hierbij de link: http://framework.zend.com/ . Iniedergeval denk ik dat de non-open houding ze iniedergeval veel parten gaat spelen, juist het toelaten en bemoedigen van het indienen van patches en dergelijke zou ze denk ik veel helpen.

JHS schreef op maandag 06 maart 2006 @ 10:52:
Ik ga er later nog eens uitgebreid voor zitten, maar op het eerste oog haalt het het niet bij RoR . Aangezien ik hem met Google niet in een keer kon vinden hierbij de link: http://framework.zend.com/ . Iniedergeval denk ik dat de non-open houding ze iniedergeval veel parten gaat spelen, juist het toelaten en bemoedigen van het indienen van patches en dergelijke zou ze denk ik veel helpen.

You may keep changes to yourself and are not required to contribute them back. That said, if you believe your changes would be useful to other Zend Framework users, we encourage you to share these patches with us.

Hm, dat heb ik dan verkeerd begrepen. Maar da's mooi iniedergeval .

Je zal echter wel een CLA moeten ondertekenen: http://framework.zend.com/framework_cla_1.0.pdf

[ Voor 41% gewijzigd door JHS op 06-03-2006 11:00 ]

Nieuwe indeling, nieuwe plaatsen. Dit topic gaat naar DTE

Op dit moment maken wij intensief gebruik van Smarty en toen kwamen we dit tegen.
Vind het ideale van Smarty juist dat er geen PHP in je HTML zit en hier weer wel.
Ik moet er nog dieper in kijken hoor. Zo had ik ook het closed source idee niet gelezen.
Ook al is het niet 100% closed. Ontwikkelaars gaan niet moeilijk doen met formulieren.
De DB classe lijkt me weer erg interessant. Het preview karakter is ook weer een risico.

Ik denk dat wij gaan kijken hoe we Smarty en Zend Framework kunnen integreren en daar mee spelen.
Mocht het final gaan dan kunnen we kijken of we het toe gaan passen.
Dit ervaringen topic is wel handig imho.

Ik vraag me even af wat de toegevoegde waarde van ZEND zal zijn tov. andere al bestaande (meer uitgewerkte) en OS frameworks?

Had er een paar dagen terug naar gekeken (zondag, iirc). Ben begonnen de manual zo'n beetje helemaal te lezen, zag er veelbelovend uit.
Toen ik echter echt wat wilde doen er mee ging het mis. Het connecten met 'n database lukte eigenlijk al niet zonder dat ik zelf een (kleine) wijziging moest maken in de source en toen ik dan ook nog eens een query wilde doen kreeg ik 'n exception op m'n scherm. Helaas kon ik het niet 1,2,3 zelf fixen en heb ik het laten liggen... Jammer, want ik zie er best wel wat in. (En php5 is ook niet direct een probleem voor mij. )
Ik wacht nog heel even af, maar denk op zich dat er best wat in zit. Andere frameworks die ik bekeken heb vond ik niet al te geweldig werken ook...

Heb er ondertussen ook even mee gespeeld, een krot lijstje + en -:
+ Zend_Db en subclasses zijn nuttig, hoewel PEAR of ADO (voor PHP) dezelfde functionaliteiten bieden
+ Zend_InputFilter is een verdomd handige class
+ Zend_PDF heeft potentiëel, als je naar FPDF kijkt dan. EzPDF is anders ook lekker om mee te werken
- Zend_View: je hebt nog PHP in je HTML nodig, Smarty is hier een betere keuze vind ik persoonlijk

Al bij al denk ik dat Zend hier een goeie weg volgt (op de templating na dan), en een eigen standaardisering probeert door te drukken op gebieden waar er voor elk gebied x-tig classes zijn met allemaal een andere API.

maartenba schreef op woensdag 08 maart 2006 @ 07:55:
- Zend_View: je hebt nog PHP in je HTML nodig, Smarty is hier een betere keuze vind ik persoonlijk

Waarom miepen mensen daar altijd over . Er is niks mis met PHP code in je templates, aangezien PHP gewoon (ook) bedoeld is als template engine. Het maakt natuurlijk geen bal uit met welke taal je dat uitvoert, of dat nu een of andere meta-taal m.b.v. bijvoorbeeld Smarty, of PHP zelf, zolang je de presentatie en andere logica maar scheid .

JHS schreef op woensdag 08 maart 2006 @ 08:37:
[...]
Waarom miepen mensen daar altijd over . Er is niks mis met PHP code in je templates, aangezien PHP gewoon (ook) bedoeld is als template engine. Het maakt natuurlijk geen bal uit met welke taal je dat uitvoert, of dat nu een of andere meta-taal m.b.v. bijvoorbeeld Smarty, of PHP zelf, zolang je de presentatie en andere logica maar scheid .

Dat je de presentatie en andere logica moet scheiden klopt, echter is het voor vele designers waar je mee samenwerkt niet zo duidelijk, al die <?php ... ?> tags. Heb het ooit eens voorgehad dat ze die er gewoonweg uit haalden, "want da's toch geen HTML?".

Zelf gebruik ik of Smarty, of PHP zelf, maar als je dan toch PHP zelf gebruikt kan je Zend_View er ook meteen uitlaten. Het enige voordeel dat ik meteen zie is dat Zend_View alle pagina-logica bekijkt als een apart object.

In geval van smarty moet je toch ook wat syntax leren?

bartvb schreef op woensdag 08 maart 2006 @ 14:13:
De PHP vs Smarty discussie is al honderden keren gevoerd, ook op GoT Het blijft een kwestie van smaak en een kwestie van eisen. Heb je losse vormgevers die niets van PHP snappen dan kan Smarty handig zijn, wil je vooral flexibiliteit en snelheid dan is PHP handig (even heel kort door de bocht samengevat).

Vormgevers die niets van PHP snappen zijn geen enkel probleem, aangezien ze niet meer hoeven te tikken dan ze in Smarty zouden moeten doen. Als je nu leert dat dat gekke beest met 4 poten en een staart "hond" heet, dan noem je het de rest van je leven zo. Als je te horen krijgt dat dat beest "dog" heet, dan heeft ie dog. Het is gewoon wat je je aanleert, en dat ga je gebruiken. En die leercurve is voor PHP net zo hoog als voor Smarty.

Verder is die discussie hier inderdaad al vaak genoeg gevoerd, en het heeft vrij weinig te maken met de discussie over het Zend framework, dus misschien is het beter om deze discussie hier maar af te breken.

maartenba schreef op woensdag 08 maart 2006 @ 12:20:
[...]

Dat je de presentatie en andere logica moet scheiden klopt, echter is het voor vele designers waar je mee samenwerkt niet zo duidelijk, al die <?php ... ?> tags. Heb het ooit eens voorgehad dat ze die er gewoonweg uit haalden, "want da's toch geen HTML?".

Zelf gebruik ik of Smarty, of PHP zelf, maar als je dan toch PHP zelf gebruikt kan je Zend_View er ook meteen uitlaten. Het enige voordeel dat ik meteen zie is dat Zend_View alle pagina-logica bekijkt als een apart object.

Onzin. Die zelf verzonnen tags is ook gewoon php en geen html. Dus php en html scheiden lukt je toch nooit.

Echt veel vernieuwende onderdelen heeft het Zend Framework zo te zien niet, het grootste gedeelte is immers in andere class library's al onderhanden genomen. Het grootste pluspunt vind ik toch wel Zend_Search, een volwaardige port van Lucene. Iets wat PHP nog niet had.

Ik vind het erg veel op mijn eigen framework lijken die ik aan het ontwikkelen ben. Nu is het maar de vraag hoe andere developers tegen dit Zend framework aankijken en of het andere frameworks buitenspel zet.

Een interessante en eenvoudige tutorial om een beetje het basismodel van dit framework door te krijgen, kun je vinden op php|architect, geschreven door Chris Shiflett van o.a. PHP Security Consortium.

bartvb schreef op maandag 20 maart 2006 @ 08:03:
Het interessante aan het Zend Framework is niet dat het vernieuwend of revolutionair is maar dat er (potentieel) een standaard komt. Op dit moment is idd alle functionaliteit al wel te vinden maar dan moet je alles houtjetouwtje aan elkaar gaan plakken. Zend zou dat allemaal kunnen structureren, iig als ze het idd voor elkaar krijgen om zich te beperken tot de basics en het eenvoudig/overzichtelijk kunnen houden. We gaan het afwachten...

Als standarisering de bedoeling was, waarom zijn het dan geen PHP modules die standaard meegeleverd worden? PEAR is al bezig met de standaardisering maar bevat een wildgroei aan classes ed.
Persoonlijk kies ik een framework bij de wensen die op dat moment aansluiten bij de eisen die ik voor een bepaald project heb. Zo zou het goed voor kunnen komen dat ik prado en Zend_Search zou combineren, bijvoorbeeld. Tot op heden heb ik eigenlijk nog niet zo'n hoge dunk van het Zend Framework, eens kijken wat het brengt.

maartenba schreef op woensdag 08 maart 2006 @ 07:55:

offtopic:
Wat dat GoT framework betreft, daar is denk ik wel animo voor te vinden. Op zich zijn er al vele, maar een kleinschaliger framework waar zaken als DB, authenticatie, I18n en templating inzitten, moet doenbaar zijn.

Nog eens gespeeld met Zend Framework a.d.h.v. dit artikel, maar ik loop al vast op pagina 2. Hij blijft naar de 'no route' action gaan... Jammer

Overigens ook wel een leuk artikel over een vergelijking tussen een aantal php frameworks.

blizt schreef op vrijdag 31 maart 2006 @ 23:32:
Nog eens gespeeld met Zend Framework a.d.h.v. dit artikel, maar ik loop al vast op pagina 2. Hij blijft naar de 'no route' action gaan... Jammer

Overigens ook wel een leuk artikel over een vergelijking tussen een aantal php frameworks.

Je moet de svn versie hebben en niet de zip file. In de zip file is de functie run() nog niet gedefinieerd. In de SVN wel.

Ik heb gister even getest, maar OO is nieuw voor me (grotendeels) en het kostte ook wat moeite php5 werkend te krijgen met apache2.2

Vanavond maar eens verder testen.

Achteraf had ik gewoon 'n path verkeerd ingesteld waarschijnlijk, de .zip werkt in principe wel. Nu de SVN gedownload, maar for some reason negeert Apache m'n .htaccess in die specifieke dir/vhost... Dus mod_rewrite werkt niet, dus ... Argh
Maar goed, dat wordt gewoon nog maar NOG MEER Googlen .. en anders 'n nieuw topic, want hoort hier niet echt thuis denk ik.

[ Voor 18% gewijzigd door blizt op 08-04-2006 00:48 ]

Wat ik zelf ff niet snap is die indexAction() in je indexController.php

Wat ga je daar nou in gooien?

Ik bedoel, een normale index pagina doet vrij veel. (zie tweakers bijv, headlines, ads, .plan, laatste meuk, en nog veel meer). Lijkt me niet dat je dat allemaal in die index action gaat gooien toch?

Maar volgens mij snap ik de hele opzet ook nog niet helemaal Misschien ligt het daaraan

Ik wist al van dit framework voordat er een release was. Maar wat een tegenvaller. Ik verwachte een volledig functioneel framework. Maar voor de applicatie waar ik mee werk zou ik veel te veel nog bij moeten maken wil ik gebruik maken van dit framework. Bijvoorbeeld gebruikersrechten, file management.

Het idee is leuk, maar zoals al eerder gezegt, ik vind het zelf ook een enorme tegenvaller. Van een bedrijf als Zend had ik toch wel verwacht dat ze met iets beters op de klippen zouden komen. Er zitten zulke basic fouten in; vaak staan de variablen nog binnen quotes, opmaakfouten en hele klasses bestaan nog uit "return true;".

Er moet nog heel erg veel gedaan worden, mogelijk komt dat nog, maar ik zie er, uitgaand van deze bèta release, niet echt heel veel toekomst in.

Ik sluit me helemaal aan bij de laatste twee reacties. Wellicht liggen mijn verwachting wat te hoog, maar op dit moment komt er weinig uit het project. De zaken die werken in de preview, zien er goed uit, maar er zitten ook enorme fouten in.

Ze leggen de nadruk nu op het stabiliseren van de basis van het framework. Een goede zaak, maar als er dan proposals voor een queue en een stack langskomen (dat zit al rechtstreeks in de array functionaliteit van PHP) vraag ik me af welke kant het op gaat.
Een ander punt waar ik wat over struikel is het gebruik van bestaande software. Zend heeft ervoor gekozen om een eigen ajax implementatie te maken. Waarom zou je dat doen als er perfecte software is in de vorm van prototype? Je begint dan weer vooraan in het proces van ontwikkelen en debuggen, terwijl prototype zijn kunnen al heeft bewezen en een stuk verder is in de ontwikkeling.

Ik heb besloten om het framework eerst even links te laten liggen. Ruby on Rails blijkt toch ook erg interessant te zijn en bevat op dit moment wel alle zaken die ik nodig heb voor het ontwikkelen van een webapplicatie.

Flydesign.nl schreef op zondag 09 april 2006 @ 11:54:
Ik sluit me helemaal aan bij de laatste twee reacties. Wellicht liggen mijn verwachting wat te hoog, maar op dit moment komt er weinig uit het project. De zaken die werken in de preview, zien er goed uit, maar er zitten ook enorme fouten in.

Ze leggen de nadruk nu op het stabiliseren van de basis van het framework. Een goede zaak, maar als er dan proposals voor een queue en een stack langskomen (dat zit al rechtstreeks in de array functionaliteit van PHP) vraag ik me af welke kant het op gaat.
Een ander punt waar ik wat over struikel is het gebruik van bestaande software. Zend heeft ervoor gekozen om een eigen ajax implementatie te maken. Waarom zou je dat doen als er perfecte software is in de vorm van prototype? Je begint dan weer vooraan in het proces van ontwikkelen en debuggen, terwijl prototype zijn kunnen al heeft bewezen en een stuk verder is in de ontwikkeling.

Ik heb besloten om het framework eerst even links te laten liggen. Ruby on Rails blijkt toch ook erg interessant te zijn en bevat op dit moment wel alle zaken die ik nodig heb voor het ontwikkelen van een webapplicatie.

Het probleem van Zend is dat het een andere licensie aanhoud dan bijv Prototype. Daarom moet alles opnieuw gedaan worden. Ook 1 van de redenen waarom ze niet direct voor Smarty als view hebben gekozen en een eigen implementatie hebben gemaakt.

Het is nog allemaal zeer zeer alpha, maar wie weet wat ze ervan bakken in de toekomst.

aex351 schreef op zondag 19 maart 2006 @ 12:22:
[...]

Onzin. Die zelf verzonnen tags is ook gewoon php en geen html. Dus php en html scheiden lukt je toch nooit.

Het hangt een beetje af van de organisatie waarin je werkt en hoe gestructureerd je zelf wil werken. Voor het scheiden van bussiness logic en een presentation layer is smarty ideaal; zoals al eerder genoemd hoeven webdesigners geen ingewikkelde tags te leren en kunnen ze in principe de templates zelf aanpassen zonder dat er een webdeveloper aan de pas hoeft te komen. Een bijkomend voordeel is dat je webdesigner de rechten kan ontnemen op php scripts en dat ze alleen aan templates kunnen / mogen zitten (het laatste wat je wil is dat een webdesigner je code breekt). Daarnaast blijft je business logic duidelijker en overzichtelijker zonder alle php tags. Verder kan je door het duidelijk in templates werken eenvoudig het design omgooien of site-breed aanpassen. Uiteraard kan dit in php ook maar via templates gaat het uiteindelijk toch een stuk eenvoudiger. Verder biedt Smarty ook caching functionaliteit die, vooral heavy sites, veel snelheidwinst kan bieden.

Voor je hobby project kan je natuurlijk beslissen wat je doet; maar bij een beetje professionele organisatie zal je PHP/HTML niet gemixed zien en zal er vooral gebruikt worden gemaakt van design patterns en scheiding van logica en content...

JHS schreef op woensdag 08 maart 2006 @ 08:37:
[...]
Waarom miepen mensen daar altijd over . Er is niks mis met PHP code in je templates, aangezien PHP gewoon (ook) bedoeld is als template engine. Het maakt natuurlijk geen bal uit met welke taal je dat uitvoert, of dat nu een of andere meta-taal m.b.v. bijvoorbeeld Smarty, of PHP zelf, zolang je de presentatie en andere logica maar scheid .

In principe heb je gelijk al biedt Smarty ook nog caching mogelijkheden en die kan veel snelheidwinst genereren (mn bij high-traffic sites).

[ Voor 24% gewijzigd door Verwijderd op 06-06-2006 17:19 ]

blizt schreef op zaterdag 08 april 2006 @ 00:42:
Achteraf had ik gewoon 'n path verkeerd ingesteld waarschijnlijk, de .zip werkt in principe wel.

Wat voor path verkeerd ingesteld? Ik heb namelijk precies hetzelfde probleem. Alles komt bij mijn indexController uit als noRouteAction.

[ Voor 3% gewijzigd door Tux op 27-06-2006 12:11 ]