Thorsten Scherler wrote:
[...]
This is the side effect of the first observation that
binary files are "transformed" into xml documents.
Really? I don't think it is a side effect, rather a separate problem.
well, it is lying in
Document destinationDocument = sourceDocument.getIdentityMap()
.getAreaVersion(sourceDocument, destinationArea);
;)
I'll take a look at it.
In another use case I have a resource type "xType" that aggregates x
files to one document.
What do you mean with "files"?
Lenya doesn't support operations on files ...
The API provides functionality to handle documents.
Yeah, *xml* documents!
It should be able to handle arbitrary documents, not only XML.
Files like in any given content (binary
including). Thereby a file = document and the API provides so far only
functionality to handle xml documents. The is the root cause of so many
problemes that occured lately.
Yes, these issues have to be fixed.
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
Yes, that sounds reasonable.
to as well create the x-2 other files that my xType needs.
We should discuss if we want to allow documents to consist of
multiple sources.
I thought we already agreed on this.
I can't remember this - would you mind pointing me to the thread?
I just can remember that we wanted to allow to assemble documents
from different other documents using XInclude or a similar concept.
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.
Maybe we should add editing formats to the resource type declaration
as well:
<resource-type name="odt" ...>
...
<format name="edit-bxe" uri="..."/>
</resource-type>
sound reasonable.
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"/>
I'm not sure if this is the way to go. IMO resource types and
publishing should be orthogonal. Publishing is only about moving
documents from one area to another (and invoking some additional
tasks), it should work with all documents which can be handled
by Lenya without implementing custom publishing components.
Well like you said:
"(and invoking some additional tasks)" which are resource type specific.
Not necessarily. E.g., notification and static export are rather
publication specific. But they should be handled by the usecase anyway.
How can the resource type define those?
What resource-type specific tasks do you have in mind?
I can imagine that there are such tasks, but to find out
the requirements it would be nice to have some examples.
which I think should apply for all "components" working on resource
types:
Creator
Editor
Indexer
Publisher
LinkRewriter
....
I'm not convinced that this is really useful, but I'm not yet sure.
I'll think about it and maybe come up with another proposal.
lol
I wish that we can work together on this as community and not each other
on its own. Why do you want to come up with another one and not bring
this proposal to a verdict? ;)
Because I have the feeling that the problem is approached from
the wrong side. But, like I already said, I'll think about it
first and *maybe* come up with another proposal.
-- 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]
