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 Mon, 03 Apr 2006 07:21:33 GMT
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"?
It would be part of the API:

Document.addReference(Document, int referenceType)
Document.removeReference(Document)
Document.getReferences()
...

[...]

>> 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.

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.

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
   ...


>>>> 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?


>>> 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 ...

-- 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