cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <...@outerthought.org>
Subject Re: [flow] forwardTo()
Date Mon, 28 Jul 2003 15:02:40 GMT
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=
-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at              http://radio.weblogs.com/0116284/
mpo@outerthought.org                              mpo@apache.org


Mime
View raw message