lenya-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Wechner <michael.wech...@wyona.com>
Subject Re: [Proposal] Moving components configuration to the resource type API
Date Tue, 04 Apr 2006 09:32:53 GMT
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


Mime
View raw message