Moving components configuration to the resource type API

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&
quot;/>
  

which I think should apply for all "components"
working on resource
types:
Creator
Editor
Indexer
Publisher
LinkRewriter
....

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

>
>The core would then know when to delegate to core or to
resource type
>implementation.
>
>wdyt?
>  
>

you mean something like

ODTResourceType extends ResourceType implements Creator,
Editor, 
Indexer, Publisher, LinkRewriter

or

FolderResourceType ResourceType implements Creator,
Publisher

?

Michi

>salu2
>  
>


-- 
Michael Wechner
Wyona      -   Open Source Content Management   -    Apache
Lenya
http://www.wyona.com     
                http://lenya.apache.org
michael.wechnerwyona.com                        michiapache.org
+41 44 272 91 61


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

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.


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


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


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


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


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


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


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

Thanks for sharing your thoughts, this issue has to be
discussed
in any case.

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

El vie, 31-03-2006 a las 10:46 +0200, Michael Wechner
escribió:
> Thorsten Scherler wrote:
> 
> >
> >The core would then know when to delegate to core
or to resource type
> >implementation.
> >
> >wdyt?
> >  
> >
> 
> you mean something like
> 
> ODTResourceType extends ResourceType implements
Creator, Editor, 
> Indexer, Publisher, LinkRewriter
> 
> or
> 
> FolderResourceType ResourceType implements Creator,
Publisher
> 
> ?
> 

Not sure yet.

...but above seems a wee bit messy in the end.

I thought about something like this:

<xconf xpath="/cocoon/resource-types"
unless="/cocoon/resource-types/component-instance[name =
'opendocument']">

  <component-instance name="opendocument"
 logger="lenya.resourcetypes.opendocument"
class="org.apache.lenya.cms.publication.ResourceTypeIm
pl">

   <creator
src="org.apache.lenya.cms.authoring.DefaultBranchCreat
or">
<sample-name>fallback://lenya/modules/opendocument/sam
ples/helloworld.odt</sample-name>
   </creator>
   <publisher
src="org.apache.lenya.cms.authoring.DefaultPublisher&
quot;/>
   <editor
src="org.apache.lenya.cms.authoring.DefaultEditor&quo
t; />
...
   <format name="xhtml"
uri="cocoon://modules/opendocument/xhtml.xml"/&g
t;
   <format name="webdavGET"
uri="cocoon://modules/opendocument/davget.xml"/&
gt;
  </component-instance>

</xconf>

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

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&
quot;/>
>   
> 
> 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: dev-unsubscribelenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org

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.

[...]

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


I fixed these issues, please review.

The problem was that RepositoryManagerImpl.copy copied the
document
source before the meta data, so that the destination
document didn't
use the same source extension as the source document. I
switched the
order of these calls.

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

Josias Thöny wrote:

[...]

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

Yes, this is true.

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

Big +1

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

I agree, otherwise we'll open too many construction sites.
In the end, we want to release 1.4 someday ...

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

Josias Thöny wrote:

[...]

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

To clarify this from an OO development point of view:

Thorsten proposes to allow resource-type specific
polymorphic behaviour
of components in the document management API. But
polymorphism is only
applicable for purely interface-based architectures:


+--------+    +---------------+         +-------+
| Client |--->| <<interface>> |     +---|
ImplA |
+--------+    | Service       |<|---+   +-------+
               +---------------+     |
                                     |   +-------+
                                     +---| ImplB |
                                         +-------+

You run into serious trouble if you allow polymorphism for
internal components:

+--------+    +------+  +------+       +-------+
| Client |--->| Serv |->| Copy |<|-+---+ CopyA
|---+
+--------+    +------+  +------+   |   +-------+   |
                   |                |               |
                   |                |   +-------+   |
                   |                +---| CopyB |---+
                   |                    +-------+   |
                   |                                |
                   |     +--------+                 |
                   +---->| Source |<----------------+
                         +--------+

If you change the internal Source class later on, the
CopyA and CopyB implementations will fail.

So you would have to add internal details (e.g., how sources
are accessed) to the public API to allow the customer to add
different implementations of the Copy component.

Adding former internals to the public API would lead to a
massive increment of the size of the public API, with the
following implications:

- breaking up encapsulation will decrease safety
- the API becomes more complex and harder to understand
- development agility will be lost
- changes will be avoided to ensure backwards compatibility

Usually, the goal is to design an API so that the complete
desired behaviour can be accessed using a minimal set of
operations. If you want to achieve flexibility and a minimal
API at the same time, you have to reduce the provided
functionality. Compare, e.g., JCR with Lenya. JCR is much
more flexible, but Lenya is more powerful regarding document
and asset management functionality.

With Thorsten's proposal we will gain flexibility, but we
should be aware of the downsides of this approach.

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

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&
quot;/>
>>  
>>
>>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: dev-unsubscribelenya.apache.org
>For additional commands, e-mail: dev-helplenya.apache.org
>
>
>  
>


-- 
Michael Wechner
Wyona      -   Open Source Content Management   -    Apache
Lenya
http://www.wyona.com     
                http://lenya.apache.org
michael.wechnerwyona.com                        michiapache.org
+41 44 272 91 61


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

Michael Wechner wrote:

[...]

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

It's not really similar. The source interface is a single
entry point
to access resources using a protocol. There are no
cross-connections
if you use the concept consequently (i.e., always use the
protocol and
therefore the source implementation to access these
resources)

The components mentioned by Josias have multiple
cross-connections.
Providing a specific implementation for one of them requires
to
provide implementations for the others as well.


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

Josias just pointed out how it is implemented today.
But I guess all of us are aware that we'd like to change
that.


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

But that doesn't reduce the complexity. If implementing a
custom
resource type means to implement all these mentioned
components,
it means to virtually implement a document management system
for
each advanced and complex resource type.

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