You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Andreas Hochsteger <e9...@student.tuwien.ac.at> on 2003/03/15 08:31:01 UTC
Flows with Jelly as backend?
Hi everybody!
I wonder if anybody ever looked at jelly:
http://jakarta.apache.org/commons/sandbox/jelly/
I found a hint to it in the Wyona/Lenya users mailing list.
It consists of an XML syntax and a tool wich interprets the XML documents and
it seems to be similar to the way ant works.
Would it in your opinion make sense to support it as backend for Cocoon flow
like this is the case now for JavaScript?
Bye,
Andreas Hochsteger
Re: Flows with Jelly as backend?
Posted by Andreas Hochsteger <e9...@student.tuwien.ac.at>.
On Saturday 15 March 2003 13:56, Stefano Mazzocchi wrote:
> Andreas Hochsteger wrote:
> > Hi everybody!
> >
> > I wonder if anybody ever looked at jelly:
> > http://jakarta.apache.org/commons/sandbox/jelly/
> >
> > I found a hint to it in the Wyona/Lenya users mailing list.
> > It consists of an XML syntax and a tool wich interprets the XML documents
> > and it seems to be similar to the way ant works.
> >
> > Would it in your opinion make sense to support it as backend for Cocoon
> > flow like this is the case now for JavaScript?
>
> 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.
That's what I wanted to know, thanks.
Since I just discovered Jelly, I didn't know, if it's suitable for Cocoon.
> Moreover, it doesn't add continuation support so it could be no
> replacement for the flow, but just a different way to write actions.
>
> Interesting timing, BTW, as we are discussing the ability for people to
> plug new sitemap tags.
>
> Imagine having jelly inside the sitemap.
>
> Brrr, scary.
I have to agree ;-)
Is it generally acceptable to support XML-based process modelling
standards in the future, which don't lead that easy to the misuse of flow
functionality for things which should be better implemented in an other way?
Are there any requirements for such a language, which you can speak out
(besides an implementation which supports continuations), to consider them
for integration or support within Cocoon?
Here is an (incomplete) list of XML-based process/workflow modeling
standards which are currently available or in development:
* BPEL4WS - Business Process Execution Language for Web Services (Bea,IBM,MS)
http://www-106.ibm.com/developerworks/webservices/library/ws-bpel/
* BPML - Business Process Modeling Language (BPMI)
http://www.bpmi.org/bpml.esp
* ebBPSS - ebXML Business Process Specification Schema (ebXML.org)
http://www.ebxml.org/specs/ebBPSS.pdf
* PIP - Partner Interface Process (RossetaNet)
http://www.rosettanet.org/rosettanet/standards/
* UML - Unified Modeling Language (OMG)
http://www.omg.org/technology/documents/formal/uml.htm
* WSCL - Web Services Conversation Language (W3C)
http://www.w3.org/TR/wscl10/
* XPDL - XML Process Definition Language (WfMC)
http://www.wfmc.org/standards/docs.htm
Further information:
* XML-Based Workflow and Process Management Standards: XPDL, Wf-XML
http://xml.coverpages.org/wf-xml.html
* Still no universal workflow
http://www.nwfusion.com/columnists/2002/0701kobielus.html
* XML business-process model ready for release
http://www.itworld.com/Tech/2406/ITW030701xml/
Perhaps you can comment on them to help those, which don't have that deep
knowledge of Cocoon internals, to better see the big picture about where
Cocoon will go in the future.
Awaiting your comments,
Andreas Hochsteger
Re: Jelly as MarkupLanguage Was Re: Flows with Jelly as backend?
Posted by Stefano Mazzocchi <st...@apache.org>.
Bernhard Huber wrote:
> <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.
Re: Jelly as MarkupLanguage Was Re: Flows with Jelly as backend?
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 15/3/03 14:37, "Bernhard Huber" <be...@a1.net> wrote:
> <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
Small, fast, and does the trick...
http://www.mycgiserver.com/~thinlet/
Oh, and it's 28 KB overall! :-) :-)
Pier
Jelly as MarkupLanguage Was Re: Flows with Jelly as backend?
Posted by Bernhard Huber <be...@a1.net>.
<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
Re: Flows with Jelly as backend?
Posted by Stefano Mazzocchi <st...@apache.org>.
Andreas Hochsteger wrote:
> Hi everybody!
>
> I wonder if anybody ever looked at jelly:
> http://jakarta.apache.org/commons/sandbox/jelly/
>
> I found a hint to it in the Wyona/Lenya users mailing list.
> It consists of an XML syntax and a tool wich interprets the XML documents and
> it seems to be similar to the way ant works.
>
> Would it in your opinion make sense to support it as backend for Cocoon flow
> like this is the case now for JavaScript?
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.
Moreover, it doesn't add continuation support so it could be no
replacement for the flow, but just a different way to write actions.
Interesting timing, BTW, as we are discussing the ability for people to
plug new sitemap tags.
Imagine having jelly inside the sitemap.
Brrr, scary.