Moving components configuration to the resource type API

El vie, 31-03-2006 a las 10:53 +0200, Andreas Hartmann
escribió:
> 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.
> 
> That needs to be changed. I'll take a quick look at
it.

Thanks.

> 
> > 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 a bug, it has to be fixed.

agree

> 
> > 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);
;)

> 
> > 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! 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.

> 
> > 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. 

> 
> 
> > 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&
quot;/>
> 
> 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.
How can the resource type define those?

> 
> > 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? ;)

salu2
-- 
Thorsten Scherler
COO Spain
Wyona Inc.  -  Open Source Content Management  -  Apache
Lenya
http://www.wyona.com     
             http://lenya.apache.org
thorsten.scherlerwyona.com                thorstenapache.org


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribelenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org

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&
quot;/>
>> 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
andreas.hartmannwyona.com                     andreasapache.org


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribelenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org