cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nikolas List <>
Subject Re: Block redirect/dispatch
Date Fri, 11 Apr 2008 08:22:24 GMT
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 
way) sth like

<map:match pattern="**.html">
     <map:aggregate element="full">
        <map:part src="servlet:main:/siteconfig"/>
        <map:part src="xml-files/{1}"/>
     <map:transform type="servletService">
         <map:parameter name="service"
     <map:transform type="myLinkRewriter" />
     <map:serialize type="xhtml">

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}&param2={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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message