cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Dumon <br...@outerthought.org>
Subject sendPage, sendPageAndWait uri argument (was Re: [flow] forwardTo())
Date Mon, 04 Aug 2003 12:20:40 GMT
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