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.
Yes, that's exactly what I was thinking...
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.
Ah, I see.
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 regula
Two problems: regexps are insanely slow. When doing URL rewrites on
something this link-intensive, you want to start caching the HTML.
Which in turn will play havoc with the plugin code generation.
Currently one of the biggest timeusers (if not the biggest) is the
DefaultURLConstructor.
The other problem is that I think some of our template/skin
generation stuff might break if the context is lost...
However, Java5 varargs I think give us a nice exit. How about
WikiContext.generateURL( String content, String param1, String
value1, ... )
with
PARAM_PAGE = "page"
PARAM_VERSION = "version"
and the JSP param could be "Wiki.jsp", or "rss.jsp" or "attach" or
"scripts/jspwiki.js" - direct servlet/JSP/resource names. E.g.
...
wikiContext.generateURL( "Wiki.jsp", PARAM_PAGE, newPage,
PARAM_VERSION, 1, "skin", "raw" );
...
We could then have a SimpleURLConstructor (which just attaches the
params one after the other), a RegexpURLConstructor (which extends
the SimpleURLConstructor and just passes them through a regexp list),
and so on. I like the fact that code can be optimized in these cases
quite a lot, but rules cannot.
I don't think we really need to carry the notion of the request
context that much further, as it's far clearer to point directly to
the JSP or resource instead of an abstract name. Unfortunately it
means that things like the ContentTag will break. But then again,
the stripes-based UI is probably going to break it anyway.
/Janne
