You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Andreas Hartmann <an...@apache.org> on 2006/03/31 14:29:20 UTC

Re: [Proposal] Moving components configuration to the resource type API

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