You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Marc Portier <mp...@outerthought.org> on 2003/07/22 16:12:34 UTC
[flow] forwardTo()
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;
}
where I assume the variable uri is holding what
sendPage()/sendPageAndWait() got as a first argument?
Some careful questions (only valid if my current assumptions are
correct)
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?
(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?)
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
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?
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?
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
RE: sendPage, sendPageAndWait uri argument (was Re: [flow] forwardTo())
Posted by Reinhard Pötz <re...@gmx.net>.
+1 for now, implementation of "real" blocks will make us rethink this
again.
Cheers,
Reinhard
> -----Original Message-----
> From: Bruno Dumon [mailto:bruno@outerthought.org]
> Sent: Monday, August 04, 2003 2:21 PM
> To: dev@cocoon.apache.org
> 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
> bruno@outerthought.org bruno@apache.org
>
sendPage, sendPageAndWait uri argument (was Re: [flow] forwardTo())
Posted by Bruno Dumon <br...@outerthought.org>.
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
Re: [flow] forwardTo()
Posted by Marc Portier <mp...@outerthought.org>.
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
Re: [flow] forwardTo()
Posted by Bruno Dumon <br...@outerthought.org>.
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.
> (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).
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org