cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Unico Hommes" <Un...@hippo.nl>
Subject RE: sendPage, sendPageAndWait uri argument (was Re: [flow] forwardTo())
Date Mon, 04 Aug 2003 15:41:38 GMT

On a related note: the cocoon.process(uri,object,outStream) FOM function
is always resolved as cocoon:// . Do you think this should behave as
sendPage(AndWait)?

Regards,
Unico

> 
> -----Original Message-----
> From: Bruno Dumon [mailto:bruno@outerthought.org] 
> Sent: maandag 4 augustus 2003 14:21
> To: dev@cocoon.apache.org
> 
> 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