Ciao Andreas,
I'm not quite sure if I understand this correctly.
The basic mechanism is
URL -> [DocumentBuilder] -> Document -> [PathMapper] -> File
The page envelope, workflow, revision controller etc. should work
on the Document object (using the getFile() etc. methods to resolve
paths).
Which stage of this process do you want to customize?
URL <- * map * -> [DocumentBuilder] -> Document(s) -> [PathMapper] ->
AC (File), WF (File) [Logic]
Webdav clients (not sending user-agent header info) seem to force us to
introduce a dummy webdav area but that's an area without AC/WF data
attached (witch is taken from authoring of course).
So looking at WF this leads to: getting an AccessController, then
getting a PolicyAuthorizer from that, again getting a PolicyManager
from that, finally getting the needed Policy, do a getRoles(), cast
them to String array and use that to build a new CMSSituation (!!).
Finally build the a WorkflowDocument and invoke an event taken into
account your situation.
Hmm. The job can be done. I was just looking for a method to pass an
identity, a doc, an area and an event to some workflow code and getting
back the wf's findings.
You get the point. The above request initializes PageEnvelopeModule
with an nonexistent document and althought it's easy to use
DocumentBuilder to build an arbitrary document letting pageEnvelope
alone, it seems to be not that easy to get the needed
RevisionController and workflow states for this document since at
least the workflow code is heavilly depending on the
PageEnvelopeModule AFAICS.
Yes - the workflow, revision controller etc. use the document
which is attached to the page envelope. This document is determined
by the DocumentBuilder. The connections are pretty hard-wired, I don't
see an immediate solution to disentangle this (at least when you use
the task concept).
I'm fine with the PageEnvelope concept, not that fine with any
hardwired connections to anything else in the system.
You could try to call the workflow and RC classes directly.
If they access the page envelope, then it's a bug (IIRC there are
such problems in 1.2).
Will report what I find.
Or what is the preferred way of implementing URI namespace schemes
that differ from the one that lenya uses except of putting a proxy in
front of the whole thing?
The API doesn't support this. The URL is mapped 1:1 to the document ID.
I'm not sure if this helps, maybe I'll have to see some code examples
to better understand what you're trying to achieve.
BTW - I was thinking about writing a
org.apache.cocoon.components.repository Wrapper for lenya. This would
simplify code reuse of existing cocoon code (webdav, ftp, ?) a bit.
Would this make sense or be considered as an offense re lenya API?
Thanks!
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
