I've been working out a new presentation in the area of web-apps. And have dry-run tested it in short version speaches last weeks already here and here.

The four points it is trying to get accross:

1. The main indicating attribute (and the one that is ever recurring in any type) of the HTTP request is the request-URI. Since it has interface value, one needs to do a proper URI-request-space design. (In Cocoon speak: write a sitemap)
2. The returned response format on the other hand can be anything served on the menu of the day. Selected use of common patterns (see Martin Fowler) like TemplateView, TransformerView, TwoStepView will only get you so far to produce all similar and different outputs in a way that ensures some componentized reuse in the publishing. One needs to be able to (un-)plug(-in) all those design techniques at will in a componentized publication pipeline. One could use the binary-stream oriented pipeline components that were introduced by servlet filters... However the easy wins in using the semi-structured SAX-pipelines from Cocoon will easily get you addicted. And don't ignore that you have XML on the wishlist anyway.
3. The stateless behaviour of the web has kept on tantalizing web-development. Despite the many proclaimed MVC for the web frameworks we are still out of reach off the true benefit of that classic GUI pattern: create a spot where one can isolate the procedural control of the interaction, as it was written down in the use case? If you find this a bit misty as a description, well just check out Cocoon's flowscript based on Javascript continuations, you're bound to get one more addiction.
4. Finally, these interactive web-apps tend to be running around the issue of presenting and processing forms. Some experience in multi-skilled web development teams lead me to believe that the two sure ways to failure here are (1) having a strict web-design-driven approach (wow-looks, doesn't work) or (2) having a strict back-end-driven approach (dull looking, unusable but essentially working). The way to success here seems to be the cliche of communication and symbiosis of both worlds. In art-terms I call this: taking the 'cubist view': mapping the different viewpoints onto one painting. In technical terms it is about introducing a central form-model that holds both all required info to serve and handle good looking, usable forms as well as all information to keep the back-end happy and operational. Oh, just to make sure I'm not leaving you wondering: Cocoon currently is hosting a Form Framework that does this.

Rephrased, these four items kinda sound like: Cocoon, Cocoon, Cocoon, Cocoon. But seriously, they do seem to appeal to a broad common sense in such a way that in both occasions I've genuinly see them hit the audience with the impact of a gentle sledgehammer. Well, none of the above tries to claim eternal truth but presents itself rather as a fair set of observations.

In any case, obeying the intellectual honesty attitude over at Apache Cocoon: *WDYT? *