Michael Ralston wrote:
Andreas Hartmann wrote:
Andreas Hartmann wrote:
According to an early idea, the NodeCreatorInterface should be replaced
by post-processing of the created document in the corresponding "create"
usecase.
But there are some difficulties:
- Until now, Lenya doesn't support usecase polymorphism based on
resource types, that's why we couldn't remove the interface yet.
BTW, even that wouldn't help, because the creating process would depend
on the resource type of the resulting document and not on the resource
type of the document the usecase was called on (this wouldn't even have
to be a document).
I've read through the threads from last year, it seems this issue is
having a birthday this month :)
I'm not sure I understand the Document Creation usecase completely. So
I'll try and describe what I think is happening, could you point me in
the right direction if I'm completely lost?
org.apache.lenya.cms.site.usecases.Create is ultimately responsible for
creating new documents right? It is abstract and it has concrete classes
for different doctypes. Is this what you mean by polymorphic usecases?
Yes, exactly.
What I understand of the Create Usecase so far...
- get the document manager
- get a document with an identifier
- then getinitialdocument which is returned by the concrete extension of
the Create usecase
- we then go into documentManager.add
- this does nice stuff with metadata
- locks the repository node
- then calls the magical nodecreator thingo
- it seems to me the node creator just copies data from one sourceURI to
another...
Yes, this is how it works.
with an optional transformation which is never used?
It is used for instance in the BlogEntryCreator.
I assume the transformation inside the nodecreatorinterface is what is
meant to do the postprocessing?
Yes
Is it possible to make this post processing a part of the Create usecase
extension?
Yes, that would be the way to go. But you'd have to extend a usecase
handler class for that, with the downsides of inheritance. Apart from
that, it's an easy and straightforward approach, and I don't think
we'll find something better.
Would it be possible to define a post processing interface, then look up
the class name which implements this from the resource type metadata?
Yes, but that would be quite the same as we have now. The problem is
that the post processing component needs parameters, which depend on
the kind of post processing and this would need a magic container again.
Why is there a need for such post processing anyway? What possible
functions could it provide?
For instance, to initialize the content depending on values entered
on the "create document" screen, or on the current date etc.
Now, from my perspective, and the EJB work I've been doing, I've created
a Content interface, which gives me OutputStream, mimetype and stuff a
normal file would have. I'm then going to make extensions of this
interface for various types of data. Eg, forums, products in an online
store. I'm going to make a usecase to create, and edit these content
objects through their own interface, eg setPrice etc. I think this is
similar to making a DTD for a custom XML content, and then defining
usecases to edit it. Does a 'content' interface offer any advantages in
the document creation problem?
I guess this wouldn't solve the problem - you would have to implement a
specific create usecase for each content type (EJB class).
Thanks for your input!
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
[EMAIL PROTECTED] [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
