Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Message-ID: <003101c0a0da$0e916c20$d77c07d5@hubert>
From: "Sven Kuenzler" <svenk@gmx.net>
To: <cocoon-dev@xml.apache.org>
References: <003501c0a0ac$a352b720$307d07d5@hubert>
 <3A9BADA5.77D80B24@apache.org>
Subject: WebWork (was: Re: [ot] XSLT pain in the *?)
Date: Tue, 27 Feb 2001 17:26:20 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

> To be clarified it is mostly in the context of writing logicsheets.  XSP
is
> a cool technology, however trying to write an XSP LogicSheet is a pain in
the
> hind end because of the XSLT semantics.

OK. As I stated in another post, this was not my concern when asking for
XSLT challenges.

But as XSLT on the logic side seems to be considered a problem, I'd like to
take the opportunity to point out to  another approach we've been testing
independently from Cocoon. It's an open source project called "Webwork"
(http://sourceforge.net/projects/webwork/), originating from the JBoss
community.

<disclaimer>
I am just starting to understand the problem space called "web apps". The
action pattern used in Webwork is something new to me. However, the Webwork
people often compare their work to Struts. Thus, it's possible that I'm
trying to sell really "old news" to you.
</disclaimer>

Besides other things, WebWork provides a contract between  Java Beans and
JSP. For WebWork, "Actions" are JavaBeans with an execute() method. This
execute() is  used to populate the beans' properties. Such an Action has
different views associated with it. These are either Actions themselves or
JSPs.  Those JSPs are able to access its Actions' properties via the WebWork
tag lib. Additionally, the JSP can instantiate more Action Beans and access
their properties.

<disclaimer>
The Webwork taglib can do more things which esp. you Cocoon2-guys won't like
(include other JSPs, eval boolean expressions, ...). When looking at the
WebWork tutorial, focus on the tags <ww:bean>, <ww:property> and
<ww:iterator>. They provide the functionality I am talking about.
</disclaimer>

My question is whether such a taglib would be a useful thing to have for
Cocoon2. It could serve as contract between logic and content, sparing the
"logic department" from XSL logicsheets. What would be the limitations of
such an approach?

    Sven....