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...)
