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
|