cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Pötz <reinhard_po...@gmx.net>
Subject RE: sendPage, sendPageAndWait uri argument (was Re: [flow] forwardTo())
Date Mon, 04 Aug 2003 12:32:12 GMT
+1 for now, implementation of "real" blocks will make us rethink this
again.

Cheers,
Reinhard

> -----Original Message-----
> From: Bruno Dumon [mailto:bruno@outerthought.org] 
> Sent: Monday, August 04, 2003 2:21 PM
> To: dev@cocoon.apache.org
> Subject: sendPage, sendPageAndWait uri argument (was Re: 
> [flow] forwardTo())
> 
> 
> Does anyone mind if I make the change outlined below?
> 
> To summarize, it's about what uri is passed as first argument to the
> sendPage(AndWait) function.
> 
> The current situation is that if the uri doesn't start with 
> cocoon://, then cocoon:// + environment.getURIPrefix() is prepended.
> 
> The proposed change is to only (and always) prepend cocoon:/
> 
> As a result, if the uri supplied to sendPage starts with a /, 
> it will be resolved starting from the root sitemap, and 
> otherwise starting from the current sitemap.
> 
> The explicit use of schemes within the uri would be forbidden 
> (by throwing an Exception).
> 
> On Mon, 2003-07-28 at 17:02, Marc Portier wrote:
> > Bruno Dumon wrote:
> > > On Tue, 2003-07-22 at 16:12, Marc Portier wrote:
> > > 
> > >>Hi all,
> > >>
> > >>Trying to understand some more flow internals...
> > >>
> > >>I just checked the FOM_Cocoon.java on how it handles the 
> > >>redirects...
> > >>
> > >>and this seems to be the relevant portion:
> > >>
> > >>String redUri = uri;
> > >>if(! uri.startsWith( "cocoon://" ) ) {
> > >>     redUri = "cocoon://" + 
> this.environment.getURIPrefix() + uri; }
> > >>
> > > 
> > > 
> > > actually that's how the forwardTo(uri, object, 
> Continuation) method 
> > > does it.
> > > 
> > > forwardTo(uri, object, FOM_WebContinuation) always 
> inserts cocoon:// 
> > > + getURIPrefix, regardless of whether the URI already starts with 
> > > cocoon://
> > > 
> > > 
> > > 
> > >>1/ do we explicitely want to prohibit the usage of ANY 
> valid uri to 
> > >>redirect to?
> > >>
> > >>I guess that http://whatever-uri should be able to work 
> as well, no?  
> > >>Maybe we should just be checking for the presence of a 
> 'scheme' part 
> > >>in the URI?
> > > 
> > > 
> > > Don't know. We got a redirectTo method for that.
> > > 
> > 
> > ah, an observation I missed out on, thx
> > (I take it that function-implementation was going over a
> > different path then the forwardTo?)
> > 
> > another thought that did cross my mind:
> > the presence of the 2nd argument (the bizdata-object) actually
> > indicates that this forwardTo() is only to be used for selection 
> > of cocoon-pipelines (and not external redirects: what should they 
> > do with this biz-data?)
> > 
> > so I guess, this adds an argument to your proposal:
> > 
> > > 
> > >>(and even if we don't want to have client-side-redirect 
> uri's ripple 
> > >>through then we should at least check and warn accordingly?)
> > > 
> > > 
> > > agreed
> > > 
> > > 
> > >>2/ when selecting a sitemap-pipeline do we explicitely 
> want to have 
> > >>everything resolved versus the top level sitemap?
> > >>
> > >>if we would just append 'cocoon:/' (ONE slash) then the 
> flow-writer 
> > >>can control if he wants to select relative to the current 
> sitemap or 
> > >>relative to the root sitemap (by letting his uri start 
> with a '/' or 
> > >>not)
> > >>
> > >>sendPageAndWait('localmap/uri-part');
> > >>     --> cocoon:/localmap/uri-part
> > >>sendPageAndWait('/topmap/whatever);
> > >>     --> cocoon://topmap/whatever
> > > 
> > > 
> > > Makes sense. This could change existing behaviour if 
> people already 
> > > used / at the beginning of the path, but I think that 
> will rarely be 
> > > the case and is a change we can still afford now.
> > > 
> > > 
> > >>3/ is this behaviour a general property of 'flow' or is it
> > >>specific to how the JSInterpreter handles things?
> > >>
> > >>personally I think we can tackle this on the level of the 
> > >>AbstractInterpreter so this line of thinking becomes available to 
> > >>all flow implementations?
> > > 
> > > 
> > > I agree.
> > > 
> > > 
> > >>if all 3 comments make sense the following could become the new 
> > >>implementation of AbstractInterpreter.forwardTo() (and we could 
> > >>offload the burdon from the current implementations)
> > >>
> > >>
> > >>
> > >>import org.apache.excalibur.source.SourceUtil;
> > >>
> > >>
> > >>public void forwardTo(String uri, Object bizData,
> > >>                         WebContinuation continuation,
> > >>                         Environment environment)
> > >>           throws Exception
> > >>{
> > >>       if (SourceUtil.indexOfSchemeColon(uri) == -1) {
> > >>           uri = "cocoon:/" + uri;
> > >>       }
> > >>
> > >>       Map objectModel = environment.getObjectModel();
> > >>       FlowHelper.setContextObject(objectModel, bizData);
> > >>       FlowHelper.setWebContinuation(objectModel, continuation);
> > >>       PipelinesNode.getRedirector(environment)
> > >>                    .redirect(false, uri);
> > >>}
> > >>
> > >>
> > >>
> > >>what do others think?
> > > 
> > > 
> > > I would forbid the use of schemes completely (i.e. throw an 
> > > exception if the uri contains a scheme), and prepend 
> cocoon:/ (one 
> > > slash).
> > > 
> > 
> > makes sense, and makes us need to change existing implementations
> > for not doing the same cocoon:/ prepend before the call to 
> > super.forwardTo()
> > 
> > finally: the exception-throwing prohibits the chaining of
> > flow-calls (for which I see no real need, and until somebody does 
> > that last argument was just an academic remark I'm afraid)
> > 
> > 
> > regards,
> > -marc=
> -- 
> Bruno Dumon                             http://outerthought.org/
> Outerthought - Open Source, Java & XML Competence Support Center
> bruno@outerthought.org                          bruno@apache.org
> 


Mime
View raw message