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 <[EMAIL PROTECTED]> 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.
