+1 for now, implementation of "real" blocks will make us rethink this again.
Cheers, Reinhard > -----Original Message----- > From: Bruno Dumon [mailto:[EMAIL PROTECTED] > Sent: Monday, August 04, 2003 2:21 PM > To: [EMAIL PROTECTED] > Subject: sendPage, sendPageAndWait uri argument (was Re: > [flow] forwardTo()) > > > 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] >
