incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Janne Jalkanen <>
Subject Re: The unspeakable horror of UserPreferences
Date Mon, 25 Feb 2008 06:56:24 GMT
> First, I'd like to see the various user preferences bits become  
> part of a proper Java class, rather than continue to get bigger and  
> bigger as scriptlet code in the JSPs. As happens, the preferences  
> themselves are just String key/value pairs.

Not "just".  In order not to have another unspeakable horror like any  
MBean tool out there, you have to mind the user experience and  
actually design the layout a bit.

But yeah, loads of scriptlets mean that it might be better to move  
them to a PreferencesBean or something.

> It seems to me that the logical thing to do is to make it a Map  
> that is returned (or settable) via something like WikiSession.  
> Thus, in JSPs or other classes, all you'd need to do is grab the  
> WikiSession reference and know that you could also retrieve the  
> user prefs easily. Doing it this way would also eliminate the need  
> to store the preferences in the session directly. This would also  
> mean we could dismantle the Preferences class and package and move  
> its functions into UserManager and SessionMonitor.

Well, Preferences *is* a Map.  Why should we deprecate it in favour  
of another Map?  It's essentially just a Map with a number of  
convenience methods...

I also think that it is good practice to keep preferences a separate  
entity as not to pollute and bloat other classes.

> Second, we should start using JSP expression language more for  
> prefs, and use 'injection' techniques via filters to make things  
> like preferences available as variables. In particular, methods  
> that must execute on "all pages," and only execute once, are  
> candidates for injection. Example: Preferences.setupPreferences is  
> called ONLY ONCE in a JSP that all pages load: commonheader. It  
> would be better to simply use WikiServletFilter to inject the  
> preferences Map as "${wikiPreferences}" or something similar.

Probably true.  On the other hand, commonheader.jsp *is* meant for  
places where common things are set up.  It's really a question of  
whether this is something which should be allowed to be varied from  
one template to another (probably not).  If it's meant to be common  
across all templates, it should be injected.  If it's something that  
we can think of a template writer want to change, then it should be  
in commonheader.jsp.

> Third, a long (long!) time ago, Janne and I discussed adding some  
> capabilities to the UserManager/UserDatabase classes that would  
> allow  persistent storage of preferences. To keep things flexible,  
> I think the best way to store these things is to simply create an  
> additional table (in the JDBC case) that would stash key/value  
> pairs. In the XML case, we could add 'pref' elements as children of  
> each 'user' element. Doing it this way would enable us to store an  
> unlimited number of preferences, for anything we could imagine. I  
> suspect Dirk can imagine quite a lot of things. :)

Ah, but there are some limitations to this - some preferences need to  
be kept browser-specific as well (e.g. my mobile phone browser likes  
slightly different settings).

We can do this in two ways

a) have a separate JCR tree for prefrences (/wiki:prefs/<username>/ 
fontsize, /wiki:prefs/<username>/skin), or
b) have a subnode under the user's own page (which would be  
automatically created), e.g. /wiki:pages/<users page>/wiki:prefs/ 
fontsize, etc

> Lastly, I'd like to understand the JSON side of things a bit more.  
> What are we doing with it?

All in all or just in preferences context?

/Janne (I'll be off to Linz, Austria for the next few days so don't  
expect a speedy response...)

View raw message