On 5/22/06, Andreas Hartmann <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
