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].)
>
> 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).
>
> 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
--
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
