incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Janne Jalkanen <Janne.Jalka...@ecyrd.com>
Subject Re: url rewriting supported?
Date Mon, 07 Jul 2008 15:32:47 GMT
>> 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

Mime
View raw message