lenya-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Hartmann <andr...@apache.org>
Subject Re: [Proposal] Moving components configuration to the resource type API
Date Tue, 04 Apr 2006 10:16:17 GMT
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


Mime
View raw message