1 Dec 2003 01:50
Re: Nested flowscripts
Steinar Jonsson <sjonsson <at> online.no>
2003-12-01 00:50:29 GMT
2003-12-01 00:50:29 GMT
On Friday 28 November 2003 09:58, Christian Hoofe wrote: > From: Steinar Jonsson <sjonsson <at> online.no> > > >Subject: Nested flowscripts > >Newsgroups: gmane.text.xml.cocoon.user > >Date: Wed, 26 Nov 2003 20:40:13 +0100 > > > >I have a flowscript that does a sendPageAndWait( request ), > >and the request happens to start a second flowscript. > > > >When that second flowscript has completed its work, > >how do I return to where the first one left off? > > Try: > > // save the actual continuation object > var scriptCont = cocoon.continuation; > > cocoon.sendPageAndWait(...); > > // reset the original continuation object > cocoon.continuation = scriptCont; > > This worked for a Woody-Form call instead of cocoon.sendPageAndWait() in > my flowscript program. This is a result of trial and error may be someone > knows a better solutions. I found nothing in the documentation. > Couldn't get that to work, cocoon.continuation is undefined.(Continue reading)
So I am finding.
>>> and am wondering if we
>>>should provide a _second_, less powerful but simpler interface to esql:
>>> [...snip...]
>>>Thoughts?
>>>
>>> Chris.
>>
>>The <esql:row-results> approach took me a little time to get my head
>>around - and the alternative syntax is a good deal simpler. Would this be
>>an alternative syntax, with the old syntax still supported?
>
>It's not really "old" vs "new" -- it would be an additional tag that
>would expand to the very same code as the current combination. Hence,
>it could be fully combined with all other esql tags that may appear
>inside a esql:row-results. Well, that would be the plan.
Ok, in that case it sounds useful.
>>Unless you can mix the old and new code together, though, this represents
>>yet another choice between simplicity and power, of which there are
>>several already 
>
>Indeed. But maybe the current ESQL usage is a little too complex to just
>list the contents of a table?
I didn't find it so, but then I'm reasonably familiar with SQL.
>>To be honest, I don't have a problem with embedding SQL SELECTs directly
>>into the XSP or logicsheet. The row-results logic, once grasped, is also
>>straightforward enough. More of an issue is the insert/update/delete
>>logic. In your GT2003 slides, IIUC, you recommended against doing these
>>using ESQL or SQLTransformer: this is my instinct also, but what are your
>>reasons? And could these problems be overcome by an alternate "simple
>>ESQL" interface? If so, that would to me make a more compelling reason
>>for an "ESQL Simple" interface.
>
>Nope. What I don't like about manipulating tables from XSP is that a)
>application logic appears on the page
Agreed - generally horrid.
> b) different results (eg errors)
>lead to different pages or ask for redirects which makes the pages too
>complex to maintain.
You mean the process flow is defined within XSPs? Ok, I can see this is a
problem.
>Actions are a good step in the right direction if used correctly.
>
>Honestly, the flow + o/r apprach is so much more elegant for complex
>logic. Especially if you add CocoonForms aka Woody to it.
I'll check this out more carefully.
>>Cocoon has the best architecture I've worked with for a very long time -
>>thanks for all your work.
>
>Thank you! Now go and spread the word 
RSS Feed