cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <agalla...@agssa.net>
Subject Re: Manually specifying a mounted sub sitemap's context
Date Mon, 11 Apr 2005 03:54:17 GMT
On Dom, 10 de Abril de 2005, 15:12, Sylvain Wallez dijo:
> Antonio Gallardo wrote:
>
>>On Sab, 9 de Abril de 2005, 14:27, Jochen Kuhnle dijo:
>>
>>
>>>Sylvain Wallez <sylvain@apache.org> wrote on 09.04.2005 20:51:41:
>>>
>>>
>>>>In other words, should it be:
>>>>
>>>>  <map:mount src="foo/bar/" context="baz"/>
>>>>and
>>>>  <map:sitemap>
>>>>
>>>>or
>>>>  <map:mount src="foo/bar/"/>
>>>>and
>>>>  <map:sitemap context="baz"/>
>>>>
>>>>
>>>>My feeling favors the second form, as allowing to specify the context
>>>>externally means that understanding what a sitemap does depends on the
>>>>mount statement.
>>>>
>>>>
>>>Agreed, the second form is easier to understand. The first one was just
>>>easier to implement (at least for me), since MountNode.invoke already
>>>resolves the sitemap context. And this was the point where cocoon went
>>>into endless recursion...
>>>
>>>On the other hand, the first form offers one additional feature:
>>> Mounting
>>>the same sitemap twice with different contexts. I just don't know yet if
>>>this is a good idea...
>>>
>>>
>>>
>>
>>I see this as a good idea. I have a lot of literally equals sitemaps that
>>with something like that I can get rid of them by just defining his
>>context.
>>
>>
>
> What do you mean by "literally equals"?
>
> Do they differ because:
> - there is a a slight difference in what they should do (in that case
> what about pass-through mounts?)
> - or because they provide the same pipelines but operate on different
> data?

The second:
they provide the same pipelines but operate on different data.

Building webapps, you have some forms sets (businnes module? [BM]) that
provide basic functionality (create, edit, search) on diferent data
(tables). Perhaps this is our fault, I know I can use a parent sitemap for
that. But we don't see it as a good solution for us, since we want to keep
every BM separated (and independent) of the others. That can allow us to
"move" a defined MB to another application by just copy paste a MB.

Maybe we need to find another solution for that.

Best Regards,

Antonio Gallardo.


Mime
View raw message