Jörn Nettingsmeier wrote:
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).
So IIUC the problem is rather the terminology.
How should the "language versions" of a site structure node be called?
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.
IMO the codebase is still quite hard to work with, because it is still
not modularized enough and there are too many dependencies. It is very
risky to make changes because you don't know which parts of the code will
be affected. I'm currently trying to separate the concern areas as good
as possible and isolate functionality, so that unit tests can be
implemented and bugs can be fixed.
another part of the problem might be that lenya advertises many features
that are just not there.
blog is totally non-functional,
Is it buggy or just not useful?
i18n is very tricky,
In what aspect?
access control has holes [users can elevate their own rights],
Could that be a configuration issue? If not, is a bug filed?
search does not work out-of-the-box,
Yes, that's a known problem
> 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.
BXE is sometimes rather tricky, but with some workarounds it is IMO
quite usable.
kupu is totally broken.
No idea (I don't use it)
error messages are hopeless,
OK, that should be quite easy to fix. Which ones do you have in mind?
error recovery for users is non-existent,
What do you mean with "recovery"?
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.
That's really annoying. I applied the patch setting the headers to
avoid caching, but it didn't work for me.
users
cannot change their passwords in an obvious way, not even the admin can.
You can add a "change password" menu item to the menu.
live ac works totally different than authoring ac and it's not documented.
Yes, that should be improved.
that's not to say lenya is stagnant, it's certainly progressing in leaps
and bounds.
At the moment, from my point of view most things happen under the hood,
and some things are breaking (sorry for this, but IMO we have to go
through this). With the separation between the API and the implementation
I'll have a much better feeling for the release re. backwards compatibility.
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
In this case, a clean solution would include changing interfaces and
the sitetree XML structure. I'm a little reluctant if the
comprehensibility improvement is worth this change.
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*,
This is a reason why modules were introduced. The core is the Java code
in /src/java and the sitemaps + XSLTs etc. in /src/webapp.
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)
Yes, I agree that this is annoying. If we were a large community, I'd
instantly agree to release 1.4 asap and postpone major changes like
a new repository API to 1.6. But IMO we don't have enough resources to
maintain another branch.
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.
IMO an important step to avoid this problem is to hide the problematic
code behind an API. The integrator should only be able to base her code
on the published interfaces + classes, which have to be taken special
care of.
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.
What should be done in this case? Should a part of the API only be
deprecated when there's a reasonable alternative? I guess this would
make sense. How do other projects handle that?
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.
Well, IMO it wouldn't be a hack but a valuable improvement. But, like
we already discussed, the terminology would have to be changed to
achieve a comprehensible solution.
rather keep the
core clean and use a branch for the particular project that needs i18n
hrefs,
A branch in the Lenya SVN? I'm not a friend of private branches, unless
they are drafts or temporary sandboxes.
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.
Is there a bug for this issue?
so let me utter the magic words:
feature freeze.
Yes, IMO that makes sense. I have no problem postponing the sitetree
href i18n until 1.4 is released.
fixed release date.
Sure, we could announce a date, but the community has to feel responsible
for abiding it. Otherwise, the development will go on like this.
(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 :-)
Thanks for your input :)
I can see your points - well, most of them :) - and I'd like to
get 1.4 out of the door asap. But some of my major concerns are
backwards compatibility and maintainability, and with the current
codebase I'm afraid it will be hard to achieve these goals.
-- 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]
