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:[EMAIL PROTECTED] > Sent: maandag 4 augustus 2003 14:21 > To: [EMAIL PROTECTED] > > 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 > [EMAIL PROTECTED] [EMAIL PROTECTED] > >
