You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Richard Frovarp <Ri...@sendit.nodak.edu> on 2007/10/19 19:16:01 UTC
cocoon:/ vs cocoon://
I probably should know this, but what is the difference between cocoon:/
and cocoon://?
I see this in the logs and would like to clear it up:
SocketListener0-9 WARN flow - usecases.js::executeUsecase() : The use
of the cocoon:/ protocol prefix in the <view uri="..."> attribute is
deprecated!
If we are releasing a rewrite, we should probably try to eliminate
deprecation messages in our logs where possible.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: cocoon:/ vs cocoon://
Posted by Thorsten Scherler <th...@apache.org>.
On Fri, 2007-10-19 at 12:16 -0500, Richard Frovarp wrote:
> I probably should know this, but what is the difference between cocoon:/
> and cocoon://?
>
Think of XPath:
http://w3schools.com/xpath/xpath_syntax.asp
/ Selects from the root node
// Selects nodes in the document from the current node that match the
selection no matter where they are
Produced to cocoon matching (the nice definition Jürgen posted with some
additions):
...
The appropriate pipeline is selected matching (from the)
root-sitemap-pipeline (on, no matter where the match is located - any
child *.xmap known by the root-sitemap will be searched).
salu2
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: cocoon:/ vs cocoon://
Posted by Jörn Nettingsmeier <ne...@apache.org>.
Richard Frovarp wrote:
> Jörn Nettingsmeier wrote:
>> Richard Frovarp wrote:
>>> So my question for you is this: Is it just cocoon:/ or does it
>>> include cocoon:// as well? The code in usecases.js matches cocoon:/
>>> but the subsequent substring will leave the trailing / from cocoon://
>>
>> iirc, the flow code only deals with a protocol-less string
>> "FOO/BAR/BAZ" that is then fed to the flow sitemap and interpreted as
>> if you had requested "cocoon:/FOO/BAR/BAZ" from the context of that
>> flow sitemap.
>> the leading slash is left intact afaik. does that answer your
>> question? if not, i'd need to dig into the flow code again...
>>
>>
>>
> The relevant section from usecases.js:
> // we used to allow a cocoon:/ prefix (which sendPageXXX does not handle),
> // but it is now deprecated!
> if (viewUri.startsWith("cocoon:/")) {
> viewUri = viewUri.substring(new
> Packages.java.lang.String("cocoon:/").length());
> log("warn", "The use of the cocoon:/ protocol prefix in the <view
> uri=\"...\"> attribute is deprecated!");
> }
> if (! viewUri.startsWith("/")) {
> // a local URI must be handled by usecase.xmap, which assumes a
> prefix "usecases-view/[menu|nomenu]/
> // that determines whether the menu is to be displayed. this
> mechanism is used by most lenya core usecases.
> viewUri = "usecases-view/"
> + (view.showMenu() ? "menu" : "nomenu")
> + "/" + viewUri;
> }
>
>
> So the first if matches cocoon:// and cocoon:/. You then do a substring
> that leaves the second / behind in the case of cocoon://. In the case of
> cocoon:/ the second if would trip, but in the case of cocoon:// it would
> not. Is this behavior correct?
i hope so.
there are some old provisions in the code for a "show menu" switch which
is dealt with in usecases.xmap iirc, and we generate a request
accordingly - if there is a menu="yes" attribute in the xconf where the
view is defined, the request is usecases-view/menu/**, otherwise it's
usecases-view/nomenu/**
xconfs that use this old switch must provide a relative uri without a
leading slash, and the requests end up in usecases.xmap.
i added some code so that you can generate your own usecase view with a
custom pipeline - such requests must be absolute uris (i.e. with a
leading slash) and will be dealt with by the root sitemap. in actual
practice, your uri would of course be something like
/modules/yourmodule/yourUsecaseView, so that the request can be handled
by the module sitemap.
arguably the resulting <view> syntax is a bit of a mess, and i don't
like those weird usecases-view/[no]menu/ strings much, but i didn't want
to disrupt too much of the old code...
while we're revising this: occurences of the "template" attribute should
be changed to "uri" as well - behaviour is the same, but uri is more
general (templates had to be .jx files, uris can be arbitrary pipelines
that generate a view by other means as well)
/me rummages through some code....
/me blushes on finding that tinymce also uses a deprecated protocol
prefix...
ah, here it is:
http://lenya.apache.org/apidocs/2.0/modules/usecase/index.html
i knew i had some documentation somewhere. hope that explains it. if
not, check the UsecaseView.java class
reminds me that we should review and update
http://lenya.apache.org/docs/2_0_x/reference/usecase-framework/index.html...
> The code and the comments are confusing
> to me. I only see <view uri> with cocoon://, but the message is still
> tripping because they match the first if and are in fact acted upon.
>
> So basically I'm confused as the comments only reference cocoon:/ and
> not cocoon://, but it is obvious that the code acts on cocoon://. Given
> what the difference is between / and // it would seem that the code is
> correct and the comments are not complete.
the code is correct iiuc. "cocoon:/foo/bar" resp. "foo/bar" is a
relative request handled by usecases.xmap. cocoon://foo/bar" resp.
"/foo/bar" is an absolute request that is passed to the root sitemap.
feel free to improve the comments as you see fit.
--
Jörn Nettingsmeier
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: cocoon:/ vs cocoon://
Posted by Richard Frovarp <Ri...@sendit.nodak.edu>.
Jörn Nettingsmeier wrote:
> Richard Frovarp wrote:
>> So my question for you is this: Is it just cocoon:/ or does it
>> include cocoon:// as well? The code in usecases.js matches cocoon:/
>> but the subsequent substring will leave the trailing / from cocoon://
>
> iirc, the flow code only deals with a protocol-less string
> "FOO/BAR/BAZ" that is then fed to the flow sitemap and interpreted as
> if you had requested "cocoon:/FOO/BAR/BAZ" from the context of that
> flow sitemap.
> the leading slash is left intact afaik. does that answer your
> question? if not, i'd need to dig into the flow code again...
>
>
>
The relevant section from usecases.js:
// we used to allow a cocoon:/ prefix (which sendPageXXX does not handle),
// but it is now deprecated!
if (viewUri.startsWith("cocoon:/")) {
viewUri = viewUri.substring(new
Packages.java.lang.String("cocoon:/").length());
log("warn", "The use of the cocoon:/ protocol prefix in the
<view uri=\"...\"> attribute is deprecated!");
}
if (! viewUri.startsWith("/")) {
// a local URI must be handled by usecase.xmap, which assumes a
prefix "usecases-view/[menu|nomenu]/
// that determines whether the menu is to be displayed. this
mechanism is used by most lenya core usecases.
viewUri = "usecases-view/"
+ (view.showMenu() ? "menu" : "nomenu")
+ "/" + viewUri;
}
So the first if matches cocoon:// and cocoon:/. You then do a substring
that leaves the second / behind in the case of cocoon://. In the case of
cocoon:/ the second if would trip, but in the case of cocoon:// it would
not. Is this behavior correct? The code and the comments are confusing
to me. I only see <view uri> with cocoon://, but the message is still
tripping because they match the first if and are in fact acted upon.
So basically I'm confused as the comments only reference cocoon:/ and
not cocoon://, but it is obvious that the code acts on cocoon://. Given
what the difference is between / and // it would seem that the code is
correct and the comments are not complete.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: cocoon:/ vs cocoon://
Posted by Jörn Nettingsmeier <ne...@apache.org>.
Richard Frovarp wrote:
> So my question for you is this: Is it just cocoon:/ or does it include
> cocoon:// as well? The code in usecases.js matches cocoon:/ but the
> subsequent substring will leave the trailing / from cocoon://
iirc, the flow code only deals with a protocol-less string "FOO/BAR/BAZ"
that is then fed to the flow sitemap and interpreted as if you had
requested "cocoon:/FOO/BAR/BAZ" from the context of that flow sitemap.
the leading slash is left intact afaik. does that answer your question?
if not, i'd need to dig into the flow code again...
--
Jörn Nettingsmeier
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: cocoon:/ vs cocoon://
Posted by Richard Frovarp <Ri...@sendit.nodak.edu>.
Jörn Nettingsmeier wrote:
> Richard Frovarp wrote:
>> I probably should know this, but what is the difference between
>> cocoon:/ and cocoon://?
>
> cocoon:/ points at a matcher in the current sitemap, cocoon:// points
> at the root sitemap.
>
>> I see this in the logs and would like to clear it up:
>>
>> SocketListener0-9 WARN flow - usecases.js::executeUsecase() : The
>> use of the cocoon:/ protocol prefix in the <view uri="..."> attribute
>> is deprecated!
>
> i think i introduced that message a while ago, because cocoon flow can
> only handle cocoon:/-type urls, not arbitrary ones - imho it's better
> to just have a matcher in there without the protocol part, lest people
> think they can use arbitrary protocols in there.
>
>> If we are releasing a rewrite, we should probably try to eliminate
>> deprecation messages in our logs where possible.
>
> very true. i should have cleaned that up while i was at it...
> generally, in all <view uri=""> attributes, cocoon:/ can be removed
> without any adverse effects (and should be)...
>
>
So my question for you is this: Is it just cocoon:/ or does it include
cocoon:// as well? The code in usecases.js matches cocoon:/ but the
subsequent substring will leave the trailing / from cocoon://
Richard
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: cocoon:/ vs cocoon://
Posted by Jörn Nettingsmeier <ne...@apache.org>.
Richard Frovarp wrote:
> I probably should know this, but what is the difference between cocoon:/
> and cocoon://?
cocoon:/ points at a matcher in the current sitemap, cocoon:// points at
the root sitemap.
> I see this in the logs and would like to clear it up:
>
> SocketListener0-9 WARN flow - usecases.js::executeUsecase() : The use
> of the cocoon:/ protocol prefix in the <view uri="..."> attribute is
> deprecated!
i think i introduced that message a while ago, because cocoon flow can
only handle cocoon:/-type urls, not arbitrary ones - imho it's better to
just have a matcher in there without the protocol part, lest people
think they can use arbitrary protocols in there.
> If we are releasing a rewrite, we should probably try to eliminate
> deprecation messages in our logs where possible.
very true. i should have cleaned that up while i was at it... generally,
in all <view uri=""> attributes, cocoon:/ can be removed without any
adverse effects (and should be)...
--
Jörn Nettingsmeier
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: cocoon:/ vs cocoon://
Posted by Juergen Ragaller <ra...@apache.org>.
Hi Richard
Am 19.10.2007 um 19:16 schrieb Richard Frovarp:
> I probably should know this, but what is the difference between
> cocoon:/ and cocoon://?
This is from the cocoon doc:
# Use cocoon:/current-sitmap-pipeline/foo/bar to merge in xml content
from the current sitemap. The appropriate pipeline is selected
matching current-sitemap-pipeline.
# Use cocoon://root-sitmap-pipeline/foo/bar to merge in xml content
from the root sitemap. The appropriate pipeline is selected matching
root-sitemap-pipeline.
Thanks for all the work!
Jürgen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org