You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Thorsten Scherler <th...@wyona.com> on 2006/03/31 10:41:26 UTC
[Proposal] 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"/>
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.scherler@wyona.com thorsten@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [Proposal] Moving components configuration to the resource
type API
Posted by Andreas Hartmann <an...@apache.org>.
Thorsten Scherler wrote:
[...]
>>>>> 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?
>
> There have been a couple of them e.g.
> http://marc.theaimsgroup.com/?t=113655405500001&r=1&w=2 and the emerging
> threads around it.
>
> Anyway we may should call a vote on it.
>
>> I just can remember that we wanted to allow to assemble documents
>> from different other documents using XInclude or a similar concept.
>
> Well, I do not really see the differents. ;)
There is a fundamental difference - does the assembly happen
above or below the document access layer? If I understand your
proposal correctly, you want to be able to assemble documents
from sources in a resource-type specific way. This would mean
to allow polymorphism below the document access layer:
- the resource type provides a specific implementation of
the internal document handling
- this way, *all* components which handle document internals must
be customizable
I would prefer to do the assembly above the document access layer:
- we provide a generic mechanism to create references between
documents
- the resource type uses different documents to assemble a
page by resolving references between documents
- all internal components are aware of the reference concept
and handle it appropriately, e.g. the Publisher publishes all
referenced documents as well. We could support several reference
handling types:
- don't follow references
- warn if referenced documents are not published
- just publish referenced documents
[...]
>>> 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.
>
> Hmm.
>
>>> How can the resource type define those?
>> What resource-type specific tasks do you have in mind?
>
> Imaginge doco. Here I want to publish the live site with forrest and
> lenya. First I want the sources moved and then using forrestbor via ant
> to generate a static html site and publish it to my server.
IMO this is publication-specific functionality and should be implemented
in doco's publish usecase, maybe based on interfaces + default components
provided by Lenya.
> Lenyas publishing is rather limited in this regards and it would be nice
> to reuse exiting components like forrest for thus tasks.
Sure, this can be done in doco.
>> I can imagine that there are such tasks, but to find out
>> the requirements it would be nice to have some examples.
>
> Multiple documents in a resource type. ;) You need to copy/publish x
> documents.
Yes, this should be supported (see above).
>>>>> 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.
>
> Well, then speak up and we need to find a way that fits.
I have the feeling that many requirements can be complied
by a thorough inter-document reference mechanism.
>> But, like I already said, I'll think about it
>> first and *maybe* come up with another proposal.
>>
>
> hmm, would save me some time if you give me your "out-of-the-head"
> thought about an alternative approach.
>
> Like we see on this discussion, maybe we need first allow multiple
> sourced and binary documents and then we may have solved already the
> limitations that emerged this proposal.
I agree.
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [Proposal] Moving components configuration to the resource
type API
Posted by Thorsten Scherler <th...@apache.org>.
El vie, 31-03-2006 a las 11:27 +0200, Andreas Hartmann escribió:
> 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?
There have been a couple of them e.g.
http://marc.theaimsgroup.com/?t=113655405500001&r=1&w=2 and the emerging
threads around it.
Anyway we may should call a vote on it.
> I just can remember that we wanted to allow to assemble documents
> from different other documents using XInclude or a similar concept.
Well, I do not really see the differents. ;)
>
> >>> 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.
Hmm.
>
> > How can the resource type define those?
>
> What resource-type specific tasks do you have in mind?
Imaginge doco. Here I want to publish the live site with forrest and
lenya. First I want the sources moved and then using forrestbor via ant
to generate a static html site and publish it to my server.
Lenyas publishing is rather limited in this regards and it would be nice
to reuse exiting components like forrest for thus tasks.
> I can imagine that there are such tasks, but to find out
> the requirements it would be nice to have some examples.
Multiple documents in a resource type. ;) You need to copy/publish x
documents.
>
>
> >>> 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.
Well, then speak up and we need to find a way that fits.
> But, like I already said, I'll think about it
> first and *maybe* come up with another proposal.
>
hmm, would save me some time if you give me your "out-of-the-head"
thought about an alternative approach.
Like we see on this discussion, maybe we need first allow multiple
sourced and binary documents and then we may have solved already the
limitations that emerged this proposal.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [Proposal] Moving components configuration to the resource
type API
Posted by Andreas Hartmann <an...@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"/>
>> 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.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [Proposal] Moving components configuration to the resource
type API
Posted by Thorsten Scherler <th...@wyona.com>.
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"/>
>
> 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.scherler@wyona.com thorsten@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [Proposal] Moving components configuration to the resource type
API
Posted by Andreas Hartmann <an...@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"/>
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.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [Proposal] Moving components configuration to the resource
type API
Posted by Andreas Hartmann <an...@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.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [Proposal] Moving components configuration to the resource
type API
Posted by Andreas Hartmann <an...@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.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [Proposal] Moving components configuration to the resource type
API
Posted by Andreas Hartmann <an...@apache.org>.
Michael Wechner wrote:
> Andreas Hartmann wrote:
>
>> Michael Wechner wrote:
>>
>> [...]
>>
>>>> If you use two Lenya documents, and use the (not yet existing)
>>>> reference mechanism to link from the primary document to the
>>>> secondary document, the internal Copier, Revisioner, and Deleter
>>>> components will be able to handle this just by following the
>>>> references if this is desired.
>>>
>>>
>>>
>>> which I would consider a very helpful implementation, but it shouldn't
>>> be confused with the API.
>>
>>
>> What do you mean with "confused with the API"?
>
>
> that the implementatio is becoming the API
What do you mean with "implementation is becoming the API"?
Both ways are possible - either you design an API and build
an implementation, or you have a proven implementation and
extract an API from it ...
>> It would be part of the API:
>>
>> Document.addReference(Document, int referenceType)
>> Document.removeReference(Document)
>> Document.getReferences()
>
>
> that's exactly what I think shouldn't be. This "reference
> implementation" shouldn't
> be the API, but maby I misunderstand something completely ...
How could you tell Lenya about references if reference
handling is not part of the API? The API is the interface
to communicate with Lenya - everything you can do must
be exposed through the API.
[...]
>> Imagine you have a JCR-based repository implementation.
>> Then your Copier interface might look like this:
>>
>> Copier.copy(Document src, Document dest, javax.jcr.Session session)
>>
>> In a RDBMS-based implementation, it might look like this:
>>
>> Copier.copy(Document src, Document dest, DBConnection conn)
>>
>> In a file system based implementation, it might look like this:
>>
>> Copier.copy(Document src, Document dest, File contentDir)
>>
>> And so on.
>
> that should be hidden by the (resource type) persistance manager
Sure, you can sum up the copying, versioning, ... into a
persistence manager interface, but that doesn't change anything
but terminology.
>> But if you want to export the Copier interface in the API,
>> you have to provide a generic parameter passing mechanism,
>> e.g. with a ParameterObject:
>>
>> Copier.copy(Documetn src, Document dest, RepoInformation info)
>>
>> That's not elegant at all.
>
>
> I think it should be
>
> Copier.copy(ResourceType src, ResourceType dest)
>
> resp.
>
> Copier.copy(ResourceTypeID src, ResourceTypeID dest)
??
Why do you want to copy resource *types*?
We're handling documents (resources), not resource types.
Or have I totally lost track? :)
>> BTW, this brings up another problem if we allow multiple repo
>> implementations:
>>
>> If you want to allow custom Copiers, Revisioners etc. for different
>> resource types, you end up with (resource types) x (repo impls)
>> implementations, e.g. a
>>
>> XhtmlJcrCopier
>> XhtmlFilesystemCopier
>> ...
>> OdtJcrCopier
>> OdtFilesystemCopier
>> ...
>>
>
> right, but I don't see a problem with it
Well, I wouldn't like it :)
What do the others think?
[...]
> right now every URL needs a Lenya meta file (1-to-1 mapping), e.g.
>
> calendar.html is being mapped to calendar/index_en.xml.meta
>
> but what if you have a proxy resource type for instance
>
>
> proxy/** --> proxy.meta (???)
>
> any you don't know what URLs are actually being available, then a
> wildcard rule help or
> if you have URLs like
>
>
> time/45654645656.html (time/**) ---> millis.meta
OK, thanks for explaining.
I guess that would need some new concepts in Lenya.
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [Proposal] Moving components configuration to the resource type
API
Posted by Michael Wechner <mi...@wyona.com>.
Andreas Hartmann wrote:
> Michael Wechner wrote:
>
> [...]
>
>>> If you use two Lenya documents, and use the (not yet existing)
>>> reference mechanism to link from the primary document to the
>>> secondary document, the internal Copier, Revisioner, and Deleter
>>> components will be able to handle this just by following the
>>> references if this is desired.
>>
>>
>>
>> which I would consider a very helpful implementation, but it shouldn't
>> be confused with the API.
>
>
> What do you mean with "confused with the API"?
that the implementatio is becoming the API
> It would be part of the API:
>
> Document.addReference(Document, int referenceType)
> Document.removeReference(Document)
> Document.getReferences()
that's exactly what I think shouldn't be. This "reference
implementation" shouldn't
be the API, but maby I misunderstand something completely ...
> ...
>
> [...]
>
>>> The more implementation options you want to give to the integrator,
>>> the more difficult it will be to design a comprehensible and
>>> maintainable framework.
>>
>>
>> it's not that complex. We already have everything, but we need to
>> abstractize it just as JCR is an API working on nodes and properties
>> instead working on directories and files ;-)
>
>
> Yes - the Lenya API should support working on documents.
> But a custom copier, deleter, ... would have to operate
> "behind the scenes".
>
>
>>> Another issue is the communication between components. You have
>>> to find a "least common denominator" to design interfaces. If
>>> you want to allow polymorphism for a family of components which
>>> operate on the same data, you're likely to end up with the
>>> MagicContainer antipattern (see the Creator interface). And IMO
>>> a ParameterObject should not be used fo inter-component
>>> communication.
>>
>>
>> can you give an example here as well?
>
>
> Imagine you have a JCR-based repository implementation.
> Then your Copier interface might look like this:
>
> Copier.copy(Document src, Document dest, javax.jcr.Session session)
>
> In a RDBMS-based implementation, it might look like this:
>
> Copier.copy(Document src, Document dest, DBConnection conn)
>
> In a file system based implementation, it might look like this:
>
> Copier.copy(Document src, Document dest, File contentDir)
>
> And so on.
that should be hidden by the (resource type) persistance manager
>
>
> But if you want to export the Copier interface in the API,
> you have to provide a generic parameter passing mechanism,
> e.g. with a ParameterObject:
>
> Copier.copy(Documetn src, Document dest, RepoInformation info)
>
> That's not elegant at all.
I think it should be
Copier.copy(ResourceType src, ResourceType dest)
resp.
Copier.copy(ResourceTypeID src, ResourceTypeID dest)
>
> BTW, this brings up another problem if we allow multiple repo
> implementations:
>
> If you want to allow custom Copiers, Revisioners etc. for different
> resource types, you end up with (resource types) x (repo impls)
> implementations, e.g. a
>
> XhtmlJcrCopier
> XhtmlFilesystemCopier
> ...
> OdtJcrCopier
> OdtFilesystemCopier
> ...
>
right, but I don't see a problem with it
>
>>>>> 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.
>>>>
>>>>
>>>>
>>>>
>>>> yes, but what is the alternative?
>>>
>>>
>>>
>>> IMO the reference concept is sufficient to fulfil the requirements
>>> mentioned until now.
>>
>>
>>
>> maybe it is, maybe it's not. My experience tells me that everytime one
>> thinks one has now covered all usecases, a new usecase pops up.
>>
>> Off Topic: for instance I think the 1-to-1 mapping of "lenya meta
>> files" is not
>> sufficient as it is today, because for instance the usecase of
>> dynamic URLs, e.g.
>> the timestamp, or proxy requests are not covered, but can only be
>> covered by
>> allowing more general patters after the 1-to-1 mapping.
>
>
> I don't quite understand this - could you please give an example?
right now every URL needs a Lenya meta file (1-to-1 mapping), e.g.
calendar.html is being mapped to calendar/index_en.xml.meta
but what if you have a proxy resource type for instance
proxy/** --> proxy.meta (???)
any you don't know what URLs are actually being available, then a
wildcard rule help or
if you have URLs like
time/45654645656.html (time/**) ---> millis.meta
...
>
>
>>>> And as said above I don't think that's a problem
>>>> because of the argument above. Also one can offer tools to simplify
>>>> the process, just as
>>>> for instance there are tools to create XML Schemas, etc.
>>>
>>>
>>>
>>> Well, IMO the major problem is that it is much harder to achieve
>>> stability and backwards compatibility when the API becomes more
>>> complex.
>>
>>
>>
>> as said, I don't think it's more complex, but less specific, whereas
>> in most problems maybe one specific implementation can be used.
>>
>> I understand the difficulty to abstractize, because it took me for
>> instance a long
>> time to understand how specific polynomials can form a vector space:
>>
>> http://en.wikipedia.org/wiki/Examples_of_vector_spaces
>> http://en.wikipedia.org/wiki/Vector_space
>>
>> but recognizing it in the end will solve a lot of problems very quickly.
>>
>> And I think recognizing the generic API and providing implementations
>> (as the by you mentioned reference implementation) will make things
>> very simple in the end.
>
>
> OK, let's see where this thread leads us ...
;-)
Michi
>
> -- Andreas
>
>
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
+41 44 272 91 61
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [Proposal] Moving components configuration to the resource type
API
Posted by Andreas Hartmann <an...@apache.org>.
Michael Wechner wrote:
[...]
>> If you use two Lenya documents, and use the (not yet existing)
>> reference mechanism to link from the primary document to the
>> secondary document, the internal Copier, Revisioner, and Deleter
>> components will be able to handle this just by following the
>> references if this is desired.
>
>
> which I would consider a very helpful implementation, but it shouldn't
> be confused with the API.
What do you mean with "confused with the API"?
It would be part of the API:
Document.addReference(Document, int referenceType)
Document.removeReference(Document)
Document.getReferences()
...
[...]
>> The more implementation options you want to give to the integrator,
>> the more difficult it will be to design a comprehensible and
>> maintainable framework.
>
> it's not that complex. We already have everything, but we need to
> abstractize it just as JCR is an API working on nodes and properties
> instead working on directories and files ;-)
Yes - the Lenya API should support working on documents.
But a custom copier, deleter, ... would have to operate
"behind the scenes".
>> Another issue is the communication between components. You have
>> to find a "least common denominator" to design interfaces. If
>> you want to allow polymorphism for a family of components which
>> operate on the same data, you're likely to end up with the
>> MagicContainer antipattern (see the Creator interface). And IMO
>> a ParameterObject should not be used fo inter-component
>> communication.
>
> can you give an example here as well?
Imagine you have a JCR-based repository implementation.
Then your Copier interface might look like this:
Copier.copy(Document src, Document dest, javax.jcr.Session session)
In a RDBMS-based implementation, it might look like this:
Copier.copy(Document src, Document dest, DBConnection conn)
In a file system based implementation, it might look like this:
Copier.copy(Document src, Document dest, File contentDir)
And so on.
But if you want to export the Copier interface in the API,
you have to provide a generic parameter passing mechanism,
e.g. with a ParameterObject:
Copier.copy(Documetn src, Document dest, RepoInformation info)
That's not elegant at all.
BTW, this brings up another problem if we allow multiple repo
implementations:
If you want to allow custom Copiers, Revisioners etc. for different
resource types, you end up with (resource types) x (repo impls)
implementations, e.g. a
XhtmlJcrCopier
XhtmlFilesystemCopier
...
OdtJcrCopier
OdtFilesystemCopier
...
>>>> 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.
>>>
>>>
>>>
>>> yes, but what is the alternative?
>>
>>
>> IMO the reference concept is sufficient to fulfil the requirements
>> mentioned until now.
>
>
> maybe it is, maybe it's not. My experience tells me that everytime one
> thinks one has now covered all usecases, a new usecase pops up.
>
> Off Topic: for instance I think the 1-to-1 mapping of "lenya meta files"
> is not
> sufficient as it is today, because for instance the usecase of dynamic
> URLs, e.g.
> the timestamp, or proxy requests are not covered, but can only be
> covered by
> allowing more general patters after the 1-to-1 mapping.
I don't quite understand this - could you please give an example?
>>> And as said above I don't think that's a problem
>>> because of the argument above. Also one can offer tools to simplify
>>> the process, just as
>>> for instance there are tools to create XML Schemas, etc.
>>
>>
>> Well, IMO the major problem is that it is much harder to achieve
>> stability and backwards compatibility when the API becomes more
>> complex.
>
>
> as said, I don't think it's more complex, but less specific, whereas
> in most problems maybe one specific implementation can be used.
>
> I understand the difficulty to abstractize, because it took me for
> instance a long
> time to understand how specific polynomials can form a vector space:
>
> http://en.wikipedia.org/wiki/Examples_of_vector_spaces
> http://en.wikipedia.org/wiki/Vector_space
>
> but recognizing it in the end will solve a lot of problems very quickly.
>
> And I think recognizing the generic API and providing implementations
> (as the by you mentioned reference implementation) will make things very
> simple in the end.
OK, let's see where this thread leads us ...
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [Proposal] Moving components configuration to the resource type
API
Posted by Michael Wechner <mi...@wyona.com>.
Andreas Hartmann wrote:
> Michael Wechner wrote:
>
>> Andreas Hartmann wrote:
>>
>>> 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.
>>
>>
>>
>> I don't fully understand. Can you give an example?
>
>
> Imagine a resource type which uses a binary source and an XML source
> for a document.
>
> If you allow this, you have to
>
> - implement a Copier which copies these two files
> - implement a Revisioner which backs up / restores these two files
> - implement a Deleter which deletes these two files
> - ...
right
>
> If you use two Lenya documents, and use the (not yet existing)
> reference mechanism to link from the primary document to the
> secondary document, the internal Copier, Revisioner, and Deleter
> components will be able to handle this just by following the
> references if this is desired.
which I would consider a very helpful implementation, but it shouldn't
be confused with the API.
> You could maybe compare this with
> the onParentVersion functionality of JCR.
>
> [...]
>
>>>>> 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.
>>
>>
>>
>> I think it does. In probably most cases you don't have to implement
>> it yourself
>> but pick an existing one
>
>
> I didn't mean the complexity of a single implementation, but
> the complexity of the API (I'm not sure what Josias meant).
>
> The more implementation options you want to give to the integrator,
> the more difficult it will be to design a comprehensible and
> maintainable framework.
it's not that complex. We already have everything, but we need to
abstractize it just as JCR is an API working on nodes and properties
instead working on directories and files ;-)
>
> Another issue is the communication between components. You have
> to find a "least common denominator" to design interfaces. If
> you want to allow polymorphism for a family of components which
> operate on the same data, you're likely to end up with the
> MagicContainer antipattern (see the Creator interface). And IMO
> a ParameterObject should not be used fo inter-component
> communication.
>
can you give an example here as well?
>
>>> 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.
>>
>>
>>
>> yes, but what is the alternative?
>
>
> IMO the reference concept is sufficient to fulfil the requirements
> mentioned until now.
maybe it is, maybe it's not. My experience tells me that everytime one
thinks one has now covered all usecases, a new usecase pops up.
Off Topic: for instance I think the 1-to-1 mapping of "lenya meta files"
is not
sufficient as it is today, because for instance the usecase of dynamic
URLs, e.g.
the timestamp, or proxy requests are not covered, but can only be covered by
allowing more general patters after the 1-to-1 mapping.
>
>> And as said above I don't think that's a problem
>> because of the argument above. Also one can offer tools to simplify
>> the process, just as
>> for instance there are tools to create XML Schemas, etc.
>
>
> Well, IMO the major problem is that it is much harder to achieve
> stability and backwards compatibility when the API becomes more
> complex.
as said, I don't think it's more complex, but less specific, whereas
in most problems maybe one specific implementation can be used.
I understand the difficulty to abstractize, because it took me for
instance a long
time to understand how specific polynomials can form a vector space:
http://en.wikipedia.org/wiki/Examples_of_vector_spaces
http://en.wikipedia.org/wiki/Vector_space
but recognizing it in the end will solve a lot of problems very quickly.
And I think recognizing the generic API and providing implementations
(as the by you mentioned reference implementation) will make things very
simple in the end.
Michi
>
> -- Andreas
>
>
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
+41 44 272 91 61
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [Proposal] Moving components configuration to the resource type
API
Posted by Andreas Hartmann <an...@apache.org>.
Michael Wechner wrote:
> Andreas Hartmann wrote:
>
>> 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.
>
>
> I don't fully understand. Can you give an example?
Imagine a resource type which uses a binary source and an XML source
for a document.
If you allow this, you have to
- implement a Copier which copies these two files
- implement a Revisioner which backs up / restores these two files
- implement a Deleter which deletes these two files
- ...
If you use two Lenya documents, and use the (not yet existing)
reference mechanism to link from the primary document to the
secondary document, the internal Copier, Revisioner, and Deleter
components will be able to handle this just by following the
references if this is desired. You could maybe compare this with
the onParentVersion functionality of JCR.
[...]
>>>> 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.
>
>
> I think it does. In probably most cases you don't have to implement it
> yourself
> but pick an existing one
I didn't mean the complexity of a single implementation, but
the complexity of the API (I'm not sure what Josias meant).
The more implementation options you want to give to the integrator,
the more difficult it will be to design a comprehensible and
maintainable framework.
Another issue is the communication between components. You have
to find a "least common denominator" to design interfaces. If
you want to allow polymorphism for a family of components which
operate on the same data, you're likely to end up with the
MagicContainer antipattern (see the Creator interface). And IMO
a ParameterObject should not be used fo inter-component
communication.
>> 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.
>
>
> yes, but what is the alternative?
IMO the reference concept is sufficient to fulfil the requirements
mentioned until now.
> And as said above I don't think that's
> a problem
> because of the argument above. Also one can offer tools to simplify the
> process, just as
> for instance there are tools to create XML Schemas, etc.
Well, IMO the major problem is that it is much harder to achieve
stability and backwards compatibility when the API becomes more
complex.
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [Proposal] Moving components configuration to the resource type
API
Posted by Michael Wechner <mi...@wyona.com>.
Andreas Hartmann wrote:
> 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.
I don't fully understand. Can you give an example?
>
>
>>> 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.
and that's what I meant, let's improve it ...
>
>
>>> 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.
I think it does. In probably most cases you don't have to implement it
yourself
but pick an existing one
> 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.
yes, but what is the alternative? And as said above I don't think that's
a problem
because of the argument above. Also one can offer tools to simplify the
process, just as
for instance there are tools to create XML Schemas, etc.
Michi
>
> -- Andreas
>
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
+41 44 272 91 61
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [Proposal] Moving components configuration to the resource type
API
Posted by Andreas Hartmann <an...@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.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [Proposal] Moving components configuration to the resource type
API
Posted by Michael Wechner <mi...@wyona.com>.
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: dev-unsubscribe@lenya.apache.org
>For additional commands, e-mail: dev-help@lenya.apache.org
>
>
>
>
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
+41 44 272 91 61
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [Proposal] Moving components configuration to the resource
type API
Posted by Josias Thöny <jo...@wyona.com>.
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: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [Proposal] Moving components configuration to the resource type
API
Posted by Andreas Hartmann <an...@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.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [Proposal] Moving components configuration to the resource
type API
Posted by Thorsten Scherler <th...@wyona.com>.
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.ResourceTypeImpl">
<creator src="org.apache.lenya.cms.authoring.DefaultBranchCreator">
<sample-name>fallback://lenya/modules/opendocument/samples/helloworld.odt</sample-name>
</creator>
<publisher src="org.apache.lenya.cms.authoring.DefaultPublisher"/>
<editor src="org.apache.lenya.cms.authoring.DefaultEditor" />
...
<format name="xhtml" uri="cocoon://modules/opendocument/xhtml.xml"/>
<format name="webdavGET"
uri="cocoon://modules/opendocument/davget.xml"/>
</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.scherler@wyona.com thorsten@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [Proposal] Moving components configuration to the resource type
API
Posted by Michael Wechner <mi...@wyona.com>.
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.wechner@wyona.com michi@apache.org
+41 44 272 91 61
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org