On Fri, 2006-03-31 at 10:41 +0200, Thorsten Scherler wrote:
> Hi all,
>
> I was trying to publish opendocuments (odt) and was not really
> suprised ;) about following finding:
>
> 1) The documentManager.copyToArea(sourceDocument, destination) is
> *always* assuming a XML doc.
> org.apache.lenya.cms.publication.DocumentManagerImpl.java
> public void copyToArea(Document sourceDocument, String
> destinationArea)
> throws PublicationException {
> Document destinationDocument = sourceDocument.getIdentityMap()
> .getAreaVersion(sourceDocument, destinationArea);
> copy(sourceDocument, destinationDocument);
> }
> That is leading to the phenomenon that the resulting documents are not
> binary anymore and unusable.
>
> 2) The destination document is "loosing" its original extension. The
> resulting document is called now index_en.xml and not like in authoring
> index_en.odt. This is the side effect of the first observation that
> binary files are "transformed" into xml documents.
>
> In another use case I have a resource type "xType" that aggregates x
> files to one document. If I publish with this xType only 2 files are
> taken into account. Further if I upload a file of the xType resource
> type via webdav PUT, I would need to access the xType specific create
> methods to as well create the x-2 other files that my xType needs.
>
> Further as soon as I want to edit e.g. a odt document with e.g. BXE it
> will request the binary document and I cannot edit it. Regardless
> whether the odt is a zip of xml files and it is certainly possible to
> edit the main xml file of the odt if I could define a resource type
> specific "Editing" implementation.
>
> With the current architecture this seems not to be possible without a
> lot of hacks.
>
> The resource type needs to configure e.g. a Publisher similar to the
> creator:
>
> <publisher src="org.apache.lenya.cms.authoring.DefaultPublisher"/>
>
>
> which I think should apply for all "components" working on resource
> types:
> Creator
> Editor
> Indexer
> Publisher
> LinkRewriter
> ....
If we allow this, we would also need a resource-type specific Mover,
Copier, Deleter, Deactivator, Revisioner, ...
The basic question seems to be whether Lenya knows what a document is or
not (and how to move it around, for example). So far, a document is just
an xml file. It could be extended to a binary file, or even multiple
files, while Lenya still knows what a document is.
But if we allow that a document may be "anything", and only the resource
type knows what it is, the complexity seems to grow quite a lot (of
course the flexibility would increase, too). It might also lead to
duplication of knowledge if each resource type has e.g. its own
publisher.
Maybe we should do one step at a time and at first just allow binary
documents.
just my 2 cents
- Josias
>
> This allows that resource types can implement their own logic for the
> components. The resource type will register whether or not it is using
> its own implementation aka
> private boolean defaultCreator = false;
>
> The core would then know when to delegate to core or to resource type
> implementation.
>
> wdyt?
>
> salu2
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
