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.
Yep. It's not only about accepting these clean URLs - that's not
really a problem with mod_rewrite - but generating them should also
be easy and convenient. We could try to parse .htaccess files etc,
but that's worthless if the configuration happens somewhere else,
like in the httpd.conf. So we need a custom-built system for that,
and as a side-effect, people without mod_rewrite-capable servers can
benefit, too.
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).
Good point. I added a ticket for this. Note that we already have very
basic content type support; you can set AG_CONTENT_TYPE in
settings.ini which is used by the controller (there's also a
getContentType() method).
Would you like to add a few of your ideas to the ticket? I'd
certainly appreciate your help! Also, feel free to give input on how
you think this should be implemented, or even provide a patch ;) here
you go: http://trac.agavi.org/trac.cgi/ticket/81
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.
Of course we will not enforce the use of Propel or Creole. However,
we might add things that make using Propel more convenient, but rest
assured that it will not be the "default" or anything. The only thing
I can think of right now is a phing task that creates a CRUD module
for quick development, similar to Rails's scaffolding, using given
Propel classes.
Other frameworks bundle a lot of stuff by default. Symfony, for
instance, comes with Creole, Propel, Prototype, script.aculo.us
(Effects), TinyMCE (WYSIWYG HTML Editor), DynArch Calendar (DHTML
Calendar Widget).
This won't ever happen in Agavi. It's not our job to bundle stuff
like that.
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.
As I said, we won't bundle Prototype. Also, many people ask if there
is / will be Ajax support in Agavi. The answer is: no, because Ajax
is primarily a client-side thing, and there aren't many things we can
do to make creating Ajax apps on the server side any easier. It's not
any different from doing "normal" sites, you just return slightly
different output.
PS: How does Agavi now stand in relation to Mojavi M4? What
happened to
the merging plans?
First, we'll finish Agavi 1.0. After that, we'll look into our
options. M4 will likely be very stable and mature at this point, so
we won't really be able to influence core design decisions and thus
opt to continue Agavi (which I'd right now prefer to do)
PPS: Has anybody heard any more about the (potentially vapourware)
Zend
Application Framework? How does this affect Agavi?
It'll be probably be crap, so I don't care ;) Tries to borrow too
much from Rails which is a bad idea given that Ruby's syntax allows
for much more convenience solutions.
- David
P.S: One thing I'd also like to have soon is a pear channel along
with some kind of AgaviForge where people can install add-ons like
filters, models or even entire modules and applications, that's be
sweet.
_______________________________________________
agavi-dev mailing list
[email protected]
http://labworkz.com/cgi-bin/mailman/listinfo/agavi-dev
