You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Ivelin Ivanov <iv...@apache.org> on 2002/12/08 21:59:03 UTC

Re: [Proposal] JS Flow vs Actions [was: Implementing XMLForm with Flow]

----- Original Message -----
From: "Christopher Oliver" <re...@verizon.net>
To: <co...@xml.apache.org>
Sent: Sunday, December 08, 2002 1:19 PM
Subject: Re: [Proposal] Implementing XMLForm with Flow


> Uh, how useful is it to insist that something be fully implemented to
> prove a point in a discussion on a mailing list?

Only to the point where we can compare apples to apples.

>The purpose of my
> example was to show that the flow layer allows you to avoid the
> state-machine code required in XMLForm actions (which is what you
> questioned in your original message), not to implement all of the
> details of your example.

Why call them XMLForm actions?
Actions are an independent part of Cocoon. They were around long before
the XMLForm components were added.
I think that for now, XMLForm as a means of handling input can be left out
of the discussion
of workflow logic.

<snip stuff that I am cool with/>

> I'm also a little surprised you don't seem to want a flow layer based
> interface to XMLForm.

Absolutely not the case. I don't know why it came across that way.

>Personally, I think it could enhance the usability
> and value of that component (by replacing the action handling code -
> with the flow layer - but retaining the rest of its current
functionality).

This thread is about finding the general area of usability of the js flow,
isn't it?
At some point we will hopefully reach a point where we agree on some best
practices,
just like we mostly agree when XSLT should be used instead of Java.


Cheers,

Ivelin



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org