Hi Patrick,
Patrick Heiden schrieb:
Hello Nikolas!
Hi Grzegorz,
thanks for your informative answer.
Grzegorz Kossakowski schrieb:
[SNIP]
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?
First of all thanks for the term: Yes - I was looking for a central
point sitemap.
And yes - I thought it was a good idea. But perhaps I'm wrong?
I think that many users are a bit confused about how designing with blocks
should look
like (I had several discussions with Grzegorz for myself ;), you
could refere to them inside the mailing-list, e.g. [1].)
Many thanks for the valuable link (including the links to further
discussions found within).
Let me give the use case I have in mind below (probably a bit lengthy):
2. What can't you just mount block A at "/contact" and block B at
"/contact/hints"?
I'm writing a kind of CMS, where (from an abstract point of view) I
don't want to bother where the content comes from. I have several blocks
handling different source types, all delivering a document conforming to
an abstract page DTD - for such an abstract page my core block makes
available different output skins (which are then used by the blocks)
To give an example:
/sql-block/customers/list.html
/sql-block/customers/list.pdf
-> will be served by the sql-block making use of transformation service
given in my main block.
/file-block/information/index.html
/file-block/information/index.pdf
-> will be served by the plain file-block making use of transformation
service given in my main block.
(In my old example)
/forms-block/contact/form.html
-> will be server by a from generating block (and needs the requst-params)
So having this in mind I have two reasons why I would like to have a
central point sitemap. Both can be derived from the fact, the blocks in
a way reflect the internal(!) logic of the application, which I would
prefer to hide from the user viewing the content.
You are perfectly able to do this in a 'reverse' manner,
where your blocks reflect your application requirements
and then let them use other blocks to enrich their functions
(again see [1], there is a little ascii picture for that purpose).
I'm not sure wether I understand your advice correctly.
My Sitemap-Snippet in the plain-file-block for example looks (in a
simplified
way) sth like
<map:match pattern="**.html">
<map:aggregate element="full">
<map:part src="servlet:main:/siteconfig"/>
...
<map:part src="xml-files/{1}"/>
</map:aggregate>
<map:transform type="servletService">
<map:parameter name="service"
value="servlet:default-skin:/service/tranformation/page2xhtml"/>
</map:transform>
<map:transform type="myLinkRewriter" />
<map:serialize type="xhtml">
</map:match>
The sql-block will have some other aggregate mechanism, but will again
use default-skin.
Isn't this sth. your nice ASCII-pic did propose?
What should I reverse?
After reading all your informative discussions I get the impression,
that the proposed best-practice (applied to my case) is, that my
specialized source blocks (file-block, sql-block,etc) should handle the
browser request _directly_, making use of either services made available
by other blocks or pipeline-fragments inherited by super-blocks. It is
not intended to "redirect/dispatch" (probably these terms are
misleading?) the browser request to different blocks.
Is this correct?
If it is, what if I still would wish to have sth. like a (mildly
intelligent) proxy? (Probably 'proxy' is a better term?)
My app could have the knowledge at hand (a map 'official url' ->
'internal url'), that the "official" url http://contact/hints/ is
handled by http://file-block/contact/hints/index.html.
How could I use this knowledge to simply redirect the browser request to
this url handled by the file-block without letting the user know?
1) I want my users to be able to change the source without changing the
bath!!
For example: They start to edit a quick list with the plain file module
and publishes under the URL "/products/list/" . A few weeks later they
could decide to generate a more complete list from a database - they
delete the old node, insert a new one with same name (in fact a move of
the node) but a different block (this means in my model editing a
predefined config file). What I would like to circumvent is, that the
public URL changes from /file-block/products/list* to
/sql-block/products/list*
2) I would like to have the flexibility to "intermix" my sources=blocks
on one URL-path meaning
/customers/ <- some nice blablah coming from plain file
/customers/23/ <- coming from a db entry (23)
/customers/23/extra-info/ <- coming from plain file-block
[SNIP]
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)
I'm happy, that you agree - I will not do it this way.
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?
I hope my long example above does answer this question now as well.
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. :-)
At this point for special purposes (before extending DispatcherServlet, wich
already fulfills its contract) AOP is sometimes usefull!
To make it plain - I didn't plan to make a proposal for changing the
DispatcherServlet. I just stumbled upon this possibility during my
"desperate" search for a solution of my problem.
I don't know whether my case above is sth. like a "convincing argument"
- you probably have already discussed related use scenarios?
Are there any public traces of your discussions - I would like to follow
the arguments against central point (if my technical ability is
sufficient)
I would advise to just mount blocks at locations as closer as possible
to what you want achieve and move on.
:-(
Probably that's what I will do first (there are enough other open issues
in my work ;-)
Thanks again for your expertise.
Best Regards, Patrick
Thanks for your help.
Regards
Niko
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
