Dear Wiki user, You have subscribed to a wiki page or wiki category on "Lenya Wiki" for change notification.
The following page has been changed by WolfgangKaltz: http://wiki.apache.org/lenya/ProposalDocumentCreationAPI ------------------------------------------------------------------------------ ## page was renamed from DocumentCreationAPI - This page discusses the current state of the document creation API in trunk (Lenya 1.4) + This page discusses the current state of the document creation API in trunk (Lenya 1.4) and changes we probably want to do. - See current class diagram and sequence diagram below + The current situation of the API is documented (in part) in form of the class diagram and sequence diagram below. == Changes planned == - * move actual document creation from usecases to {{{DocumentManager.add()}}} - * consequently, {{{DocumentManager.add()}}} would no longer access the {{{SiteManager}}}, this would be the responsibility of the usecase. (This is necessary because not all publications need have a {{{SiteManager}}} -> see blog) - * AndreasHartmann: I disagree. Every publication has to have a site manager, we should probably provide a {{{FreeSiteManager}}} or something like that which does not store any structural information. + * (Andreas Hartmann) Every publication should have a site manager, we should probably provide a {{{FreeSiteManager}}} or something like that which does not store any structural information. + * Once we have that the parameter {{{useSiteManager}}} of {{{DocumentManager.add()}}} can be removed + * (Andreas Hartmann) there should be a {{{DocumentManager.add(document, documentType)}}} - * {{{DocumentManager.add()}}} is extended to take all necessary parameters for document creation, that is: - * (TODO: complete) - * Lenya internal meta-data, such as "resource type". Other meta-data is optional and thus not passed to {{{DocumentManager.add()}}}, it is the responsibility of the individual usecase. - * Open issue: what about {{{DocumentIdentityMap}}} ? Currently it creates a {{{Document}}} instance when {{{get()}}} is called on a (new) id. Do we want to keep that mechanism ? + == Current situation == + This section attempts to document the current situation. See class diagram and sequence diagram. Some additional notes: + * The mechanism where {{{DocumentIdentityMap}}} creates a {{{Document}}} instance when {{{get()}}} is called on a (new) id is not yet well documented + + - == Class diagram == + === Class diagram === attachment:documents.jpg - == Sequence diagram == + === Sequence diagram === attachment:documents-sequence.jpg - == 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: + - - 1. The {{{Create}}} usecase handler - 1. builds the {{{Document}}} object using the {{{DocumentIdentityMap}}} - 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). - 1. (optional) The {{{Create}}} usecase initializes the publication-specific meta data. - --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
