cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Fagerstrom" <daniel.fagerst...@swipnet.se>
Subject RE: [RT] Forms and wizards (was: RE: HEADS UP - cocoon form handling (long!!))
Date Tue, 16 Apr 2002 23:40:30 GMT
Ovidiu Predescu wrote:
<snip/>
> The approach here and the one you describe are similar in
> functionality and shortcomings. The above version is much cleaner IMO,
> as it removes the flow of the application from the sitemap.
Yes, from a flow perspective they do about the same thing. From an input
handling perspective they do not, the main topic in my post was how to
handle XML-input, and your example don't. Handling XML-input might not be an
important use of Cocoon right now for most people. But with the growing
popularity of SOAP, XML-RPC, WebDAV, and more specialized XML-based
protocols, I think it will be an important use of Cocoon, or at least it can
be if we find it worthwhile to provide good tools for it. In my experience
form handling becomes much cleaner if one transform the form input to xml as
the first step while handling input. We have build webapps along the lines I
described for nearly a year at the company I work for, we have also tried
the action based approach, and it is so much more productive to use
XML-input.

Ok, suppose that we want to use XML input, then we might want to do thing
like: validate it, transform it to another format, store it, present it,
send it to an application and so on. Many of these operations have XML both
as input and output, it is of course possible to glue such operations
together in Java or JavaScript or to use Actions, but IMO it is much cleaner
to connect the operations together as a pipeline. By doing this we can also
reuse all the existing pipeline components in cocoon, and one can manage
fairly complex input handling without needing to write any program code. Do
you think it would be possible to connect "input"-pipelines to Schecoon?

> The syntax
> is much easier to read, and since we use a full programming language,
> there's no need to modify the sitemap engine to add new constructs as
> needs evolve. Just write a new JavaScript function, or create a Java
> class which you can call from the control layer.
Ever heard about FS ;) The great strength with Cocoon as a publishing
framework is that it uses a few, very carefully chosen concepts, and by
using these few concepts one can easily build sites that would be so much
harder to build in e.g. JSP. Why should we use the opposite strategy and
give the users full flexibility but no guiding in the flow handling case?
Isn't our task to develop the concepts that makes building webapps easy, I
found it hard to believe that the best answer is: introduce a full
programming language.

I believe that continuations is one of the concepts that are going to make
webapps easy, but I think we have to be very careful about what kind of
continuations we should use.

I think the best way to keep focus on what is important and avoiding the
temptations of FS, is to evaluate the new ideas against realistic use cases.
In our earlier discussion, we evaluated how to use continuations for a
shopping site. In the shopping site examples there are (at least) two
classes of user interactions: managing the shopping cart and the checkout
sequence. In booth cases we found that using full continuations would lead
to unwanted behavior of the application. After all, having several parallel
instances of the shopping basket with different content would be rather
confusing. I would also be frustrating if you, if you go back and change
some data in the first page in a checkout sequence, after having filled in
the rest, and find that everything you wrote in the rest of the pages are
gone. You solved this by adding shared global variables, and the
sendPageAndContinue function and continuation passing style.

Now I wonder, where are the realistic and important use cases where we
really need the full continuation machinery and all the extra complexiy and
storage requirements that it introduces?

> Also I think it's a
> lot easier for new users to come up to speed on such an approach,
> compared to the similar sitemap-based implementation.
Maybe, when I taught about continuations in computer science courses a
number of years ago, I never got the impression that people found
continuations easy to grasp ;), maybe it was just a defect in my teaching
skills.

> Of course the same scenario might be implemented in the control flow
> layer using full continuations, in which case the implementation would
> be a little different, since everything could be written in one
> function.
Please show how, and describe how to make it possible to go back and make
changes in early pages without losing the content of the ones after.

> As you notice, there are some differences in how a developer thinks
> when describing the flow using a continuations based approach and when
> the classical one is used. But you're free to choose the option that
> fits you best, the control flow layer gives you this flexibility. You
> can even mix and match in the same implementation to use continuations
> for one portion, and the session state for the rest.
So if I write "what if" scenarios I can do it in a really elegant and neat
way. And if I write more conventional webapps, I should by all means avoid
storing important data in local variables and I have to program continuation
passing style, which is less neat. Is this really the right priority order
between the use cases?

/Daniel Fagerstrom



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


Mime
View raw message