List Info

Thread: Moving components configuration to the resource type API




Moving components configuration to the resource type API
user name
2006-03-31 10:21:33
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&a
mp;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&
quot;/>
> >> I'm not sure if this is the way to go. IMO
resource types and
> >> publishing should be orthogonal. Publishing is
only about moving
> >> documents from one area to another (and
invoking some additional
> >> tasks), it should work with all documents
which can be handled
> >> by Lenya without implementing custom
publishing components.
> >>
> > 
> > Well like you said:
> > "(and invoking some additional tasks)"
which are resource type specific.
> 
> Not necessarily. E.g., notification and static export
are rather
> publication specific. But they should be handled by the
usecase anyway.

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

Moving components configuration to the resource type API
user name
2006-03-31 12:29:20
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&a
mp;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.hartmannwyona.com                     andreasapache.org


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

[1-2]

about | contact  Other archives ( Real Estate discussion Medical topics )