Ideas: UserPreferences#

This discussion has been refactored from Ideas. It concerns the expansion of the UserPreferences capabilities of JSPWiki.

December 18,2006#

Since I started keeping some notes on the possibility of using the new JavaPreferences API within my own application (and suggested this might also be valuable for JSPWiki), I thought I'd start a page to keep track of the various specs and articles. -- MurrayAltheim

November 19, 2003: Plugin-driven User Preferences#

A way for a plugin or filter to indicate (via its init method) which properties should show up in the User Preferences. For example, I would like the Stamp Filter to be able to access a preference for the user signature and date format.

Actually, the preferred date format would be useful elsewhere, such as in the Recent Changes page. Hmm, to really be effective, editors would have to write dates with special markup so the translator could be style them at render-time according to the user's date format preference. Or maybe just make ISO 8601 the date format (YYYY-MM-DD) that is always stored if the translator can recognize it and convert to any existing user preference.

-- Daggerbox

March 13, 2003: Additional User Preferences#

In my template (on the ContributedTemplates page) I added to the user preferences page fields to set the width and height of the text area editor (when editing a page, of course). These aren't used in the template yet -- I only put them in as an example, but I think it would be a nice addition to be able to set them. How much trouble do you think that would be? They'd need to be saved in the cookie and the JSP edit page would have to query that information to set the values for the text area. This would certainly help those with larger (or smaller) monitors.


Yup. This was one of the things that was planned. So it should not be a very complex addition.

-- JanneJalkanen

Jan 31, 2003: enforcing user preferences#

(I moved this here from the wiki tips page; probably more relevant. --ebu)

Requiring UserPreferences to be set

I wanted to make sure that before anyone edited a page they were required to set their user preferences (currently their WikiName) first. This would avoid an IP address showing up for the page history information, although the name could be totally inaccurate.

I modified the PageFooter.jsp file to check to see if user preferences are set and to change the link depending on the setting. Here are the modifications:

<wiki:Permission permission="edit">
  <wiki:UserCheck exists="true">
    <wiki:EditLink>Edit this page</wiki:EditLink>
  <wiki:UserCheck exists="false">
    <wiki:LinkTo page="UserPreferences">Set your UserPreferences to edit this page</wiki:LinkTo>

If they want to edit the page, they must first enter their name. This works, but unfortunately, I do not know of a way to have the UserPreferences page submit button then redirect to the edit page. If anyone knows a way to do this, I'd appreciate it. I suspect I'd have to go augment the UserPreferences.jsp and/or PreferencesContent.jsp files to support an extra parameter. Still, it is better than IP addresses. Also, shouldn't the monospace markup disrupt WikiWords just like the code block markup? Or am I just missing the way to escape it?

-- MichaelGentry

OK, I now know you can inhibit a WikiWord with a tilde.

Also, the above code has essentially been incorporated into my template on the ContributedTemplates page.

-- MichaelGentry

Jan 20, 2003: user preferences#

I'm getting to where it would be nice to store user preferences centrally (as well as per workstation). While we need authentication before we can load user information, this might be a good time to provoke some discussion.

Things we need to think of when evolving the user prefs system:

  • cookie-stored prefs, stored on browser workstation, used when browsing on that computer
  • centrally stored prefs, used when a user authenticates himself
  • a way of providing storage of centrally stored prefs (PreferenceProvider?)
  • a way to access those prefs within a customized webapp (presumably through UserProfile)

Ideas? Disputes?


Can we agree up front not to head toward using a database for storing preferences (right away)? Seems like whenever I get involved with any kind of preferences management discussion we always head down that dark path. It gets very complicated because preferences always have some kind of hierarchy, which is complicated to manage in a relational database, IMHO.

Some examples of what kind of prefs you are thinking about would certainly facilitate some discussion. -- KenLiu

Right now, in a hurry, I can only think of a user's personal time zone, and skin choice (if/when offered by a wiki; the basic functionality is there). More to come. --ebu

I personally believe that a TWiki-style approach of storing UserPreferences on the user's own personal page is simply the best way to handle this. I am not even sure if it is worth to build a pluggable architecture for that, since I find it difficult to imagine any situation where it would be necessary.

Databases are a hassle, I agree. They make setup considerably more difficult, and don't offer benefits unless you have something that actually can really apply the relationships between objects.


June 17th, 2002 ebu#

Profile-based change hilights[#1]?#

Since we now have user profiles, should we consider making a profile-specific added text hilighter? I imagine this would involve just storing a profile's last access date and adding a bit to TranslatorReader or WikiEngine to use an alternate paragraph class. The hilight shouldn't be intrusive; just a colored font or tinted background, perhaps.

Opinions? Objections? I'll be able to volunteer - lots of time to code on midsummer's eve.. =)

JanneJalkanen: Um. I'm having a hard time to understand why you'd want to do something like that, but... feel free =). This reminds me - we probably need a better plugin system for user preferences as well.

ebu: Maybe this is related to my reading habits: I hit JSPWiki way too rarely, use the diff a lot, and the have to go back to the actual page and do a search to find the context of the changes. (This could also be a signal for wikipage slice'n'dice time.) Being able to see things changed since you last visited would make catching up easier. (Have others noticed themselves wishing for something like this, or do you have radically different reading habits?)

JanneJalkanen: I actually rely quite a lot on the NotificationList, since it shows daily changes. Doing "changed since last time" -diffs is probably a better way of doing things than highlighting interesting words. We could save the information about last visit to a local database (could be flat file), but then we would need to reliable be able to tell when a person has actually stopped browsing the wiki and when he just took a break and does not want his "last visit" time reset.


Identity Management#

Some times one would like to post delicate issue anonymously or under some pseudonym. So Identity Management comes into play. Authors would like to have more freedom over what is stored as <author> in the version control.

-- Pibach

Category Ideas

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-30) was last changed on 19-Jan-2011 15:15 by Janne Jalkanen