Nikolas List pisze:
Hi,
Patrick Heiden wrote:
Hi Nikolas!
Could you please state a snipped of your sitemap to get an overview of
how you actually redirect request params?
My problem is, that I have no snippet. I'm looking for a miraculous(?)
way of passing them.
Let me give an (old) example snippet: If both sitemap parts would reside
in one block (for example mounted under mount-A and mount-B I would do
sth like (ignoring the lookup in my bean knowing all URL-Mappings)
<map:match pattern="/contact/">
<map:generate src="cocoon://mount-A/niceurl/serving/form"/>
<map:serialize />
</map:match>
<map:match pattern="/contact/hints/">
<map:generate src="cocoon://mount-B/otherurl/serving/hints"/>
<map:serialize />
</map:match>
The source generated in this case is an internal cocoon redirect and has
access to the ObjectModel so it knowns everything - thats the miracle
here ;-).
Before I start to comment on your proposals/questions I need to ask a few mine:
1. Do you _really_ think that having central point (sitemap) that rewrites your URLs for blocks is a
good idea at all? What's wrong with URLs reflecting your logical structure of application?
2. What can't you just mount block A at "/contact" and block B at
"/contact/hints"?
Now both approaches I thought of first don't work:
1)
<map:generate src="/block-A/niceurl/serving/form" />
is invalid as it tries to create a CocoonSource in the context of the
core block "/", so the resource doesn't exist.
2)
<map:generate src="servlet:block-A:/niceurl/serving/form" />
Creates (as far as I understood) a new request (without including the
params from the Object model).
Three aproaches which work - but I don't like for various reasons:
1)
<map:redirect-to uri="/block-A/niceurl/serving/form" />
Is an external redirect - realized by the user
2)
<map:generate
src="servlet:block-A:/niceurl/serving/form?param1={request-param:param1}¶m2={request-param:param1}"
/>
The problem is I do not know the parameters needed by
block-A:/niceurl/serving/form
There is a code in JIRA that would help with this. Guess why it have not been
merged to trunk.
(hint: it's not the best idea to do it this way, at least in my humble opinion)
3)
Implement an extension of DispatcherServlet, which first asks my bean
for the URL mapping, then using the normal Block-Dispatching mechanism
for the mapped path. ... This should not be the best approach, or?
I hope this clarifies my problem - or is it weird what I am trying to do?
It clarifies what you want to do specifically but does not help with the question why do you want to
do it?
We had plenty of discussions about having central point for block dispatching (apart from
DispatcherServlet), the last one was held yesterday at Hackathon in Amsterdam. Few Cocoon committers
agreed that it's the best to leave dispatching to DispatcherServlet (it's exactly the reason why it
exists!) until someone comes with convincing argument that we need more flexibility. :-)
I would advise to just mount blocks at locations as closer as possible to what you want achieve and
move on.
--
Grzegorz Kossakowski
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
