I think it was Juliette that was asking me about spam filtering in PHP. I didn't think that was such a great idea (spamassassin is slow enough!), however, it seems that some others do.
The framework shootout session was very interesting. It was nice to see Toby jumping into CodeIgniter with such ease - it contrasted markedly with my own difficult initiation into CakePHP! There was mention of Kohana which I'd only seen a couple of weeks previously, but looks pretty good - I had always been put off CI by its support for PHP4, so a PHP5-clean version is very appealing. This article spells out the differences.
The shootout was, um, augmented by a heckler who had decided that all frameworks were "criminal" because they didn't conform to the letter of the "rules of MVC" (though MVC is really a pretty loose term AFAIAC). He wouldn't name his mystery preferred framework, but I later found out it was Agavi when I saw it demo'd by its creator. It is indeed very nice, and has distant ancestry in Mojavi (as used by Symfony). One of the things that I was impressed by is that it uses (of all things) HTML for marking up templates. This is an elegant reversal of what I've seen before, where form elements are typically generated by helpers (requiring syntax that you don't know). Why mark up a form input like this (vaguely CakePHP style):
<?php echo $htmlhelper->textinput('name', 'name', 20, 50); ?>
when you could do:
<input type="text" id="name" name="name" size="20" maxsize="50" />
and still get automatic server and client-side validation and ajaxy feedback goodness, but also have it play nicely with HTML editors like Dreamweaver? It also makes for a great deal of sense when generating non-HTML output. I can't think why other frameworks have not done this before.
Agavi also has very elegant routing so that a single controller function is available across all access methods, whether HTML, JSON, SOAP, XML-RPC or whatever. Makes CakePHP look very dumb.
Anyway, so maybe this heckler had a point of sorts.
I have to say a big thank you for the compliments I've received about my talk. Maybe it wasn't so bad after all! I'll get on with doing the remaining audio ASAP...
The framework shootout session was very interesting. It was nice to see Toby jumping into CodeIgniter with such ease - it contrasted markedly with my own difficult initiation into CakePHP! There was mention of Kohana which I'd only seen a couple of weeks previously, but looks pretty good - I had always been put off CI by its support for PHP4, so a PHP5-clean version is very appealing. This article spells out the differences.
The shootout was, um, augmented by a heckler who had decided that all frameworks were "criminal" because they didn't conform to the letter of the "rules of MVC" (though MVC is really a pretty loose term AFAIAC). He wouldn't name his mystery preferred framework, but I later found out it was Agavi when I saw it demo'd by its creator. It is indeed very nice, and has distant ancestry in Mojavi (as used by Symfony). One of the things that I was impressed by is that it uses (of all things) HTML for marking up templates. This is an elegant reversal of what I've seen before, where form elements are typically generated by helpers (requiring syntax that you don't know). Why mark up a form input like this (vaguely CakePHP style):
<?php echo $htmlhelper->textinput('name', 'name', 20, 50); ?>
when you could do:
<input type="text" id="name" name="name" size="20" maxsize="50" />
and still get automatic server and client-side validation and ajaxy feedback goodness, but also have it play nicely with HTML editors like Dreamweaver? It also makes for a great deal of sense when generating non-HTML output. I can't think why other frameworks have not done this before.
Agavi also has very elegant routing so that a single controller function is available across all access methods, whether HTML, JSON, SOAP, XML-RPC or whatever. Makes CakePHP look very dumb.
Anyway, so maybe this heckler had a point of sorts.
I have to say a big thank you for the compliments I've received about my talk. Maybe it wasn't so bad after all! I'll get on with doing the remaining audio ASAP...
Trackbacks
Trackback specific URI for this entryNo Trackbacks
Comments
Display comments as (Linear | Threaded)
Thanks Mike, glad you liked the talk, and and it was good to have a chance to look at Agavi with you. First off, I should say that I'm really not one to hold forth on design patterns or particular frameworks. My experience of them is fairly limited so I'm quite happy for others with clearer opinions on such things to deal with them. I think your point has its merits, but I also think that there can be a degree of flexibility that can make life easier - for example it's clear that separating views from controllers is a good practical idea, but quite how sharp that distinction is is probably less important in reality - some separation is significantly better than none, but complete separation is not necessarily that much better than some, especially if it requires additional effort to maintain. In a government-size project with millions of lines of code, maybe it would be worthwhile, but for everyday small to medium web projects, it's just not that critical, at least for me. Maybe that's just my outlook from having to deal with email, where there are plenty of tight, well-defined standards, but nobody sticks to them...
Something that I asked the Agavi author (David?) we were talking to is how to deal with typical CMS-style pages, where the output of a request is accompanied by unrelated content (e.g. viewing a blog post also shows a list of top stories, links and some ads). As far as I can see there is no way that you can accomplish this without either a) including a small element of a controller in a view (the view calls a controller action to populate the story list) or b) including a small aspect of a view in a controller (controller pushes additional views into the one requested). None of the frameworks I've seen achieve this without doing one or the other. It seems we need an additional concept to refer to a combined group of views and/or controller actions? A 'Layout' perhaps? Agavi refers to a 'slot' mechanism that seems to be neither view nor controller. This is a peculiarity of HTML apps - the problem doesn't arise in a web service model as you never get more than you ask for. Maybe MVC (as good as it is) just isn't a good fit for such web apps, and ALL these frameworks are wrong??! Dang, and there I am holding forth on design patterns... I'll stop now!
Something that I asked the Agavi author (David?) we were talking to is how to deal with typical CMS-style pages, where the output of a request is accompanied by unrelated content (e.g. viewing a blog post also shows a list of top stories, links and some ads). As far as I can see there is no way that you can accomplish this without either a) including a small element of a controller in a view (the view calls a controller action to populate the story list) or b) including a small aspect of a view in a controller (controller pushes additional views into the one requested). None of the frameworks I've seen achieve this without doing one or the other. It seems we need an additional concept to refer to a combined group of views and/or controller actions? A 'Layout' perhaps? Agavi refers to a 'slot' mechanism that seems to be neither view nor controller. This is a peculiarity of HTML apps - the problem doesn't arise in a web service model as you never get more than you ask for. Maybe MVC (as good as it is) just isn't a good fit for such web apps, and ALL these frameworks are wrong??! Dang, and there I am holding forth on design patterns... I'll stop now!
Hi Marcus,
indeed, the entire problem is more or less specific to HTML sites, since if you want a list of, say, related stories in your web service response alongside the article contents, then the obvious approach is to pull both inside the controller.
In Agavi (and symfony, too), the slots are, in my opinion, purely presentational (or behavioral, depends) in that they are an instrument to assemble a page made up of multiple fragments that are reusable. Consider, again for the sake of example, a related stories box beneath an article. You simply instruct the framework (either via the layout configuration, or manually in the code) to place the output of an action run there. Sure, internally, the respective action (=controller) is called, output is rendered again etc, but if you look at it without the knowledge of another action being run to achieve all this, it's a matter of "give me this box, don't care how you do it". It's kind of a chicken and egg problem anyways - you need to kick off the execution of the logic that renders the box somewhere, and the best place in our example is the view, since it's part of the presentational logic, not anything related to the controller.
Also, keep in mind that you simply leave an instruction to run a slot. It is not actually executed there in Agavi (not sure about symfony), but in the execution filter, which controls the action/view interaction and execution. Maybe that makes it a little more bearable?
Regarding layouts; we have such a facility where you define various layers of content and their slots (symfony, like Mojavi, only knows two layers for content and a decorator, and only the decorator may hold slots) in a layout configuration, which you can then load in the view. Internally, this calls the normal view methods for layer and slot definition, so after a layout has been loaded, you can fiddle with its layers and slots (e.g. add another slot, give additional arguments to a slot or whatever).
And you're correct. MVC is completely miserable for web applications. It's just that nobody has come up with something genuinely better yet (even though I find the .NET approach original, but not necessarily clean, given how you give validation instructions in the form tags and stuff like that).
indeed, the entire problem is more or less specific to HTML sites, since if you want a list of, say, related stories in your web service response alongside the article contents, then the obvious approach is to pull both inside the controller.
In Agavi (and symfony, too), the slots are, in my opinion, purely presentational (or behavioral, depends) in that they are an instrument to assemble a page made up of multiple fragments that are reusable. Consider, again for the sake of example, a related stories box beneath an article. You simply instruct the framework (either via the layout configuration, or manually in the code) to place the output of an action run there. Sure, internally, the respective action (=controller) is called, output is rendered again etc, but if you look at it without the knowledge of another action being run to achieve all this, it's a matter of "give me this box, don't care how you do it". It's kind of a chicken and egg problem anyways - you need to kick off the execution of the logic that renders the box somewhere, and the best place in our example is the view, since it's part of the presentational logic, not anything related to the controller.
Also, keep in mind that you simply leave an instruction to run a slot. It is not actually executed there in Agavi (not sure about symfony), but in the execution filter, which controls the action/view interaction and execution. Maybe that makes it a little more bearable?
Regarding layouts; we have such a facility where you define various layers of content and their slots (symfony, like Mojavi, only knows two layers for content and a decorator, and only the decorator may hold slots) in a layout configuration, which you can then load in the view. Internally, this calls the normal view methods for layer and slot definition, so after a layout has been loaded, you can fiddle with its layers and slots (e.g. add another slot, give additional arguments to a slot or whatever).
And you're correct. MVC is completely miserable for web applications. It's just that nobody has come up with something genuinely better yet (even though I find the .NET approach original, but not necessarily clean, given how you give validation instructions in the form tags and stuff like that).
I'm glad to see that I'm not barking up the wrong tree - thanks for the clarification. I'm definitely happier with the idea that this additional unrelated output should be pulled by a layout thing, and formalising that arrangement with a slot mechanism sounds fair enough. I was originally put off that approach by the CakePHP docs which say you shouldn't call actions from layouts, but then fail to suggest a sensible alternative. Though some of Cake is really good, and the community support is excellent, I've generally found it very hard work, so like many others, I've been dabbling in all sorts of things. Maybe I should give Agavi a go next!
Oh, you absolutely should! Just stop by on the IRC channel (most likely the best experience and quickest responses there) to learn some hints on how to get started, or, of course, try the mailing lists. IRC is much better in the beginning since you can ask many questions quickly as you progress through playing with the framework. I'm sure you'd enjoy it a lot, so here's hoping to see you soon!
"Agavi also has very elegant routing so that a single controller function is available across all access methods, whether HTML, JSON, SOAP, XML-RPC or whatever. Makes CakePHP look very dumb."
CakePHP has had support for serving multiple representations for over a year and a half now. You can set it up in two lines of code and add additional representations just by adding templates.
As to the issue of using helpers, Cake's buy you a whole lot that plain HTML templates don't, like automatic CSRF protection and POST data tamper-proofing, not to mention automatic inline validation... I could go on for a while, but the point is do your research. Calling things dumb that actually aren't dumb just shows your own ignorance.
Speaking of ignorance, I'd like to see how your friend Mike says this "Agavi" holds up on any of those fronts. And I want specifics, not rhetorical BS.
CakePHP has had support for serving multiple representations for over a year and a half now. You can set it up in two lines of code and add additional representations just by adding templates.
As to the issue of using helpers, Cake's buy you a whole lot that plain HTML templates don't, like automatic CSRF protection and POST data tamper-proofing, not to mention automatic inline validation... I could go on for a while, but the point is do your research. Calling things dumb that actually aren't dumb just shows your own ignorance.
Speaking of ignorance, I'd like to see how your friend Mike says this "Agavi" holds up on any of those fronts. And I want specifics, not rhetorical BS.
Hi Nate,
I didn't mean to cause any offence, I was just relating my own experiences.
Generally speaking my experience with CakePHP was very good (as I've said above), and the irc channel was a great resource with some very helpful people on it (including you as I recall). I would certainly use it again.
When I last used CakePHP last (about a year ago), it did support multiple access routes (WEBSERVICES = on in config), but required that I implement different controller actions for each, so I might have login() and xmlrpc_login() in a controller, though it will look like I'm calling 'login' from the XML-RPC client's point of view. It was also difficult (at least I never managed it) to map all XML-RPC requests through a single entry point. While I was working on this part I couldn't find any meaningful docs for it, and nobody on the google group or irc channel seemed to be able to help. Eventually I had to give up altogether, and that's not a good outcome for any framework. I'm glad to hear that's all changed since then.
I think you have misunderstood Agavi's templates. It does everything that you say, but without explicit helpers. It might look like plain html, but that's only before it gets parsed and delivered. It's all linked together using tag id attributes. Using a helper action to generate an input tag is just needlessly reinventing the wheel - why not just write the tag normally and attach the additional behaviour to it when you parse the template? There might be some overhead in parsing the template (like any templating mechanism), but the payoff is massively improved compatibility (helpers don't work in visual HTML editors) and readability of the templates. I think it's a brilliantly simple idea. You can still do PHP/helper style stuff, but you only need it where HTML doesn't provide suitable syntax (e.g. looping).
I've not actually used Agavi as yet, and I've observed (as have others) that its documentation is sorely lacking compared to other frameworks, but I was very impressed by the demo given by David (comments above) as it seems to be doing some major things very elegantly. I might try it and find that it's a disaster for me, but I don't know right now. As for Mike, I think you have missed out on his excellent heckling and the discussion that his comments provoked here: http://pookey.co.uk/blog/archives/43-phplondon08-the-crazy-guy-mail.html
I didn't mean to cause any offence, I was just relating my own experiences.
Generally speaking my experience with CakePHP was very good (as I've said above), and the irc channel was a great resource with some very helpful people on it (including you as I recall). I would certainly use it again.
When I last used CakePHP last (about a year ago), it did support multiple access routes (WEBSERVICES = on in config), but required that I implement different controller actions for each, so I might have login() and xmlrpc_login() in a controller, though it will look like I'm calling 'login' from the XML-RPC client's point of view. It was also difficult (at least I never managed it) to map all XML-RPC requests through a single entry point. While I was working on this part I couldn't find any meaningful docs for it, and nobody on the google group or irc channel seemed to be able to help. Eventually I had to give up altogether, and that's not a good outcome for any framework. I'm glad to hear that's all changed since then.
I think you have misunderstood Agavi's templates. It does everything that you say, but without explicit helpers. It might look like plain html, but that's only before it gets parsed and delivered. It's all linked together using tag id attributes. Using a helper action to generate an input tag is just needlessly reinventing the wheel - why not just write the tag normally and attach the additional behaviour to it when you parse the template? There might be some overhead in parsing the template (like any templating mechanism), but the payoff is massively improved compatibility (helpers don't work in visual HTML editors) and readability of the templates. I think it's a brilliantly simple idea. You can still do PHP/helper style stuff, but you only need it where HTML doesn't provide suitable syntax (e.g. looping).
I've not actually used Agavi as yet, and I've observed (as have others) that its documentation is sorely lacking compared to other frameworks, but I was very impressed by the demo given by David (comments above) as it seems to be doing some major things very elegantly. I might try it and find that it's a disaster for me, but I don't know right now. As for Mike, I think you have missed out on his excellent heckling and the discussion that his comments provoked here: http://pookey.co.uk/blog/archives/43-phplondon08-the-crazy-guy-mail.html
Hi Marcus, my apologies for the misunderstanding. That is actually the old way of handling web services, from before Cake had explicit support. It was replaced shortly after the 1.1 release, and the new way is mentioned here: http://cake.insertdesignhere.com/posts/view/2 and here: http://cake.insertdesignhere.com/posts/view/8
Also, everyone has their own opinion on this, but we find custom templating itself (i.e. Smarty) to be redundant, since PHP is itself a templating language. Not to mention the extra overhead of parsing an entire HTML page, which could be significant in many cases. IMO, not worth it.
As far as Mike's "rant," I did indeed read it, and my conclusion is that he is ignorant of the difference between a pattern and a specific implementation of a pattern (i.e. the 1988 MVC/Smalltalk-80 paper from the Journal of Object Oriented Programming).
Also, (and I have said this before: http://www.littlehart.net/atthekeyboard/2008/03/06/my-framework-is-more-mvc-than-your-framework/) the fact that he calls himself an "evangelist" essentially gives his game away. This isn't about debating pattern semantics, this is about a framework that can't get the job done.
While the demos may be impressive, the fact is that even though Agavi has been around longer, Cake is now the dominant framework in the PHP community, while Agavi continues to wallow in obscurity.
Everyone points to Agavi's lack of clear (or any) documentation as the reason for its lack of traction. I would submit that Cake suffered from the same problem for quite a long time in the earlier days of the project, and yet here we are, with the most active userbase of any PHP framework available. That should tell you something.
So if I were an Agavi "evangelist," I suppose I'd be ranting too.
Also, everyone has their own opinion on this, but we find custom templating itself (i.e. Smarty) to be redundant, since PHP is itself a templating language. Not to mention the extra overhead of parsing an entire HTML page, which could be significant in many cases. IMO, not worth it.
As far as Mike's "rant," I did indeed read it, and my conclusion is that he is ignorant of the difference between a pattern and a specific implementation of a pattern (i.e. the 1988 MVC/Smalltalk-80 paper from the Journal of Object Oriented Programming).
Also, (and I have said this before: http://www.littlehart.net/atthekeyboard/2008/03/06/my-framework-is-more-mvc-than-your-framework/) the fact that he calls himself an "evangelist" essentially gives his game away. This isn't about debating pattern semantics, this is about a framework that can't get the job done.
While the demos may be impressive, the fact is that even though Agavi has been around longer, Cake is now the dominant framework in the PHP community, while Agavi continues to wallow in obscurity.
Everyone points to Agavi's lack of clear (or any) documentation as the reason for its lack of traction. I would submit that Cake suffered from the same problem for quite a long time in the earlier days of the project, and yet here we are, with the most active userbase of any PHP framework available. That should tell you something.
So if I were an Agavi "evangelist," I suppose I'd be ranting too.
You obviously haven't ever looked into the performance of such a thing. It's not even measurable. And gets completely negligible altogether given how it's not done on any page request anyway.
Also, your remark "we find custom templating itself (i.e. [sic] Smarty) to be redundant" fits many rants I've been hearing about Cake and friends regarding how they lock people into their way of thinking.
Also, your remark "we find custom templating itself (i.e. [sic] Smarty) to be redundant" fits many rants I've been hearing about Cake and friends regarding how they lock people into their way of thinking.
Hi nate,
of course, Agavi's approach also means it escapes stuff for you. And Marcus has a point - if I want to use Smarty, my own template language, whatever, with Cake (or any other framework relying on unnecessary helpers for forms), I need to replicate all the features that ship with the default implementation.
Also, if you think that having your validation rules inline in an HTML template declaration, you obviously haven't ever exposed an application through both a web interface and a services API. Exactly what Mike was saying in his comments at the conference. Frameworks that do such a thing cannot deliver what they promise.
of course, Agavi's approach also means it escapes stuff for you. And Marcus has a point - if I want to use Smarty, my own template language, whatever, with Cake (or any other framework relying on unnecessary helpers for forms), I need to replicate all the features that ship with the default implementation.
Also, if you think that having your validation rules inline in an HTML template declaration, you obviously haven't ever exposed an application through both a web interface and a services API. Exactly what Mike was saying in his comments at the conference. Frameworks that do such a thing cannot deliver what they promise.
Hi David,
Unfortunately, we really can't have a productive discussion, since your comments clearly indicate that (a) you know little to nothing about Cake, and (b) you really didn't read what I said very carefully.
While CakePHP does have very strong opinions about how software should be developed, it by no means locks you into anything. The fact is, Cake is extremely extensible at every level. In fact, there are several classes available to replace the view layer and allow you to plug in a custom templating system (Smarty, phpTAL, and a couple others I'm aware of, probably more that I'm not).
Heck, assuming Agavi's templating system is modular, you could probably plug that right in with a few lines of code as well.
I suggest you go back and read my initial comment again, slowly. I mentioned nothing about inline validation rules. My comment was referring to Cake's ability to automatically output validation error messages.
Also, heh, I have most certainly written applications that serve both HTML front-ends as well as several different APIs... a few more times than you have I'm willing to wager.
You know David, you make an awful lot of assumptions. I highly recommend that you examine yourself before someone less polite than me decides to make you look foolish in public. Just throwin' that out there.
Unfortunately, we really can't have a productive discussion, since your comments clearly indicate that (a) you know little to nothing about Cake, and (b) you really didn't read what I said very carefully.
While CakePHP does have very strong opinions about how software should be developed, it by no means locks you into anything. The fact is, Cake is extremely extensible at every level. In fact, there are several classes available to replace the view layer and allow you to plug in a custom templating system (Smarty, phpTAL, and a couple others I'm aware of, probably more that I'm not).
Heck, assuming Agavi's templating system is modular, you could probably plug that right in with a few lines of code as well.
I suggest you go back and read my initial comment again, slowly. I mentioned nothing about inline validation rules. My comment was referring to Cake's ability to automatically output validation error messages.
Also, heh, I have most certainly written applications that serve both HTML front-ends as well as several different APIs... a few more times than you have I'm willing to wager.
You know David, you make an awful lot of assumptions. I highly recommend that you examine yourself before someone less polite than me decides to make you look foolish in public. Just throwin' that out there.
First of all, thank you for the interesting lecture, I enjoyed it more than the other sessions we had at the conference. I am the "heckler" as you mentioned it, and also the guy who approached you after the session and suggested that you write a book. Since my point about the frameworks was not understood, I wrote a somewhat long clarification which Ian has posted on his blog. Here it is: http://pookey.co.uk/blog/archives/43-phplondon08-the-crazy-guy-mail.html