On Tue, 2006-01-10 at 09:07 +0100, David Zülke wrote: > 3) URL handling for elegant URLs and their generation. Pretty self- > explanatory. The Symfony project has an excellent routing > functionality we can borrow ideas from ;)
I hope this point becomes a top priority - URL query strings to select module and action have a few disadvantages. As an example, I have some Cisco IP phones that retrieve an XML phone directory listing, powered by Agavi. Since the Cisco phone web client is not really all that standards compliant, it chokes on the '&' in the URLs generated by Agavi. I resorted to using Apache's mod_rewrite to rewrite an SEO URL into the format that Agavi expects. Obviously it would be very nice for Agavi to handle routing like that internally though. Something else I'd like to see added to Agavi is support for different content-types. In the example above, I have to manually use PHP's header() function to override the MIME content-type, setting it to XML. The Agavi class is not aware of this though, and if it throws an exception, it will render an HTML exception page. Different content types will need to render the exceptions differently. Consider also content types like image/png, if using Agavi + GD to render images (as I am). Thirdly, I hope that Agavi doesn't go down the same track as so many other PHP frameworks, and fall in love with Propel and Creole. Ok, some people might find them useful, but as an experienced SQL programmer, I prefer my databases to be a bit smarter than the average MySQL-powered blog. I often use (Postgre)SQL foreign keys, views, rules, and triggers. Show me a scaffolding-like library that handles all those, and I'll show you someone trying to reinvent SQL in PHP. Let the power users handle their DB interaction the way they want - don't force/coerce them to use bloated, scripted libraries that run about one twentieth the speed of native PDO. And finally, regarding AJAX. I've looked at a lot of different AJAX libraries, before deciding to write my own. It seems a lot of frameworks chose the well-known "prototype" library. This library is quite good, although it tries very hard to turn JavaScript, a prototype-based language, into a traditional OO language. I also note that it predominantly expects the server to return HTML fragments in the XmlHttpRequest reponse. That is certainly a very simple method of updating a page. I prefer to return XML however, and parse it using XPath in JavaScript. I use this method to populate HTML forms - basically, I retrieve a database object, package it in XML, and client-side JavaScript extracts the fields from the XML and populates the form. The form POST also goes to an AJAX responder, which can return the status of the DB insert (primary/foreign key violation for example) to the client, without having to redraw the form. This way, I can swap out the front end (essentially, the view) for something like XUL or XAML further down the track, as both will parse XML, without having to change what the AJAX responder sends back to the client. PS: How does Agavi now stand in relation to Mojavi M4? What happened to the merging plans? PPS: Has anybody heard any more about the (potentially vapourware) Zend Application Framework? How does this affect Agavi? _______________________________________________ agavi-dev mailing list [email protected] http://labworkz.com/cgi-bin/mailman/listinfo/agavi-dev
