<snip/>
I would personally dislike this option because Jelly is rewriting a programming language using a markup language syntax, which is, IMHO, a very bad thing to do.
Well, disliking Jelly on the ServerSide I think Jelly-Swing on the client-side
would be a quite interesting option.
Not using a standard-HTML browser but a Java-Swing-Jelly application receiving
its UI from Cocoon as Jelly-Swing XML.
I think that would quite interesting, and to some sort quite flexible
I'm talking on the context of flow replacement, I don't mean to judge Jelly in any other way.
Stefano.
