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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
