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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
