RE: [RT] Use of flowscript or the pyramid of contracts (was Re: [RT] Checked exceptions considered harmful)

[Tim Olson]

> > we already have a nice system of flow helper methods to 
> access entity beans
> > and pump them into XML.  we use flow to select which 
> components are needed
> > when, and the contract with our GUI designers is XML.  we 
> were already burnt
> > quite badly when sendPage() became a requirement, since we 
> were using flow
> > to merely select actions and the sitemap had all of our 
> branching.  we are
> > now unable to upgrade past 2.1.2 without major refactoring 
> which honestly we
> > can't afford to do.
> > you theoreticians seem all too willing to break production 
> systems to
> > enforce your latest notion of best practices.
> 
> Tim, don't take the word for everything said in a RT thread and don't 
> worry that access to Java will be disabled in the 2.x branch 
> (if ever) 
> as this certainly would break any production system running 
> on with flow.

sorry to be so sensitive.  i still have a bad taste from the exception being
thrown if no sendPage() is present.

RE: [RT] Use of flowscript or the pyramid of contracts (was Re: [RT] Checked exceptions considered harmful)

[Tim Olson]

> > Yes, we habe FOM. The difference to the sitemap is that the sitemap 
> > enforces the contract while flow doesn't.
> 
> One drastic approach would be to stop flow from being able to access 
> java at all, if not thru FOM. I would be in favor of that 
> once we have 
> the real block system running, but at that point it might 
> well be too late.

we already have a nice system of flow helper methods to access entity beans
and pump them into XML.  we use flow to select which components are needed
when, and the contract with our GUI designers is XML.  we were already burnt
quite badly when sendPage() became a requirement, since we were using flow
to merely select actions and the sitemap had all of our branching.  we are
now unable to upgrade past 2.1.2 without major refactoring which honestly we
can't afford to do.
you theoreticians seem all too willing to break production systems to
enforce your latest notion of best practices.

RE: Internet Explorer 6.0 cocoon reader PDF defect?

[Tim Olson]

do you get a "Page Cannot Be Displayed"?

