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/ [EMAIL PROTECTED] [EMAIL PROTECTED]
