Reinhard Poetz wrote:
Sorry for my late answer but I was very busy last week ...
Sylvain Wallez wrote:
Reinhard Poetz wrote:
I'm sitting in a JAX (conferenc about Java, XML, Apache and Webservices) session about Tapestry and I'm rather impressed. Does anybody have experiences with it?
Tapestry really makes it easy to design web applications with e.g. Dreamweaver and the person who is responsible for this job doesn't need to have a clue about what happens in the background. Of course multi-channel publishing gets lost but: Do multi-channel forms really make sense? Or are they an academic solution because IRL you are forced to rewrite each form because of different screen sizes?
I just have a doc-reading experience of Tapestry, and we (Anyware) have been using this kind of "augmented HTML" for years, compiling it to XSL stylesheets.
Although this works well for simple mappings, I don't know how this can handle conditional layouts (e.g. different HTML when a repeater is empty or not) without requiring a minimal knowledge of some templating language.
Unfortunatly I'm not a tapestry specialist after a 75 min session but I think there are (simple) ways.
I digged into the Tapestry documentation. The main difference between Tapestry and other template languages is that template instructions are written as attributes on standard HTML tags, thus allowing the template to be edited with any HTML editor, as long as it keeps foreign attributes. This somehow looses the clean structure brought by using multiple namespaces, but doesn't require a specially configured Dreamweaver.
Technically, I actually see nothing that couldn't be implemented either through a new template generator (TapestryTemplateGenerator?) or an XSL producing e.g. JXTemplate.
When time permits, I'll prototype something with a CForms sample.
But this is something we may work on: I once prototyped a few dozen lines of XSL to transform a regular HTML page with <form> and <input> tags into their <ft:*> counterparts. You can then use dreamweaver to edit your forms.
The problem is 'roundtrip editing' of those forms, isn't it? And, how to integrate your data layer?
No roundtrip problem, as the template is produced on the fly (and cached) by a pipeline:
<map:match pattern="view-*.html">
<map:generate type="jx" src="cocoon:/tapestry2jx/{1}.xml"/>
<map:transform .... />
<map:serialize/>
</map:match><map:match pattern="tapestry2jx/**.xml">
<map:generate src="{1}.xml"/>
<map:transform src="tapestry2jx.xsl"/>
<map:serialize type="xml"/>
</map:match>E.g. Tapestry has a very small 'footprint' within the HTML and roundtrip editing is no problem. If you set up a template in Dreamweaver for every component you get a very powerful system.
Having done some customization on Dreamweaver, I can say it's easier to add new tags (i.e. JXTemplate instructions) than new attributes on standard tags.
However, the value of Tapestry isn't in the possible DW integration, but in the ability for the web designer to be totally unaware of the dynamic aspect of the page. She just has to use the same editor as for static pages, be it DW, FrontPage, whatever.
But Cocoon adds more value to this: from my own experience (related to the people's skills in my company), most pages in a webapp are designed by people that know the application domain and are therefore more often developpers than web designers.
I think that's the question: Is it about application development or design?
Sun targets the 'Corporate Programmer' with its new generation of tools (Rave) in order to compete with M$ Forms and M$ Visual Basic. And, the more I think about it the more I doubt whether the programmer or their managers are the target group of Sun ...
Yep. The target is the manager for sure ;-)
In this organisation, the work of the web designer is to produce a "skin" that gives some styling for all graphical layouts used throughout the application. That skin is then translated to XSLT (+CSS). The page developper then only has to write very basic HTML (page structure) that is fed into the skinning XSLT to add all the fancy graphical layout.
Result: productivity boost and ability to have multiple skins (and to some extent multiple channels). It's called "SoC" I guess... ;-)
The pros and cons of Cocoon are:
+ multi-channel publishing + skinnable + more easily maintainable
- WYSIWIG publishing not possible (or only with some limitations)
Mmmh... rather the contrary: with dynamically produced templates, we can go way further in the WYSIWIG domain that every other templating technology, simply because using a simple XSL we can produce a template from any kind of source.
If we don't have WYSIWIG now, it's just that it wasn't itching enough for us to scratch ;-)
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
