[Yanel-dev] Re: Learning from Yanel?

Michael Wechner michael.wechner at wyona.com
Tue Apr 7 23:57:33 CEST 2009


Joachim Wolfgang Kaltz schrieb:
> Hi Michi
>
> thanks for your insights. There are several issues here and I'm still
> trying to sort them out ;)
>
> 1. Design principles
> Do I understand correctly: your resource objects say which interfaces, in
> which version, they implement. Does that mean that you store this
> information along with the contents?

no. There is a dedicated "repository" containing the resource type 
configurations. One can either do a one-to-one mapping, for example

/foo/bar.html

is mapped to

/foo/bar.html.yanel_rc (whereas this is an XML containing all the 
relevant resource type configuration)

or  use a map (also an XML containing patters)

/*.html

is mapped to

xhtml.yanel_rc

for example.

So the chain of responsibility is to check first if there exists a 
one-to-one mapping and if not then will check the map which contains 
patterns which might match.

(similar to Lenya which checks "first" the doctype, but  I would say 
more general)
>  If so, is it in XML,

resource configurations are in XML
>  or serialized
> Java objects, or ... (just being curious ;) )
> So next step, you read a resource and the controller knows which version
> of which interface this resource implements. If you keep the "old" code in
> your controller to support the older versions of the interfaces, you can
> handle them.
>   

the core will ask the resource (which handles a specific request) which 
interface version it implements and hence will handle it accordingly
> 2. Consequences
> I understand how this would simplify backwards compatibility, since the
> old code is still in the program and still works. But why would this
> result in less releases being necessary?
>   

because you don't need any releases anymore re the core itself (only the 
versioned interfaces are released, and as soon as they are, they will be 
carved in stone).
So one can do real continuous integration with the core itself
> 3. Relevancy to Lenya
> Do you see an incompatibility between this approach and what Lenya is
> doing?

I am not sure if I understand your question, because I would consider 
the core architecture re the resources of Yanel very different than how 
Lenya generates/handles content.
If your question is "what needs to be changed that Lenya can also 
support versioned interfaces", then I would say "let's first define what 
the current interfaces of Lenya are at the moment"
>  Is there something inherent in Lenya's design which would prohibit
> versioned interfaces? 

I guess the question would be what are the current interfaces of Lenya?
> At the moment, an argument that comes to my mind
> would be that the interfaces in Lenya are too complex and would make the
> implementation of versioned interfaces too hard to maintain - is this the
> main problem in your eyes, or something else?
>   

I don't think the number is the problem, but I would say that Lenya has 
many interfaces which are not spelled out as interfaces, but
still people build something on top of them and developers are suddenly 
changing them and everybody is suddenly surprised that they
are facing an upgrade nightmare. This is what I have experienced many 
times and Lenya is not the only CMF/S with this problem and this is
what we IMHO really solved with Yanel.

Cheers

Michael
> Thanks in advance for any further input!
>
> Wolfgang
>
>   
>>>> (...)
>>>> The main reasons I have started Yanel and use it today successfully
>>>> (and
>>>> not using Lenya anymore) are
>>>>
>>>> - backwards compatibility/upgradeability
>>>> - scalability/performance
>>>> (...)
>>>>
>>>> With Yanel we do not need releases anymore (except from a marketing
>>>> point of view), but can continuously upgrade at any time and it handles
>>>> arbitrary amount of content without a problem
>>>>
>>>>         
>>> Hi Michi
>>> IIUC you are saying that Yanel has design principles ensuring
>>> upgradeability. This sounds interesting, can you elaborate a bit?
>>>
>>>       
>> it's all about versioned interfaces
>>
>> http://yanel.wyona.org/javadoc/org/wyona/yanel/core/api/attributes/package-summary.html
>>
>> Yanel is at the core a framework with interfaces (with content
>> management characteristics) in order to build on.
>>
>> Interfaces/contracts/protocols have a good and bad side. Your
>> implementations break when they are being changed, but
>> you want them to break. So how to get out of this dilemma?
>>
>> The answer is "versioned interfaces" (just as some protocols also have a
>> version)
>>
>> So the basic element/unit  of Yanel is a so-called "resource" (or
>> "resource type"), which acts as controller, but has no capabilities in
>> the first place. Each request is mapped onto such a resource type
>> instance (similar as in Cocoon each request is mapped onto a pipeline).
>>
>> Now a resource type can become some life by applying some interfaces,
>> such as for example, viewable, modifiable, etc.
>>
>> These interfaces are versioned and the core of Yanel checks the versions
>> and handles them accordingly.
>>
>> Very simple and it works great :-)
>>
>> This way you can upgrade at any time without a problem.
>>
>> HTH
>>
>> Michael
>>     
>>> TIA
>>> Wolfgang
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe at lenya.apache.org
>>> For additional commands, e-mail: dev-help at lenya.apache.org
>>>
>>>
>>>       
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe at lenya.apache.org
>> For additional commands, e-mail: dev-help at lenya.apache.org
>>
>>
>>
>>     
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe at lenya.apache.org
> For additional commands, e-mail: dev-help at lenya.apache.org
>
>   



More information about the Yanel-development mailing list