Michael Wechner wrote:
Andreas Hartmann wrote:
Michael Wechner wrote:
[...]
The major problem of Lenya 1.4 is that Lenya forces you to accept a
specific
data structure
This is not true. You can implement custom NodeFactory classes to
support arbitrary storage facilities. The current refactoring has the
goal to make it clearer how to extend the core with custom functionality.
ok. How can this be done? Can you give me a pointer?
One example is the JCRNodeFactory in the jcrsource module. It returns
JCRSourceNode objects, which use JCR sources to store the content:
/**
* @see org.apache.lenya.cms.repository.SourceNode#getRealSourceURI()
*/
protected String getRealSourceURI() {
String path = this.sourceUri.substring(LENYA_PROTOCOL.length());
return "jcr://" + path;
}
You can implement a custom NodeFactory which returns custom Node objects.
You don't even have to use sources but can implement arbitrary node
classes, e.g. Node.getInputStream() and Node.getOutputStream() can
use arbitrary files to store the content, depending on the source URI.
There are some restrictions (yet?):
- The node has no access to the document it belongs to, since nodes
are generally used (also by sitetrees etc.).
- The node factory can't be determined based on the resource type.
Well, you could implement a hack and the functionality to the node
class, which has access to the meta data and therefore to the resource
type, but I wouldn't recommend that.
which doesn't make sense, because it's a lock-in and totally
unecessary, because if one separates the navigation properly from the
data storage
with a good data abstraction layer in between, then it's no problem
at all.
Then please come up with this good data abstraction layer. I already
proposed an API draft, and I'm trying to bend the existing code slowly
in this direction (separate the data access API from the actual
implementation and allow different implementations).
I once made a proposal re ResourceTypes, Resources, etc. and using
interfaces for Publishing, Creating , e.g.
XHTMLResource implemets Creatable, Publishable
public void publish()
public void create()
public Source getSource()
...
just as each node has meta, one would also have a resource config for
each node
IMO this is not a recommendable architecture, since the stage where
polymorphism is allowed is too high. But this is worth another thread,
I guess there is more need for discussion.
When I started Lenya some years ago that was one of my major goals
and I still think it's one of the most important things re content
management, because it means
one can share information with other applications, build on content
repositories of
other applications (e.g. DSpace) and no content migration is
necessary anymore.
IMO the maintenance burden of allowing custom persistence layer
implementations is very high, but nevertheless I'm still working in
this direction.
well, I am convinced a high percentage could be solved by very few such
implementations
I think it's not the burden by these implementations, but by the complexity
of the framework to allow custom implementations. But maybe I'll be
convinced by an architectural proposal which covers concern areas like
centrally managed transactions, data consistency, and performance.
This means you don't have to worry about backwards compatibility
anymore re content.
I don't understand this implication ...
IIUC you mean that custom persistence layer implementations should be
supported (even depending on the resource type, though I don't yet
fully understand how this can be achieved if the meta data are stored
in a resource-type specific repository - isn't this a chicken-and-egg
problem again?).
I don't think so. But I guess I just have to implement it to prove that
this is possible.
I'd just like to see a draft of the architecture or something like that.
Re the rest of Lenya I can tell you one thing for sure: There will
always be changes. So one has to think how to live with that without
breaking backwards compatibility. There are several ways to deal with
this, e.g.
- deprecation (instead just removing stuff)
+1 in stable branches
-1 in trunk because it unacceptably slows down development
why does it slow down development?
Because it requires a certain amount of time until the API can
be changed. If other changes depend on this change, the development
is stalled. How long should one wait before removing a deprecated
interface from the trunk?
[...]
- madatory migration tools in the case of breaking backwards
compatibility.
+1 in stable branches
-1 in trunk (see above)
well, it's like eating properly at home such that one will be prepared
eating properly when visiting someone.
Also it makes one realize what a change re breaking things actually means.
And third, when a release is getting close one always needs productive
environments to get things finalized.
If this productive environment is under your control, you can implement
a custom migration tool.
Unfortunately I don't see this happening currently within this
community and
the reason I think this is not happening is because some of the core
developers
are either not using Lenya in production or are considering it as
their private toy.
IMO this is a wrong conclusion. I think that the trunk development
should be very lively, and that a release should be done at the first
reasonable moment.
how do you define lively?
Commit then review. If a developer disagrees to a change by someone
else, this can be discussed and the change can be reverted if
appropriate.
And what is a reasonable moment?
This depends on the perception of the developers. If someone feels
that a release could be done, she/he will ask on the mailing list.
The still lacking 1.4 release is practically
unacceptable, though one reason for the delay is certainly my ambition
to keep on improving it.
it's not just you, it's myself and others as well
But if we close the 1.2 branch when 1.4 is
released,
why should we close 1.2 if there are people willing to fix things?
I'd be afraid that the community could diverge into the 1.2 and 1.4
"devotees" (like Gregor already pointed out). But I can't tell if
this danger is indicated.
many changes should be postponed to 1.6.
what changes?
- JCR integration: JCR-based transactions + versioning
- module dependency resolving (maybe postponed to 1.4.1)
- API improvements to clearly separate storage from content object model
(these come into my mind at the moment, maybe there are more)
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
[EMAIL PROTECTED] [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
