ranting... i want a release date :-D

On 5/22/06, Andreas Hartmann <andreasapache.org> wrote:
> Josias Thöny wrote:
> > On Fri, 2006-05-19 at 21:39 +0200, Jörn
Nettingsmeier wrote:
> >> Andreas Hartmann wrote:
> >>> Jörn Nettingsmeier wrote:
> >>>> i don't like this. how can the href
be an attribute of a node *label*?
> >>>> this is so obviously wrong,
> >>> Why do you consider this wrong? IMO it is
quite straightforward.
> >> a label belongs to a node. a node points
somewhere. 100 out of 100
> >> people will grasp this at the first glance.
having a label pointing
> >> somewhere is totally counter-intuitive and
makes the concept of a "node"
> >> redundant (it is reduced to "a group of
labels", and all the brains are
> >> in the labels, which is totally
bass-ackwards).
> >
> > I agree it's not very intuitive that a label has
a href attribute. But
> > the problem, IMHO, is not the href attribute
itself but the name
> > "label". The sitetree needs to have
something like a node for each
> > language version, and it happens to be named
"label", because so far the
> > only information it contained was the label (and
the language).
> > It might make sense to give it a more general name
(like language node
> > or translation).
> +1
>
> But which one to choose?
> I wouldn't give it the same name as the corresponding
content object
> (we agreed upon "Translation") to avoid
confusion.
>
> > But for backwards compatibility reasons, we cannot
> > easily rename this in Lenya 1.2.x.

I am working on a fork of Lenya 1.2 that solves most issues
while
maintaining backwards compatibility.  Hopefully some of the
concepts
could be used in 1.4, but there is developer resistance to
making
Lenya easier to use rather than making it easier to program.
 Most of
my work is designed to remove the need for programming Java.

Sitetree structure:
"The sitetree needs to have something like a node for
each language version"
That is the problem.  Why should the sitetree include more
than one language?

This is mostly an architecture problem.  Lenya 1.2 maintains
separate
sitetrees for each "Area" with the languages
mixed together.  That
could be solved by maintaining separate sitetrees for each
language.
I moved to flat storage without the "Area"
concept.  Indexes are
maintained separately for each language.  The sitetree is
configurably
and dynamically generated from the data.  Resources have a
"title"
attribute in the current language pulled from the desired
version of
the content in that language.  There are no separate nodes
in the
Sitetree for each language because the SitetreeGenerator
returns only
information for the current language.  For backwards
compatibility,
the Navigation Module passes to the new Menu Module if using
flat
storage.  If using 1.2's storage, the Navigation Module
just adds much
flexibility.

For the record, the flat storage implementation uses
"Translation" as
a class and as part of the structure, but it is not part of
the API.
The key is a simple Content class allowing access to
Resources, and
the language is assumed to be the current language.


Codebase complexity:
Needed a new class hierarchy to separate the content API
from the
implementation.  Have implementations for 1.2 hierarchical
data
storage and the new flat storage.   Should be relatively
easy to add
JCR or EJB implementations later.  There are also several
additions
for retrieving variables, such as each Module can be
configured in
publication.xconf.  Hopefully little development will
require
programming Java.  Everything will be documented.

One of the big issues was the PageEnvelope Input Module.  It
assumes
the documentID is at a certain place in the URL, which is
not valid in
my version.  While nothing has been removed, much of its
functionality
is better accessed using new methods.


Modules:
Plug and play.  Drop the directory into either the
publication's or
the global "modules" directory, and it just
works.  No compiling.
Most core functionality is being moved to the Modules to
take
advantage of inheritance with the ability to override any
file at any
level.  publication.xconf overrides any default
configuration.

i18n:
Not certain if this is an issue.  The SitetreeGenerator
solves all
issues with navigation.  Thought about forcing all responses
through
the i18nTransformer, but have not decided yet.  External
links are
maintained as Resources, so the title or href could be
changed without
updating other documents.  May search content during save to
convert
all A tags to Resources.

Blog Module:
Have not touched it yet, but it should be very easy with
flat storage.
Maybe easy enough to start from scratch.  Do I need
backwards-compatibility?  If it does not work now, that
would not be
an issue.

Search:
I wrote the fix for 1.2.  There are some patches on my site
that need
to be added to 1.2.5.  The new version will have it work
out-of-the-box.

Editors (BXE, Kupu):
Just starting to work on the editors.  Currently using
1.2's editor
functions to maintain the documents with a migration routine
for
updating the flat storage.    Making at least one editor
work directly
with flat storage is a priority before releasing.  Will be
adding the
ability to choose any Resource and have the anchor or image
tags
auto-generated and auto-updated.

Errors:
Removed some errors by adding default values.  Others had
the messages
changed to be understandable.  Trying to make everything so
easy that
effort is required to create an error.

Access Control:
Designing new system.  Cannot depend on inheritance with
flat storage.
 It will be built into the core, and apply to all versions
of a
Resource.

Release:
There are several major functions to be completed before
distributing
the code.  It would be nice to create a branch, but since
that seems
unwanted, I will post it on my site.  Upgrading requires a
bunch of
new Java classes, some minor changes to existing classes,
additions to
cocoon.xconf, and changes to global-sitemap.xmap.  The only
publication change is a very minor change to page2xhtml.xsl
because
Lenya 1.2's toDoc.xsl did not produce valid XML, which has
been fixed.
 (It had multiple root nodes.)

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