Moving components configuration to the resource type API

Andreas Hartmann wrote:

> Michael Wechner wrote:
>
> [...]
>
>>>> which I think should apply for all
"components" working on resource
>>>> types:
>>>> Creator
>>>> Editor
>>>> Indexer
>>>> Publisher
>>>> LinkRewriter
>>>> ....
>>>>   
>>>
>>>
>>> If we allow this, we would also need a
resource-type specific Mover,
>>> Copier, Deleter, Deactivator, Revisioner, ...
>>>
>>
>> similar to the source interface 
>
>
> It's not really similar. The source interface is a
single entry point
> to access resources using a protocol. There are no
cross-connections
> if you use the concept consequently (i.e., always use
the protocol and
> therefore the source implementation to access these
resources)
>
> The components mentioned by Josias have multiple
cross-connections.
> Providing a specific implementation for one of them
requires to
> provide implementations for the others as well.


I don't fully understand. Can you give an example?

>
>
>>> The basic question seems to be whether Lenya
knows what a document 
>>> is or
>>> not (and how to move it around, for example).
So far, a document is 
>>> just
>>> an xml file.
>>
>>
>> that's a common misunderstanding
>
>
> Josias just pointed out how it is implemented today.
> But I guess all of us are aware that we'd like to
change that.


and that's what I meant, let's improve it ...

>
>
>>> It could be extended to a binary file, or even
multiple
>>> files, while Lenya still knows what a document
is.
>>>  
>>
>>
>> that's why we have the concept of a resource type
>>
>>> But if we allow that a document may be
"anything", and only the 
>>> resource
>>> type knows what it is, the complexity seems to
grow quite a lot (of
>>> course the flexibility would increase, too). It
might also lead to
>>> duplication of knowledge if each resource type
has e.g. its own
>>> publisher. 
>>
>>
>> you can always provide default implementations
>
>
> But that doesn't reduce the complexity.


I think it does. In probably most cases you don't have to
implement it 
yourself
but pick an existing one

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

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:
>>
>> [...]
>>
>>>>> which I think should apply for all
"components" working on resource
>>>>> types:
>>>>> Creator
>>>>> Editor
>>>>> Indexer
>>>>> Publisher
>>>>> LinkRewriter
>>>>> ....
>>>>>   
>>>>
>>>>
>>>> If we allow this, we would also need a
resource-type specific Mover,
>>>> Copier, Deleter, Deactivator, Revisioner,
...
>>>>
>>>
>>> similar to the source interface 
>>
>>
>> It's not really similar. The source interface is a
single entry point
>> to access resources using a protocol. There are no
cross-connections
>> if you use the concept consequently (i.e., always
use the protocol and
>> therefore the source implementation to access these
resources)
>>
>> The components mentioned by Josias have multiple
cross-connections.
>> Providing a specific implementation for one of them
requires to
>> provide implementations for the others as well.
> 
> 
> I don't fully understand. Can you give an example?

Imagine a resource type which uses a binary source and an
XML source
for a document.

If you allow this, you have to

- implement a Copier which copies these two files
- implement a Revisioner which backs up / restores these two
files
- implement a Deleter which deletes these two files
- ...

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. You could maybe compare this
with
the onParentVersion functionality of JCR.

[...]

>>>> But if we allow that a document may be
"anything", and only the 
>>>> resource
>>>> type knows what it is, the complexity seems
to grow quite a lot (of
>>>> course the flexibility would increase,
too). It might also lead to
>>>> duplication of knowledge if each resource
type has e.g. its own
>>>> publisher. 
>>>
>>>
>>> you can always provide default implementations
>>
>>
>> But that doesn't reduce the complexity.
> 
> 
> I think it does. In probably most cases you don't have
to implement it 
> yourself
> but pick an existing one

I didn't mean the complexity of a single implementation,
but
the complexity of the API (I'm not sure what Josias meant).

The more implementation options you want to give to the
integrator,
the more difficult it will be to design a comprehensible and
maintainable framework.

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.


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

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

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