You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by bu...@apache.org on 2006/03/31 10:18:39 UTC
DO NOT REPLY [Bug 39165] New: - Allow different href attributes for sitetree labels
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=39165>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=39165
Summary: Allow different href attributes for sitetree labels
Product: Lenya
Version: unspecified
Platform: Other
OS/Version: other
Status: NEW
Severity: enhancement
Priority: P2
Component: Navigation Framework
AssignedTo: dev@lenya.apache.org
ReportedBy: andreas@apache.org
At the moment, it is possible to define a href attribute for sitetree nodes. To
support different links for different language versions, it would be nice to
allow href attributes for labels as well:
<tree:node id="world">
<tree:label xml:lang="de" href="http://welt.de">Hallo Welt</tree:label>
<tree:label xml:lang="en" href="http://world.com">Hello World</tree:label>
</tree:node>
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: DO NOT REPLY [Bug 39165] New: - Allow different href attributes
for sitetree labels
Posted by Andreas Hartmann <an...@apache.org>.
Thorsten Scherler wrote:
> El vie, 31-03-2006 a las 09:18 +0100, bugzilla@apache.org escribió:
>> DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
>> RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
>> <http://issues.apache.org/bugzilla/show_bug.cgi?id=39165>.
>> ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
>> INSERTED IN THE BUG DATABASE.
>>
>> http://issues.apache.org/bugzilla/show_bug.cgi?id=39165
>>
>> Summary: Allow different href attributes for sitetree labels
>> Product: Lenya
>> Version: unspecified
>> Platform: Other
>> OS/Version: other
>> Status: NEW
>> Severity: enhancement
>> Priority: P2
>> Component: Navigation Framework
>> AssignedTo: dev@lenya.apache.org
>> ReportedBy: andreas@apache.org
>>
>>
>> At the moment, it is possible to define a href attribute for sitetree nodes. To
>> support different links for different language versions, it would be nice to
>> allow href attributes for labels as well:
>>
>> <tree:node id="world">
>> <tree:label xml:lang="de" href="http://welt.de">Hallo Welt</tree:label>
>> <tree:label xml:lang="en" href="http://world.com">Hello World</tree:label>
>> </tree:node>
>>
>
> Hmm, I have problems with the logic behind this. A "label" is a label of
> the "node". The node has a implicit href location and its children
> (labels) would now override this?
This would only apply to the explicit href location.
We should probably move it from the node to the label.
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: DO NOT REPLY [Bug 39165] New: - Allow different href
attributes for sitetree labels
Posted by Thorsten Scherler <th...@wyona.com>.
El vie, 31-03-2006 a las 09:18 +0100, bugzilla@apache.org escribió:
> DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
> RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
> <http://issues.apache.org/bugzilla/show_bug.cgi?id=39165>.
> ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
> INSERTED IN THE BUG DATABASE.
>
> http://issues.apache.org/bugzilla/show_bug.cgi?id=39165
>
> Summary: Allow different href attributes for sitetree labels
> Product: Lenya
> Version: unspecified
> Platform: Other
> OS/Version: other
> Status: NEW
> Severity: enhancement
> Priority: P2
> Component: Navigation Framework
> AssignedTo: dev@lenya.apache.org
> ReportedBy: andreas@apache.org
>
>
> At the moment, it is possible to define a href attribute for sitetree nodes. To
> support different links for different language versions, it would be nice to
> allow href attributes for labels as well:
>
> <tree:node id="world">
> <tree:label xml:lang="de" href="http://welt.de">Hallo Welt</tree:label>
> <tree:label xml:lang="en" href="http://world.com">Hello World</tree:label>
> </tree:node>
>
Hmm, I have problems with the logic behind this. A "label" is a label of
the "node". The node has a implicit href location and its children
(labels) would now override this?
TIA
salu2
--
Thorsten Scherler
COO Spain
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
thorsten.scherler@wyona.com thorsten@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: ranting... i want a release date :-D
Posted by so...@apache.org.
On 5/22/06, Andreas Hartmann <an...@apache.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-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: ranting... i want a release date :-D
Posted by Andreas Hartmann <an...@apache.org>.
Josias Thöny wrote:
> On Fri, 2006-05-19 at 21:39 +0200, Jörn Nettingsmeier wrote:
>> Andreas Hartmann wrote:
>>> Jörn Nettingsmeier wrote:
>>>> bugzilla@apache.org 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).
>
> 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.
-- Andreas
> But for backwards compatibility reasons, we cannot
> easily rename this in Lenya 1.2.x.
>
> Josias
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: ranting... i want a release date :-D
Posted by Josias Thöny <jo...@wyona.com>.
On Fri, 2006-05-19 at 21:39 +0200, Jörn Nettingsmeier wrote:
> Andreas Hartmann wrote:
> > Jörn Nettingsmeier wrote:
> >> bugzilla@apache.org 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).
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). But for backwards compatibility reasons, we cannot
easily rename this in Lenya 1.2.x.
Josias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: ranting... i want a release date :-D
Posted by Michael Wechner <mi...@wyona.com>.
Jörn Nettingsmeier wrote:
>
> don't get me wrong, i don't want to be disrespectful,
don't worry
> 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...
to me it's very clear:
- generic request2process mapping API (whereas Cocoon could be an
implementation)
- navigation framework
- resource type framework
> 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)
agreed. Well, I am using it in production, but I think the current
changes are
really done very in a very bad way (even if they might be meant as a
good thing or maybe turn out to be good), but no real discussion has
been held and they break a lot of stuff although I don't see any reason
why this is actually necessary, because it could have done way different
>
>
> 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.
I don't fully understand. Can you explain a bit?
Michi
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
+41 44 272 91 61
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: ranting... i want a release date :-D
Posted by Jörn Nettingsmeier <po...@uni-duisburg.de>.
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:
>>>> bugzilla@apache.org 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: pol-admin@uni-due.de, Telefon: 0203/379-2736
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: ranting... i want a release date :-D
Posted by Andreas Hartmann <an...@apache.org>.
Jörn Nettingsmeier wrote:
> Andreas Hartmann wrote:
>> Jörn Nettingsmeier wrote:
>>> bugzilla@apache.org 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
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
ranting... i want a release date :-D
Posted by Jörn Nettingsmeier <po...@uni-duisburg.de>.
Andreas Hartmann wrote:
> Jörn Nettingsmeier wrote:
>> bugzilla@apache.org 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: pol-admin@uni-due.de, Telefon: 0203/379-2736
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: DO NOT REPLY [Bug 39165] - Allow different href attributes for
sitetree labels
Posted by Andreas Hartmann <an...@apache.org>.
Jörn Nettingsmeier wrote:
> bugzilla@apache.org wrote:
>> DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
>> RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
>> <http://issues.apache.org/bugzilla/show_bug.cgi?id=39165>.
>> ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
>> INSERTED IN THE BUG DATABASE.
>>
>> http://issues.apache.org/bugzilla/show_bug.cgi?id=39165
>>
>> ------- Additional Comments From andreas@apache.org 2006-04-11 15:01
>> -------
>> 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.
> 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.
> 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.
> otoh, i would really welcome a way to have site tree nodes point to
> external uris rather than local ones (which this issue seems to imply).
Yes, this would be the first step. There's already a bug report,
it is fixed in the 1.2 branch.
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: DO NOT REPLY [Bug 39165] - Allow different href attributes for
sitetree labels
Posted by Jörn Nettingsmeier <po...@uni-duisburg.de>.
bugzilla@apache.org wrote:
> DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
> RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
> <http://issues.apache.org/bugzilla/show_bug.cgi?id=39165>.
> ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
> INSERTED IN THE BUG DATABASE.
>
> http://issues.apache.org/bugzilla/show_bug.cgi?id=39165
>
>
>
>
>
> ------- Additional Comments From andreas@apache.org 2006-04-11 15:01 -------
> 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, 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.
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).
otoh, i would really welcome a way to have site tree nodes point to
external uris rather than local ones (which this issue seems to imply).
regards,
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: pol-admin@uni-due.de, Telefon: 0203/379-2736
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
DO NOT REPLY [Bug 39165] - Allow different href attributes for sitetree labels
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=39165>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=39165
------- Additional Comments From andreas@apache.org 2006-04-11 15:01 -------
Thanks a lot!
Do you think it would be difficult to port it to the trunk?
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
DO NOT REPLY [Bug 39165] - Allow different href attributes for sitetree labels
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=39165>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=39165
andreas@apache.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|1.4.1 |2.0.1
Version|unspecified |Trunk
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
DO NOT REPLY [Bug 39165] - Allow different href attributes for sitetree labels
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=39165>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=39165
------- Additional Comments From josias.thoeny@wyona.org 2006-04-11 14:01 -------
fixed in Lenya 1.2 in rev 393208
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
DO NOT REPLY [Bug 39165] - Allow different href attributes for sitetree labels
Posted by bu...@apache.org.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=39165>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=39165
andreas@apache.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|1.4 |1.4.1
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org