On 6/23/05, Andreas Hartmann <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > Code reuse is better solved with Resources. > Personally I don't like resources that much, especially because > they can't be shared between sitemaps. > Just FYI, maybe you're interested in this: > http://wiki.apache.org/cocoon/VirtualComponents
Was that proposal implemented? We were discussing Views, which also cannot be shared between sitemaps. Resources are good as subroutines or macro substitution. It would be nice if they could be defined in a header file or alternate sitemap. Then a single Resource could finish the processing of every document in every Sitemap. That could also be implemented by making the HTML Serializer a Virtual Component to always: i18n Transform StripNamespaces HTML Serialize What exactly is inherited by Sitemaps? Just Components: Generators, Serializers, Selectors, Readers, Actions and Pipes? Views and Resources are not inherited. Pipelines must specify how to jump. Flow must return to the Sitemap that called it. -- Almost-related topic: I am wondering how best to implement document security. My current project handles it in XSL, but XSL should be for formatting, not functionality. It could be handled in a Sitemap with something like auth-protect, but that is where application functionality is defined; a Usecase sitemap should not bypass the security because the author forgot to copy something. I think it needs to be built into the File Generator. That might be a Virtual Component (if they exist), but hardcoding into the Java would be best. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
