J. Wolfgang Kaltz wrote:
Apache Wiki schrieb:
+ == Some comments by AndreasHartmann ==
+ + * IMO there's still to much knowledge in the {{{Create}}}
usecase. I'd rather delegate the whole creation process to the
DocumentManager:
yes
+ + 1. The {{{Create}}} usecase handler
+ 1. builds the {{{Document}}} object using the
{{{DocumentIdentityMap}}}
Maybe we can delegate that to DocumentManager.add() as well, which would
return the instance when done
OK, that would be possible. But it is not unclean to work with
Document objects which are not represented by "real" documents
(XML, sitetree entry etc.). Passing the Document object leads to
a shorter signature than DocumentIdentityMap + publication + area + ...
+ 1. builds the {{{DocumentType}}} object using the
{{{DocumentTypeBuilder}}}
+ 1. calls {{{DocumentManager.add(document, documentType)}}}
+ 1. The {{{DocumentManager}}} delegates the creation process to
the {{{Creator}}} of the document type.
+ 1. (optional) The {{{Create}}} usecase writes another content XML
to the document (if a new language version is created).
We now have the parameter "initialContentsURI" for the creator, we could
pass that through DocumentManager.add() along with the other new params
Yes, I also considered that. Actually IMO the sample location should
not be exposed by the Creator interface, since it is an implementation
detail. Additionally, it may be possible to create documents "from
scratch" without a sample (e.g., collections).
I'd rather have the following methods:
DocumentManager.add(document, documentType);
DocumentManager.add(document, documentType, sourceDocument);
where the second one clones a source document.
+ 1. (optional) The {{{Create}}} usecase initializes the
publication-specific meta data.
I will try to factor the creation code as discussed from the usecases
into DocumentManager.add()
AFAICT the only problem is the call to the site manager, which throws an
exception if triggered by a blog entry creation, since blog does not
have a site manager.
Then we should implement a site manager which does not restrict
the site structure (mostly emtpy method bodies). What I'm still
missing is a reasonable class name ... :)
-- Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
