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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
