Josias Thöny wrote:
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, ...
similar to the source interface ;-)
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.
that's a common misunderstanding
It could be extended to a binary file, or even multiple
files, while Lenya still knows what a document is.
that's why we have the concept of a resource type
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.
you can always provide default implementations
Maybe we should do one step at a time and at first just allow binary
documents.
what do you mean by allow only binary documents?
Michi
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]
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
[EMAIL PROTECTED] [EMAIL PROTECTED]
+41 44 272 91 61
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
