Moving components configuration to the resource type API

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.w
ikipedia.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.wechnerwyona.com                        michiapache.org
+41 44 272 91 61


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribelenya.apache.org
For additional commands, e-mail: dev-helplenya.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.hartmannwyona.com                     andreasapache.org


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribelenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org