Janne Jalkanen wrote:
Well, it's not a major change at all and doesn't introduce any bugs. It
is simply the addition of an almost-empty JSP, an addition to CSS to by
default hide it, and one line to Header.jsp.

Adding a new JSP file *is* a major change, as it is a new feature. 2.6.x should be kept stable, and new features should go to the 2.8 branch.

Well, I might note that the discussion last year did happen as we went
to 2.6.0, and it's only my failure (due to time and the holidays) that
this isn't in right now. The patch was submitted but failed because I
packaged it up with some i18n changes that had problems with encoding.
Otherwise this would already be in CVS. I can point to the emails if
this is necessary.

I can do this and have been doing this for the past year. It's a pain,
and I'm absolutely certain that this is a very common use case, perhaps
the most common.

If it is common, there will be more people requesting it. A good idea might be to start a new enhancement request at issues.apache.org.

If you want me to stop asking for features it's a good idea to just put
them in an issues register where they get dealt with sometime in the
distant future. Part of the reason this isn't in CVS right now is that
I already am overbooked for time. Part of the reason I'm overbooked for
time is that I spend too much time on things like updating code and CSS
and related. (and no, we can't run on the older stable releases since
I base an enormous amount of work on current CVS, so I have no choice
but to live on the bleeding edge.)

As for more people asking for it, I don't see anyone asking for much
of anything. We're designing this product as we go along, and the users
who download it aren't generally on this mailing list (to my understanding,
as they generally aren't involved in design discussions at all usually).

E.g., there's a completely customized Zope-Plone implementation here as a
corporate web site and neither the designers nor the customer ever once
contacted anyone in the Zope-Plone design team nor even read any mailing
list messages. What typically happens is that someone downloads a stable
version, they make expensive customisations to it following installation,
and then a year or so later the customer has to hire the contractor back
to make the same set of expensive customisations when they do an upgrade.
Great for contractor, sucks for customer. I open the corporate home page
and look at a really annoying bug that's been there since last August,
right at the top of the page. ugh.

I like the idea of TitleBlock.jsp because it is self-contained. I hand
that off to a web site designer, tell them how many pixels high we want
it and they get free reign within that area. Maintenance is their thing
within that area. Nice division of labour.

If it is a pain, it sounds like our extension mechanism is broken, or you are using it wrong. I would like to go deeper into this before we start panic-slapping patches to see what the root cause really is.

You have characterized this as both a "major change" (which it to any
reasonable observer could hardly be seen that way -- the entire change
makes no default change to the design and is only a few lines of code),
and "panic-slapping", which is hardly fair. This was part of a discussion
from last October and November where you and Dirk had agreed to include
this in the design. There is no root cause to a broken mechanism (which
is not a mechanism, just a page include), this is simply a feature request
that had been (to my understanding) approved and only due to my own
inability to get the patch in is it not there now.

And yes, I can continue to make this custom modification myself as I have
been.

You should *not* have to keep making a custom modification. That's the point of the extension mechanism.

The extension mechanism is there (to my memory) because I suggested it as
part of the TitleBlock.jsp (which at one point did do a transclusion of
a wiki page but I wasn't able to get the formatting and content I needed).
The ability to include a wiki page only permits wiki-style content. Most
corporate headers (as any glance at a typical commercial or corporate web
site) include a lot more brand information.

It's not broken, it's just completely insufficient to do anything typical
of a corporate header. Transcluding the contents of a wiki page really
doesn't do it. So I suppose yes, the "extension mechanism" is broken if
the idea is that it's meant to fulfill the need for a typical title block.

Part of the reason I'd like this in 2.6 is that if it's there I can pass
this entire thing off to other people to maintain for the next x months,
and we're at a point where I'd like to be able to *for once* set up a
production JSPWiki system and be able to leave it for awhile. Otherwise
I've got to continue to patch this locally until we get to 2.8, which is
a long time to continue to patch things given I've already been doing
this for about a year. It is a pain every time I upgrade. I've made
significant modifications to our designs so that I've been able to make
almost *no* other modifications to the default template apart from CSS
ones (though constant changes to the CSS itself has made this a pain too,
but I'll deal with that). This is the *one* remaining sticky area since
we simply must have corporate brand identity at the top of every site
I'm working on.

Murray

...........................................................................
Murray Altheim <murray07 at altheim.com>                           ===  = =
http://www.altheim.com/murray/                                     = =  ===
SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk               = =  = =

      Boundless wind and moon - the eye within eyes,
      Inexhaustible heaven and earth - the light beyond light,
      The willow dark, the flower bright - ten thousand houses,
      Knock at any door - there's one who will respond.
                                      -- The Blue Cliff Record

Reply via email to