Andrew C. Oliver wrote: > Stefano Mazzocchi wrote: > >Ok. Here's my vision: a flowscript is the location where you place your > >flow logic. The flow logic is the collection of instructions that > >indicate how to make the transition from one page to another. > > > >Everything else shouldn't be there. > > > So why do you need scripting for that? It seems inconsonant with the > rest of Cocoon and even unnecessary.
Agree, if flowscripts only are supposed to be used for flow logic and not for writing complete webapps, the use of JavaScript seem like _massive_ FS to me. > There is relatively minor difference between what XSLT does (match > conditions and output a result) and > what the flowscript does and the sitemap and what the flowscript does. > The gap is I suppose a mid sitemap > decision on what the next step should be, therefore, why can the sitemap > not be extended with minor conditionals > similar to the ones in XSLT and make flow decisions in XML versus > Javascript. I described how to add some minimal flow handling mechanisms to the sitemap in the last sections of http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101882151416705&w=2. The proposal is based on a _very_ light weight kind of continuation passing. As the few commenter seemed to hate the use of xml to describe flow logic and the inclusion of flow logic in the sitemap, maybe I should add that one of course could describe the same concepts in a different syntax and in a separate (flow description) file. > I regard this flowmap decision as taramount to multiple inheritance. I > think its a decision that will later come to be > regretted. I also think I'll be seeing Cocoon applications that are > virtually implemented exclusively in Javascript instead > of using the sitemap at all. I don't know if it is a good or a bad decision (or even if there have been a decision yet ;) ), to adopt flowscripts. I'm quite surprised that there have been so little discussion about what they are supposed to be used for. I guess most people agree about that flowscripts should describe the flow aspect of webapps, but such a general view doesn't help design much. IMO we need to be more concrete about the use cases for flowscripts. Without a common view on what problem they are supposed to solve, it is hard to know if a certain technical solution is good or not. So what use cases do we have? * It should definitely be easy to write wizards in a flow description language. I believe this is the case for flowscripts (see http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102052662705449&w=2, for details), but on the other hand this could be done in a much smaller and more specialized language. Ivelin and Torsten listed some requirements for wizards, IIRC. * Shopping carts? This will be possible when Ovidiu (or someone else) have added variables that are accessible across different flowscript invocations. * Anything more? <snip/> > >No, no, no. With this you are assuming that it's equivalent to use a > >scripting language to describe business logic. This is yet to be > >discussed, but this is an entirely different concern from this > >discussion, thus my call to stop it until we have finished focusing on > >the flowscript. AFAIK Ovidiu have always advertised flowscripts as a language for writing webapps in, which is far more general than just describing flow logic. As flowscripts can, and most probably, will be used for writing complete webapps, I can't see that the business logic and the flow description are different concerns. Keeping the concerns separated at this stage means that we decide to just discuss "if", "when", "for", "case" and the like in Javascript and don't care about the effects of introducing all the other parts of the language. If we really want to focus on the flow aspect, it is IMO premature to assume that flowscripts is the right solution, before we know what problem we want to solve. /Daniel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
