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/04/03 09:21:33 UTC
Re: [Proposal] Moving components configuration to the resource type
API
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
Re: [Proposal] Moving components configuration to the resource type
API
Posted by Andreas Hartmann <an...@apache.org>.
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
Re: [Proposal] Moving components configuration to the resource type
API
Posted by Michael Wechner <mi...@wyona.com>.
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