Andreas Hartmann wrote:
Jörn Nettingsmeier wrote:
[EMAIL PROTECTED] wrote:
Thanks a lot!
Do you think it would be difficult to port it to the trunk?
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).
and there are already way too many "make it work"-type kludges in
lenya that are cool for the one guy who needs them and totally wreck
the consistency of the model for everyone else.
Maybe, but in this case I can't see the inconsistency that is caused.
i think this is a java developer disease. i'm all for abstraction and
loose coupling, but not when my brains are concerned :-D
seriously, i have developed some major grudges with lenya. cocoon
(despite being a frightening behemoth) is actually graceful sometimes
(at least from a user's pov). lenya is mostly not, except for parts of
the java code that i hardly ever get to see...
everybody patches their good ideas and pressing needs into it (which is
understandable, since a customer is waiting for them), and the result is
really hard to work with.
credit where credit's due, hats off to you, andreas, for your
refactoring and janitor work. but at this point in time where the lenya
is being gutted and redone it makes life for me even harder.
another part of the problem might be that lenya advertises many features
that are just not there.
blog is totally non-functional, i18n is very tricky, access control has
holes [users can elevate their own rights], search does not work
out-of-the-box, bxe looks cool but is not exactly usable unless you are
so fearless and knowledgeable that you might as well work the xhtml
source code. kupu is totally broken. error messages are hopeless, error
recovery for users is non-existent, browser caching irritates users
since they cannot see the current state of affairs and can click on
stale links that will give them even more cryptic error messages. users
cannot change their passwords in an obvious way, not even the admin can.
live ac works totally different than authoring ac and it's not documented.
that's not to say lenya is stagnant, it's certainly progressing in leaps
and bounds.
but somehow it's one of the most frustating projects i've worked with so
far, because it constantly plays havoc with my expectations, both in
terms of functional completeness while using it and consistency and
elegance while trying to learn and extend the code.
having labels point somewhere just because someone needs a feature
summarizes all this so neatly that i couldn't restrain myself :-D
if people really need i18nized hrefs, then there should be yet another
layer of indirection between the node and the uri. but i think this is
quite a corner case and should not be supported (at least not until
the many glaring usability issues in trunk are fixed).
This is not the way open source development works. You implement
what you need, not what others tell you. And I need i18nized
hrefs in the sitetree.
i know how open source works. the problem with lenya is that it is not
clear what's the *core* and what's *add on*, and 1.4 suffers from the
"cool feature of the day" disease, while at the same time a lot of basic
stuff is still wrong or non-functional.
don't get me wrong, i don't want to be disrespectful, but the fact is
that despite its considerable age 1.4 is still a pile of patchwork with
many open issues, and at least to me it is not clear where the journey
is heading... there is still no release date, and core parts are
constantly being gutted and re-written (which is not bad at all, just
irritating when you've been told a year ago that it would be perfectly
sane to base a project on lenya 1.4 :-D)
we all have read esr's classics, and we all know how cool bazaar-style
development is. the problem of bazaar-style combined with java or oo in
general is that all the ancient layers of cruft are wrapped up and
carried along forever. (in the special case of cocoon, this cruft can
pile up in several different languages and mechanisms.)
and there is the very real danger that core parts stay in the "proof of
concept" stage for way too long and there are not enough people in the
bazaar to do the cleaning-up.
when new people try to learn lenya, they will pick up a lot of
quick-and-dirty, proof-of-concept code. if they, like me, are not at all
veterans in j2ee and avalon in particular, their code contributions will
as a consequence be inelegant and geared towards quick, easy features
and not conceptual elegance and (whoops!) beauty.
people see a crappy api and mark it deprecated. well, that's cool,
except for the fact there is no alternative and it's not even clear how
this alternative should look like.
we need a couple of "best practice" modules that show how things should
be done.
hacking something into the core because you need it (and you happen to
be a core developer) might not be the best approach. rather keep the
core clean and use a branch for the particular project that needs i18n
hrefs, at least until there is a global consistent concept of "i18nized
everything" throughout lenya (i.e. for all assets, for urls and
whatnot). at the moment, i still need to patch the core code to make
i18n work in templated publications, and that seems a rather more
pressing issue for me.
so let me utter the magic words: feature freeze. fixed release date.
there will always be another release for more refacturing and more cool
features.
best,
jörn
(now that my humours are balanced again, let me add a necessary
disclaimer: i profit immensely from your work and the code you all have
donated, and please take my ranting with a grain of salt - no offense
intended. thanks for helping newbies like me out, and thanks for
listening :-)
--
"Open source takes the bullshit out of software."
- Charles Ferguson on TechnologyReview.com
--
Jörn Nettingsmeier, EDV-Administrator
Institut für Politikwissenschaft
Universität Duisburg-Essen, Standort Duisburg
Mail: [EMAIL PROTECTED], Telefon: 0203/379-2736
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
