Daniel Fagerstrom wrote: > > 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.
Hmmm, I wish I was allowed to send you my 58Kb sitemap used to control the flow of 4 URI familites (4 mathers)! Anyway, that sitemap had 12 levels of nesting, matchers with 110 lines each and I had to write a special transformer and 4 different actions. Actions that were 10/15 lines each. With the flowscript, I estimate to be able to refactor the entire thing in a third of the sitemap code, no actions and a few Kbs of javascript. And there is no business logic whatsoever there, just page transitions based on system status (the entire business logic is contained in java objects). Now matter what, it will be hard to convince me that using the XML syntax is a good idea to describe simple procedural logic. > > 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. Hmmm, I think I missed this. I'll go over it again. > 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 would not be against this, just I think Javascript is the best compromise so far because it doesn't force people to learn a new syntax. > > 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. Good point. > 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? what? is your web-app world limited to multi-pages and shoppint carts? I can believe that. No wonder why you think that the flowscript is FS. For those things it might well be. Think granular: you are talking about 'pieces' of web applications. I'm talking about web applications all together. Think of a on-line banking system, think of a webmail, a calendar, an administrative intranet, a revision control system for air-2-air NATO missiles platform spare parts (yes, I did consulting for that once!) There is no need to write a flow for something so simple as a data-entry wizard or a shopping cart. In fact, those are *exactly* those webapp components where flows can be standardized and reused with little hassle. But I'm talking about the webapps: suppose you are hired by a company that does this revision control system for missiles platforms. It's a huge military system that connects to spare part databases located around the planet, thru kick-ass crypto extranets, you have vector parts transformed into VRML2 and you can know who, when, why and how changed the spare part 3849484984489 of that missile. Now, suppose you want to *understand* what's going on: how you move from page A to page B and why, what can errors are catched, what things can go wrong, what is called to obtain this data and how. You *do* *not* care *HOW* the pages are created. First thing you want to find out is how the system behaves. And 'web app behavior' is the description of the flow, not the description of the sitemap. So, your learning process would be something like: 1) use the webapp [learn cocoon] (optional if you already know this) 2) learn the flowscript 3) learn the sitemap Believe me: today there is *NO* web technology that allows this simple course of action to get productive on a system, or to estimate in a short term the complexity of the system in question. > <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. Hmm, we might be having a terminology impedence mismatch here. I call 'flow logic' the logic that describes the transition between states of a web application (sometimes these states map to changes in pages, sometimes they do not, but the state changes). In this sense, a flow logic is a white box. I call 'business logic' the logic that describes how data is created, handled, managed, kept secure, consistent, persistent. In this sense, a business logic is a black box. Example: a webmail is a web application that shows a web view of a mail server. The business logic is the 'mail server abstraction'. The objects you call to get access to the underlying data. In case of an IMAP server, this is a think layer that makes a client IMAP, in case of a POP server, the layer is bigger because it has to simulate the mail repository. The flow layer simply connects the web layer to the underlying business object layer. It might become quite a complex logic, but the 'juicy' mail-related logic is contained in the underlying model. Nobody stops you from writing everything (even the mail business logic) inside the flowscript, just like nobody forces you to use object orientation in Java (you can have one single class to do everything!), but this doesn't mean that OO for Java is FS. > 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. Hope the above definition of the terminology explains my vision better because I think that writing a complex business logic using the flowscript would be such an evident suicide that it would be our fault if someone does it. > 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. I know what problems I want to solve: the sitemap poorely describes procedural flow logic. So far, I've not seen any better solution than the flowscript. As far as the 'SpitScript' and this thread: writing business logic (as I defined it above) in the flowscript is such an evidently terrible idea that I don't even think it's worth talking about it at this point. It's like stating that map:readers lead to FS becase you could write an entire cocoon replacer as a reader. -- Stefano Mazzocchi One must still have chaos in oneself to be able to give birth to a dancing star. <[EMAIL PROTECTED]> Friedrich Nietzsche -------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
