On Mon, 2008-01-14 at 19:36 +0100, Jörn Nettingsmeier wrote:
> Andreas Hartmann wrote:
> > Jörn Nettingsmeier schrieb:
> >> Thorsten Scherler wrote:
> > From my POV, the major benefits of JCR vs. the others are:
> >
> > - You get a Java API and can choose your implementation.
Which is the most important point. You write your code against an API
like other tool developer. Meaning a wide range of tools are available
to explore your content WITHOUT our current web front end.
> > - You get versioning and transactions out of the box.
One thing less that we need to maintain as our own implementation.
...
> > These cases could be handled by a transformer:
> >
> > 1) <rev:insert-history document="lenya-document:1234-234-asdf"/>
> >
> > would be expanded to
> >
> > <rev:history document="...">
> > <rev:revision ...
> > <rev:revision ...
> > ...
> > </rev:history>
> >
> > which can be evaluated by a subsequent XSLT.
>
> lovely. imho, this is the most natural way of dealing with it.
> unfortunately, lenya uses this pattern only in some obscure corner
> cases. we should change that.
Exactly and if we change it, then please let us try to use just a
wrapper transformer. I mean the transformer will call 2 or three methods
max of a cocoon independent helper class which is actually doing the
work. This way I can write a JSF tag attacking the same helper in no
time.
I do not propose to drop cocoon but to make our code more reusable
outside of cocoon.
>
>
> > 2) <ac:insert-user-data user="{$currentUser}"/>
> >
> > would be expanded to
> >
> > <ac:user-data user="john">
> > <ac:email>[EMAIL PROTECTED]</ac:email>
> > <ac:name>John</ac:name>
> > ...
> > </ac:user-data>
> >
> >
> > [...]
> >
> >> if we somehow exported an xml view of our repository, i'm sure many
> >> users could think of very clever things to do with their content and
> >> metadata.
> >
> > In principle I agree, though I'd rather provide a well-documented and
> > extensible set of "custom Lenya tags" (see above). AFAIK most CMSs
> > provide such a mechanism, and users are used to it. A big plus of Lenya
> > is that, thanks to Cocoon, we have XML processing pipelines which allow
> > very flexible and powerful tag expansion scenarios.
>
> sounds good. we should bear in mind that users might want to do things
> we haven't anticipated, and expose everything in a generic way.
Yeah, write it once and use it everywhere.
...
> i'd say we should do strict interfaces and encapsulation for writing
> data and doing access control, and be really sloppy when it comes to
> retrieving data.
>
IMO using JSR as data retrieving API is the only way to go. We just do
not have the manpower for an awesome homegrown powerful implementation.
> > (Regarding the workflow engine I have no strong opinion at the moment,
> > only that it would be nice to have workflow-driven usecases instead of
> > the other way round as it is now.)
>
> well said. thorsten, what made you mention workflow explicitly? do you
> see problems with our workflow engine that other engines could solve?
Well our engine is actually an implementation of a concrete usecase (the
publishing process of web content), it is not an easy task to implement
your own custom use case where you may need a higher level of control
over different steps of a process.
Imagine I want to implement:
webcontent is created -> is DOC -> send to user xy for verification ->
xy verifies -> system transforms it to pdf -> send to Designer for
verification -> Designer verifies -> system publish
How much days/week will this cost to implement with our engine? How can
I implement this with our engine?
With e.g. JBoss jBPM that is a quite quick task like the demo may show
http://docs.jboss.com/jbpm/v3/demos/movies/jbpm-overview.htm
I do not want to say that replacing our engine with a custom jbpm
process definition is priority but would definitely say that our
user/devs can benefit a lot from such a move. Imagine the user can
choose different usecase that are provided from the programmer.
...and believe me there a lot programmers that can write you the process
definition as shown in the video with jbpm but only a few that are
capable to implement it in lenya with our current engine.
...anyway the workflow was just an example, AC would be another one, ...
and ...
salu2
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
