[EMAIL PROTECTED] wrote:
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?
Carsten Ziegeler is working on it in the trunk:
cocoon/trunk/src/java/org/apache/cocoon/sitemap/impl/AbstractVirtualSitemapComponent.java
We were discussing Views, which also cannot be shared between sitemaps.
Yes, you're right. But I've never seen views as a means for pipeline
reuse anyway ...
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
Yes, that is a nice example.
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.
Hmmm, I wouldn't think that way round. The purpose shouldn't be
defined by the technology, but rather the other way round. If you
find XSLT suitable for your needs (although I agree that it seems
strange to use them for security :) ), why shouldn't you use it?
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.
Maybe it could even be added in the repository layer, or at least
in the RepositorySource (lenya:// protocol). Then it wouldn't be
restricted to generation, but it would also apply to all other
operations on a document.
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
