cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nikolas List <l...@metromorph.de>
Subject Re: Block redirect/dispatch
Date Thu, 10 Apr 2008 05:29:09 GMT
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?

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.

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. :-)
> 
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.

Regards
Niko


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message