Janne --
I'm still opposed to the idea because of the context loss involved.
URL rewriting *after* the HTML translation is done means that e.g.
preformatted areas would also get all of their URLs rewritten.
Just wanted to ask you more about what you meant by this. I think what
you were implying is that we would somehow wrap the response, capture
all of its output, and do replacements on the whole response. That is
not what I meant... I was thinking of something simpler.
In the case of URLRewrite, for it to work properly, you just encode
the URLs when you need to. All you need to do is make sure you have a
response object available, for calling response.encodeURL() on a
particular URL. If you don't call encodeURL(), nothing happens to it.
So I don't think preformatted areas would have their URLs re-written,
because while in a preformatted area you would not call
response.encodeURL().
Or did I misinterpret what you meant?
The advantage of encoding the URLs via the response is that it is
would be nice and safe for classes that need to generate URLs. Classes
that generate URLs would only need to generate ones that looked
"normal" (making sure they called encodeURL of course) rather than
hieroglyphic ones. (E.g., a rendering class would generate /Wiki.jsp?
page=Foo rather than %b%p=Foo or whatever it is now.). That's an
easier contract to adhere to than our current scheme.
The other advantage is that it externalizes the URL-generation
mechanism in a way that allows us to plug in creative ways of
rewriting URLs (and un-rewriting them coming in as requests). This is
where URLRewrite comes in -- it could provide everything that
ShortURLConstructor does, but all through rules rather than *code*.
And JSPWiki itself would not have any awareness that the URLs were
anything other than regular URLs.
