cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Olson <tol...@marketingforce.com>
Subject RE: [vote] forbidding flowscripts with no sendpage redirects (was Re: Saving pipeline output to a temp file...)
Date Wed, 12 Nov 2003 19:20:44 GMT
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

<map:match action="*/profile/edit">
  <map:call function="dumpUserData"/>
  <map:generate src="cocoon://generate"/>
  <map:transform src="profileForm.xsl"/>
  <map:serialize/>
</map:match>



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

<map:match action="*/profile/edit">
  <map:call function="dumpUserData"/>
</map:match>

<map:match action="*/profile/edit2">
  <map:generate src="cocoon://generate"/>
  <map:transform src="profileForm.xsl"/>
  <map:serialize/>
</map:match>

(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:

<map:match action="*/profile/edit">
  <map:call function="dumpUserData"/>
  <map:call function="dumpOrderData"/>
  <map:call function="dumpNewsItems"/>
  <map:generate src="cocoon://generate"/>
  <map:transform src="homePage.xsl"/>
  <map:serialize/>
</map:match>

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:sylvain@apache.org]
> Sent: Tuesday, November 11, 2003 5:00 PM
> To: dev@cocoon.apache.org
> 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
> 
> 

Mime
View raw message