> -Original Message-
> From: depub2 [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, March 30, 2004 1:33 AM
> To: [EMAIL PROTECTED]
> Subject: Internet Explorer 6.0 cocoon reader PDF defect?
> 
> 
> I am unable to get MS IE 6.0 to display a PDF file that
> comes from a reader. It works fine when using the fo2pdf
> serializer, but I need to use the reader to read a file.
> 
> The following sitemap excerpt behaves nicely with Mozilla
> and MS IE 5.5; BUT NOT MS IE 6.0.
> 
> 
>   
> 
> 
> Using cocoon 2.1.4 release.
> 
> Help!! What's the problem??
> 
> David
> 
> 

RE: FlowScript in 2.1.5-dev has gone tango uniform

[Tim Olson]

i've noticed this problem in 2.1.2 and was someday going to have time to
make a test case & bug report.

we use flowscript in subsitemaps only (not the root sitemap) and cocoon
appears to only load the .js files listed in the first subsitemap requested.
subsequent requests to other subsitemaps do not load the accompanying script
files and you get a "function not found".
we had to work around this problem by listing all .js files in all
subsitemaps (painful)


> -Original Message-
> From: Jeremy Quinn [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, March 03, 2004 5:52 AM
> To: [EMAIL PROTECTED]
> Subject: Re: FlowScript in 2.1.5-dev has gone tango uniform
> 
> 
> 
> On 2 Mar 2004, at 21:59, Sylvain Wallez wrote:
> 
> > Jeremy Quinn wrote:
> >
> >>
> >> On 2 Mar 2004, at 18:42, Jeremy Quinn wrote:
> >>
> >>> To restate the basic problem :
> >>>
> >>> I have 2 URLs each served by a different sub-sitemap, 
> each loading a 
> >>> different (single) flowscript. Each flowscript has some common 
> >>> function names, eg. index(). For debugging purposes, each 
> function 
> >>> outputs it's name etc. to the flow log.
> >>>
> >>> load URL 1 : the correct script and function run fine
> >>> load URL 2 : the same-named function in the flowscript 
> file for URL 
> >>> 1 runs.
> >>>
> >>
> >> Some further info:
> >>
> >> Rolling back to Cocoon 2.1.4 Release, has fixed the problem.
> >
> >
> > I made changes to flowscript after 2.1.4 to remove the 
> dependency of 
> > flowscript on Environment (it now uses only the 
> Redirector). This led 
> > to changing the key used to store global scopes in the session (see 
> > FOM_JavaScriptInterpreter.getSessionScope()), but I don't 
> know how it 
> > can produce what you encounter.
> >
> > I'll give a look at this tomorrow.
> 
> Many thanks Sylvain.
> 
> It appears like the first FlowScript that gets used, is the only 
> FlowScript that gets used.
> 
> regards Jeremy
> 

RE: [vote] forbidding flowscripts with no sendpage redirects (was Re: Saving pipeline output to a temp file...)

[Tim Olson]

> Tim Olson wrote:
> > 
> >   
> >   
> >   
> >   
> >   
> >   
> > 
> 
>   
> 
>   
> 
>   
> 
> 
> 
>   
> 
> function dumpData() {
>dumpUserData();
>dumpOrderData();
>dumpNewsItems();
>cocoon.sendPage("view");
> }
> 
>   Ugo

i thought the original intention was to make the flow clearer?  now we have
three blocks of code to follow instead of one...

stefano's suggestion of
>   
>
> 
> 
> 
>
>   
> 
>   
>
> 
>  
> 
>
>   
> 
> function main(action) {
>  func = this[action];
>  if (func != undefined) func.apply(this,args);
>  cocoon.sendPage("screen/" + action);
> }

is cleaner but we have many pages which need no backend data, only "simple"
xsl of our standard xml stream, so we would now have to write empty
javascript "flow controllers" for these pages.

throwing an exception for a case which works fine seems very heavy-handed to
me.  wouldn't a warning in the log suffice?  how about making the error
throwing configurable?
it pains me that our site will have to make significant refactorings,
increasing the complexity and verbosity of our code, to accomodate what
seems to me to be a stylistic decision facistly enforced, because some user
somewhere doesn't know that a map:call might not return.

RE: [vote] forbidding flowscripts with no sendpage redirects (was Re: Saving pipeline output to a temp file...)

[Tim Olson]

sorry i'm so late in commenting on this but
please NO NO NO!

we are using javascript not as a flow engine but as a simple scripting
controller.  we have one main pipeline which does auth, i18n, etc, and which
calls specific pipeline fragments for each page.  typical subsitemap code
looks like


  
  
  
  




function dumpUserData()
{
  userID = util.getRequestParam("userID") - 0
  userHome = util.lookupHome("User")
  user = userHome.findByPrimaryKey(userID)
  util.set( "user", user.getValueObject() )
}


our generator is generic and takes the values set by the utility object and
marshalls them into XML which is fed to the XSLT...

by enforcing the use of sendPage(), you would force us to break all of our
subsitemap blocks into two pieces


  



  
  
  


(with the addition of sendPage("edit2") in our javascript)


this is heinous and unnecessarily complicates our nice structure.

also, we have cases where we call several javascript controller modules to
get various data needed by the xslt:


  
  
  
  
  
  


currently, we can easily tack on a javascript module to add XML data to the
transformation pipeline, but how could this work if every js was required to
sendPage()?  it makes our usage pattern seem impossible, but we find this
way of using javascript to be quite wonderful, and quite independent of flow
concerns.



> -Original Message-
> From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, November 11, 2003 5:00 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [vote] forbidding flowscripts with no sendpage redirects
> (was Re: Saving pipeline output to a temp file...)
> 
> 
> Sylvain Wallez wrote:
> 
> > Let's reformulate this into a proper vote.
> >
> > Do you want to enforce the fact that flowscript calls (either 
> > "function" or "continuation") *must* redirect using sendPage, 
> > sendPageAndWait or redirectTo and that, should it not be 
> the case, a 
> > ProcessingException be raised?
> 
> 
> So far, we have the following results :
> 
> 8 votes to enforce it in 2.1.3,
> 1 vote to enforce it in 2.1.4,
> and a "-0" and "-0.5" on enforcing (Vadim and Geoff)
> 
> So, the community has decided that this should be enforced 
> sooner than 
> later. Quoting Antonio, "earlier means less pain in the future".
> 
> I just committed the patch. Samples seem to behave correctly. Please 
> cross-check.
> 
> Sylvain
> 
> -- 
> Sylvain Wallez  Anyware Technologies
> http://www.apache.org/~sylvain   http://www.anyware-tech.com
> { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
> Orixo, the opensource XML business alliance  -  http://www.orixo.com
> 
> 

RE: DO NOT REPLY [Bug 24571] New: - Content-Length header missi ng

[Tim Olson]

could i beg anyone to pick this up?  we're dead-in-the-water with our
current development because our java applet can't read the cocoon-generated
XML due to a missing content-length header.  it took a couple weeks to debug
it to this point, and i'll be looking at the cocoon source to see what i can
find but i don't really know my way around it.
both the xml & http serializers exhibit this problem so either they're both
buggy or it's part of a post-serialize step?


> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Monday, November 10, 2003 12:43 PM
> To: [EMAIL PROTECTED]
> Subject: DO NOT REPLY [Bug 24571] New: - Content-Length header missing
> 
> 
> DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
> RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
> .
> ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
> INSERTED IN THE BUG DATABASE.
> 
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24571
> 
> Content-Length header missing
> 
>Summary: Content-Length header missing
>Product: Cocoon 2
>Version: 2.1.2
>   Platform: PC
> OS/Version: Windows NT/2K
> Status: NEW
>   Severity: Normal
>   Priority: Other
>  Component: sitemap components
> AssignedTo: [EMAIL PROTECTED]
> ReportedBy: [EMAIL PROTECTED]
> 
> 
> with the following sitemap:
> 
> 
>   
> 
> 
> 
>   
>   
> 
> 
> 
> config1 returns:
> 
> HTTP/1.1 200 OK
> X-Cocoon-Version: 2.1.2
> Last-Modified: Mon, 10 Nov 2003 17:22:35 GMT
> Content-Type: text/xml
> Content-Length: 1038
> Date: Mon, 10 Nov 2003 17:29:25 GMT
> Server: Apache Coyote/1.0
> Connection: close
> 
> 
> while config2 returns no Content-Length, which is required by 
> the HTTP 1.1 spec:
> 
> HTTP/1.1 200 OK
> X-Cocoon-Version: 2.1.2
> Content-Type: text/xml
> Date: Mon, 10 Nov 2003 17:25:55 GMT
> Server: Apache Coyote/1.0
> Connection: close
> 
> 
> if you use a caching pipeline, cached requests will return a 
> correct Content-
> Length but touching the source file invalidates the cache and 
> shows the missing 
> Content-Length behavior again.
> the reader gives the correct content-length even when caching 
> is disabled.
> 
> this bug is more severe than it sounds, because java socket 
> code that reads 
> from the generated (no content-length) URL may terminate 
> before the entire 
> stream is read (if the content is large enough)
> 

RE: NPE While Redirecting

[Tim Olson]

oops, it actually does have a serializer which i accidentally clipped off
when removing an extraneous transform

> -Original Message-
> From: Unico Hommes [mailto:[EMAIL PROTECTED]
> Sent: Monday, October 20, 2003 6:10 PM
> To: [EMAIL PROTECTED]
> Subject: RE: NPE While Redirecting
> 
> 
> 
> 
> One thing I can see right away is that the fullPipe pipeline 
> is missing
> a serializer. All valid pipelines have at least one generator and one
> serializer. Calling a subpipeline using the cocoon: protocol will then
> connect the pipeline component to the subpipeline minus the 
> serializer.
> 
> Hope that helps.
> 
> > -Original Message-
> > From: Tim Olson [mailto:[EMAIL PROTECTED]
> > Sent: maandag 20 oktober 2003 23:29
> > To: '[EMAIL PROTECTED]'
> > Cc: '[EMAIL PROTECTED]'
> > Subject: NPE While Redirecting
> > 
> > we get a NullPointerException for any  that gets called
> in
> > our
> > subsitemap.  i presume this is because a  has
> been
> > called, but we must use the "cocoon:" protocol in order to 
> divide our
> > pipeline into a main pipe which calls down into page-specific
> fragments.
> > no
> > "actual" generation has happened before the redirect.
> > is this NPE fixable?  if not, how else can we organize our pipelines
> into
> > per-page sitemaps?  resources don't work because they can't 
> be called
> from
> > a
> > subsitemap.
> > using cocoon 2.1.2
> > 
> > 
> > MAIN SITEMAP:
> > 
> > 
> > 
> > 
> > 
> > 
> >   
> > 
> > 
> >   
> >   
> > 
> > 
> >> label="banner">
> > 
> >   
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> >  > src="{global:xsl-root}/common/{2}/{2}.xmap" 
> uri-prefix="subsitemap"/>
> > 
> > 
> > 
> > SUBSITEMAP:
> > 
> > 
> > 
> > 
> > 
> > 
> > Original Exception: java.lang.NullPointerException
> > at
> >
> org.apache.cocoon.environment.AbstractEnvironment.release(Abst
> ractEnviro
> nm
> > en
> > t.java:521)
> > at
> >
> org.apache.cocoon.environment.wrapper.MutableEnvironmentFacade
> .release(M
> ut
> > ab
> > leEnvironmentFacade.java:332)
> > at
> >
> org.apache.cocoon.components.source.impl.SitemapSource.reset(S
> itemapSour
> ce
> > .j
> > ava:495)
> > at
> >
> org.apache.cocoon.components.source.impl.SitemapSource.toSAX(S
> itemapSour
> ce
> > .j
> > ava:480)
> > at
> >
> org.apache.cocoon.components.source.SourceUtil.parse(SourceUti
> l.java:224
> )
> > at
> >
> org.apache.cocoon.generation.FileGenerator.generate(FileGenera
> tor.java:1
> 41
> > )
> > at
> >
> org.apache.cocoon.components.pipeline.AbstractProcessingPipeli
> ne.process
> XM
> > LP
> > ipeline(AbstractProcessingPipeline.java:532)
> > at
> >
> org.apache.cocoon.components.pipeline.impl.AbstractCachingProc
> essingPipe
> li
> > ne
> > .processXMLPipeline(AbstractCachingProcessingPipeline.java:196)
> > at
> >
> org.apache.cocoon.components.pipeline.AbstractProcessingPipeli
> ne.process
> (A
> > bs
> > tractProcessingPipeline.java:683)
> > at
> >
> org.apache.cocoon.components.source.impl.SitemapSource.toSAX(S
> itemapSour
> ce
> > .j
> > ava:467)
> > at
> >
> org.apache.cocoon.components.source.SourceUtil.parse(SourceUti
> l.java:224
> )
> > at
> >
> org.apache.cocoon.generation.FileGenerator.generate(FileGenera
> tor.java:1
> 41
> > )
> > at
> >
> org.apache.cocoon.components.pipeline.AbstractProcessingPipeli
> ne.process
> XM
> > LP
> > ipeline(AbstractProcessingPipeline.java:548)
> > at
> >
> org.apache.cocoon.components.pipeline.impl.AbstractCachingProc
> essingPipe
> li
> > ne
> > .processXMLPipeline(AbstractCachingProcessingPipeline.java:196)
> > at
> >
> org.apache.cocoon.components.pipeline.AbstractProcessingPipeli
> ne.process
> (A
> > bs
> > tractProcessingPipeline.java:492)
> > at
> >
> org.apache.cocoon.components.treeprocessor.sitemap.SerializeNo
> de.invoke(
> Se
> 

NPE While Redirecting

[Tim Olson]

we get a NullPointerException for any  that gets called in our
subsitemap.  i presume this is because a  has been
called, but we must use the "cocoon:" protocol in order to divide our
pipeline into a main pipe which calls down into page-specific fragments.  no
"actual" generation has happened before the redirect.
is this NPE fixable?  if not, how else can we organize our pipelines into
per-page sitemaps?  resources don't work because they can't be called from a
subsitemap.
using cocoon 2.1.2


MAIN SITEMAP:






  


  
  


  

  
















SUBSITEMAP:






Original Exception: java.lang.NullPointerException
at
org.apache.cocoon.environment.AbstractEnvironment.release(AbstractEnvironmen
t.java:521)
at
org.apache.cocoon.environment.wrapper.MutableEnvironmentFacade.release(Mutab
leEnvironmentFacade.java:332)
at
org.apache.cocoon.components.source.impl.SitemapSource.reset(SitemapSource.j
ava:495)
at
org.apache.cocoon.components.source.impl.SitemapSource.toSAX(SitemapSource.j
ava:480)
at
org.apache.cocoon.components.source.SourceUtil.parse(SourceUtil.java:224)
at
org.apache.cocoon.generation.FileGenerator.generate(FileGenerator.java:141)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.processXMLP
ipeline(AbstractProcessingPipeline.java:532)
at
org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline
.processXMLPipeline(AbstractCachingProcessingPipeline.java:196)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(Abs
tractProcessingPipeline.java:683)
at
org.apache.cocoon.components.source.impl.SitemapSource.toSAX(SitemapSource.j
ava:467)
at
org.apache.cocoon.components.source.SourceUtil.parse(SourceUtil.java:224)
at
org.apache.cocoon.generation.FileGenerator.generate(FileGenerator.java:141)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.processXMLP
ipeline(AbstractProcessingPipeline.java:548)
at
org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline
.processXMLPipeline(AbstractCachingProcessingPipeline.java:196)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(Abs
tractProcessingPipeline.java:492)
at
org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(Seri
alizeNode.java:147)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo
keNodes(AbstractParentProcessingNode.java:84)
at
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invok
e(PreparableMatchNode.java:164)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo
keNodes(AbstractParentProcessingNode.java:108)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(Pipel
ineNode.java:163)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invo
keNodes(AbstractParentProcessingNode.java:108)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(Pipe
linesNode.java:161)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcess
or.java:351)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcess
or.java:304)
at org.apache.cocoon.Cocoon.process(Cocoon.java:640)
at
org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1104)

RE: How to change the location of cocoon.xconf and sitemap.xmap

[Tim Olson]

from a cvs perspective, we keep all of our xsl, plus the root sitemap and
subsitemap, in its own module.  it's important to our development process to
keep the xsl & xmaps separate from the application code since it's two
different groups of people who do the work.
very unfortunately, we had to hardcode absolute paths into our xconf and
root xmap, which limits our server configuration options.
i feel that better flexibility for the sitemap location is a worthwhile
goal, but i'm not sure how to accomplish that.  i sure wish java read
environment variables...
if the xconf could replace a token with a system property, then we could get
an environment variable tucked into tomcat's system properties...
i'd write a patch if someone could point me in the right direction.


> Uwe Gerger wrote:
> 
> > Hello,
> > I would like to know if it's possible to put the files 
> cocoon.xconf and
> > sitemap.xmap on an other location, wich is independly from my
> > WebApplication - directory. 
> 
> As indicated by Tim, it's possible but not generally done 
> (which is why 
> it hasn't been made easier).  Can you explain why?  There is 
> probably a 
> different/better way of accomplishing your end goal.
> 
> Geoff

RE: Use of flowscript (was: EJB + Cocoon, "Best Practices")

[Tim Olson]

> > activities often have results which need to be displayed by 
> > the generated page, and the emission of XML seems very 
> > natural to me.
> 
> ah, okay. this requirement is neither an argument for nor against
> flowscript (it should be very easy to implement it using flowscript)

oh?  i'd like to hear about that.


> > i consider flow script to be part of the view layer.  
> 
> nonono, flowscript is *another* layer, it controlls your application
> (--> controller). It decides which pipeline is sent to the client (-->
> view) and also decides which data this pipeline uses (--> model).

well for the scale of our application, the controller logic needs to be on
the backend servers.  our "controller" is really just a forwarder that can
be sequenced.  in some ways it's less powerful than flowscript, which is
intentional.
you could make the same argument that ASP/JSP/XSP code is also controller
code, but the entanglement with the view is clear.


>  - flowscript gives you the possibility to describe the logic 
>of your application at one single place (it does everything
>a controller has to do)

ok, but it's the wrong place for us.  most of the controller logic needs to
be on our business process servers, not the web servers.


>  - the state of your application is *frozen* using continuations and 
>you don't have to find out each and every time the current state 
>of your application
>--> this also solves the back-button problem

nice.  p.s. what kind of performance penalty does freezing the application
state involve?  what is included in "application state"?  what about all the
state in our EJBs and other backend services?  that still would need managed
of course.


>  - a page sent to the client doesn't have any information which
>page comes next

for us, the page that gets sent to the client has ALL the info about what
comes next, and our controller has very little of it.  that allows our
designers to change the site flow with very little tweaking (if any) in the
controller.


> > true, and i believe that (at least for our site), you 
> > SHOULDN'T code any page-to-page relations.  but then, what 
> > makes flow script so cool?
> 
> also your controller needs rules which page follows another page. You
> wrote your own solution which is fine. Since 2.1 flowscript would be
> another possibility how you can do it

actually the controller doesn't know about which page follows another; this
is important.  our view layer provides an exit key and an entry key.  the
exit key triggers a series of activities which cleans up from any posted
data etc from the page just left.  the entry key identifies and prepares the
new page.  with this scheme, we are able to mix-and-match pages in our view
layer without modifying the controller.


honestly, i'm not happy about having to write our own solution.  if flow
script could emit XML and invoke remote EJBs then we might use it.

it seems that cocoon is taking the direction of trying to be/do everything,
but i'd rather have a fast, stable XSL pipeline engine that can integrate
well with other technologies.  we already have app servers that work great;
we just needed a better view solution.

RE: Use of flowscript (was: EJB + Cocoon, "Best Practices")

[Tim Olson]

> > there are a few reasons we didn't use flow scripts even 
> > though they are quite cool technologically.
> > 
> > --> we wanted to execute a series of actions which can not 
> only follow
> > different paths like selectors but can also emit XML which is 
> > concatenated into the response stream.  there's no cocoon 
> > component like this so we're already into custom code.
> 
> it seems very hacky (an action generates XML ...???) to me - 
> but maybe I
> haven't got it right

well, when i say "action" i don't mean "cocoon action" because of course
they can't emit xml.  by "action" i meant any modular process, like an EJB
call.  i'll start calling them "activities" to avoid confusion.
it's very nice to say things like:

1. validate credit card
2. save user's updated credit card info
3. ship order

then at the same time have these three activities push out something like:


  true
  823748927
  $99
  2003-09-09


  
false
User elected to never save credit card
information
  


  58834
  2003-09-12
  
Widget
$99
  


activities often have results which need to be displayed by the generated
page, and the emission of XML seems very natural to me.


> > --> flow scripts seem to present the same problem as ASPs, 
> JSPs, and 
> > --> XSPs in
> > that too much process logic ends up on the web server
> > 
> Back to your scenario: What has "code in the view layer" to do with
> flowscript? Since using flowscript I don't have to do this anymore.

i consider flow script to be part of the view layer.  it's how you traverse
from one UI page to the next.  no?


> > --> flow scripts encourage you to link multiple pages 
> together into a
> > series, but i think this is a bad idea in terms of 
> > maintenance.
> > 
> > or C to B etc.  writing flow scripts which cross page 
> > boundries would make our navigation logic a nightmare.
> 
> that's no argument against flowscript because nothing 
> prevents you from
> building your decision logic (which page comes next) using 
> flowscript in
> a way action do it. You don't have to code explicitly any page2page
> relation.

true, and i believe that (at least for our site), you SHOULDN'T code any
page-to-page relations.  but then, what makes flow script so cool?

> > --> the action engine we wrote not only handles long-running-request
> > continuations but can also provide an updated view of the 
> > data processing. that is, our long-running backend actions 
> > can iteratively add data to the response stream, and our 
> > continuation controller will display whatever results have 
> > been given so far.  this allows us to do things like show 
> > progress bars that change with every refresh.  while a flow 
> > script could be made to do this, you would have to 
> > (artifically) break your long-running process into multiple 
> > stages and return different pages between each.  in our 
> > solution, you can have a single long-running stage and a 
> > single progress page.
> 
> IIUC you have a long running job in the background that gathers data.
> You have two possibilites: You can either wait for the final result or
> you can have a look at the intermediate results.

yes, if the results are not complete, our interstitial pipeline is
automatically invoked with the  most up-to-date xml.  if the long-running
activities have completed then a different pipeline is invoked.

> To implement this I wouldn't use neither actions nor flowscript - IMO
> both are the wrong place. Both could be used to start the 
> processing or
> access your store with the collected (maybe not finished) 
> results but I
> wouldn't make the controller to be the store.

i guess my use of the word "action" lead to some misunderstanding.  to hack
cocoon, we wrote a cocoon action which merely starts our own action engine
(controller).  to charge any of our activity chains from realtime into
long-running, we merely change one attribute on the cocoon action plus
specify an interstitial pipeline.