andreas, thanks for your reply. i hope no one took offense...
Andreas Hartmann wrote:
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?
suggestion:
a node is the set of all translated versions of a document or (what we
currently call) an asset.
the root node is the starting point of the site map (and hence, the
navigation tree).
nodes can be related to each other by parent-child relationships (like
we have now), or they can have a "contains" relationship, to denote that
a document contains others. this would help get rid of the "asset"
concept and enable us to treat all kinds of resources uniformly, as
potentially i18nzed (even graphics). "contains" edges in the graph would
be ignored by the menu tree generator.
a node will contain at least one pointer to an actual resource: an xml
file, some other file, or a web hyperlink, or younameit. this pointer is
tagged with a language (missing tag means it applies to all languages)
and a label. if the node is not part of the navigation tree (i.e. it
does not have the root node as an ancestor on the parent-child axis,
i.e. it is an "asset"), the label is optional.
it would be very nice if these "actual resources" could very
transparently offer all that cocoon has to offer, for instance it might
be nice to be able to refer to dynamic content that is not under the
control of lenya in terms of authoring or versioning.
blog is totally non-functional,
Is it buggy or just not useful?
last time i tried (a few days ago), you could not create new entries
(the "no lock" error) or do anything with it at all. are people on this
list seriously interested in it? if so, i'd like to start a new thread
about getting it to work, improving and modularizing it.
the blog is an interesting case for my own project: you have a
potentially huge number of data records, so it is out of the question to
use the lenya document mechanism to handle them one-record-per-file, but
you still want to present a consistent feel to your web editors, even if
the data is stored in one large xml file or an xml or relational
database. i'd like to see the blog thingy split into components:
* the handling of content with expiration dates
* the automated creation of rss/atom feeds
* editing/browsing/maintaining database content in lenya
i18n is very tricky,
In what aspect?
it does not work with publication templating, since the catalogs of the
parent and child publications are not merged correctly. i have submitted
a patch a while ago that works for me.
(http://issues.apache.org/bugzilla/show_bug.cgi?id=38413)
but i think the root of the problem is that publication templating is
either "override" or "inherit" on a per-file basis. what we need is a
clean and well-defined way to *merge* files, and as a later step, to
override on a "per-element" basis.
the xsp catalog page attempts to do merging, but it is subtly wrong atm.
anyways, it's an ad-hoc merging hack and needs to be generalized...
i couldn't come up with something nicer yet (same problem everybody has:
the customer does not pay for a clean architecture...), but it's in the
back of my mind.
access control has holes [users can elevate their own rights],
Could that be a configuration issue? If not, is a bug filed?
it is possible by default. it can be fixed by changing subtree policies
iiuc (some solutions were discussed on the user list lately), but the
default setup needs to be tightened.
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.
it's *really* hard to use except for minor typo corrections.
* there is no way i know of to prevent the deletion of the topmost <h1>
element, and once you deleted it, there's no way to get it back (unless
you know the source).
* sometimes you have the red arrow that allows you to select source code
or element view, sometimes you don't.
* if you want to re-format a line from, say, <p> to an <h2>, and the
drop-down menu is already showing a <h2>, clicking on it will do
nothing. you first have to choose any other format and then go back to
<h2> before anything happens.
* you cannot (or at least i couldn't figure out how) create a list of
"class" attributes that users can select from, to give them a limited
and well-defined way of styling their content (for instance, think of
the classes "left-floating" and "right-floating" to allow for images to
be placed in the text).
it's not totally unusable for me, but i can only use it because i have
intimate knowledge of html and javascript, and i understand its
oddities. my users don't have this background, and they are mystified.
i like how many different editors are currently being integrated
(tinymce is the most promising to me), but at the same time it seems
there's a lot of wasted duplicate effort.
bxe doesn't seem to be the best choice as a default xhtml editor for
lenya anymore. unfortunately, the alternatives are still not fully
integrated into 1.4.
kupu is totally broken.
No idea (I don't use it)
i wouldn't either if bxe worked :-D
error messages are hopeless,
OK, that should be quite easy to fix. Which ones do you have in mind?
everything that users get to see when they try to do something: writing
with no lock acquired, trying to access a page that does not exist,
trying to access a page they have no rights for, trying to access a page
that's checked out, etc....
but the worst issue is this:
error recovery for users is non-existent,
What do you mean with "recovery"?
how does a user get out of an error condition? you get the generic error
message, and unless you know how to edit the url in your browser to
avoid the error and go somewhere useful, there is no way in hell to go
back to work. users will close their browser and log in again, or use
their back button and trigger the same error condition over and over again.
error pages need to offer a link that will take the user back into the
same context s/he came from. they need to be informed whether part of
their editing work just went pooof. if the error handler cannot figure
our where to best take the user after an error (which can be hard
sometimes), it should at least provide a link back to the root node of
the authoring interface.
for a really funny experience, just delete the document that has "index"
as its id. doing so is perfectly valid from a user pov, but there are
assumptions all over the place that an index.xml must exist. if it
doesn't, you are totally and utterly screwed.
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.
i submitted an incorrect patch a while ago, but last week i fixed it
correctly (i hope), and it has worked for me nicely. patch is in
bugzilla: http://issues.apache.org/bugzilla/show_bug.cgi?id=38723
wooops: i just realized a problem: i think i must have marked the bug
"fixed" (which is stupid since the patch has not been committed), but i
shouldn't have been able to do that, right? most other projects i've
worked with don't allow non-committers to change bug status...
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.
i know :) the point is: it should be there already :-D
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.
i don't have a problem with things breaking. i can use an older, known
good checkout while trunk is broken. i have a problem with issues that
are not being addressed. breaking means it's alive :-D
lenya is really cool, its only problem is that it does not live up to
its expectations, since it advertises functionality that is not there or
not stable.
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.
i assume you have a much better insight into the consequences than me,
and i have no doubt that there may be good reasons to go with an interim
solution now. still, it would add to the legacy of unclean interim
solutions that has come to haunt lenya users old and new for a while...
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.
in terms of code layout, you are right. things are much nicer now.
i was thinking more about "core functionality" that should be made
obvious and work out of the box, and add-on funcionality that cannot be
expected to work without some polishing. core problems should get more
development and testing time than add-ons.
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.
i see.
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.
that would be great for learning as well.
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?
yes.
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?
yes. http://issues.apache.org/bugzilla/show_bug.cgi?id=38413. it's not
obvious, i should have edited that bug report better...
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.
i see. the burden of maintaining a new stable branch is really a
problem. but maybe you can take a linux-kernel type approach:
maintenance is a job for third-party vendors, and the trunk moves at its
own pace and is not afraid to break stuff. but then we're back to the
original problem: lenya could use a larger community.
best,
jörn
--
"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]
