- If you are logged in, it adds a link to the bottom of the list of interests on any user info page.
- If you are looking at your own user info, the link reads "Remove some of these interests", otherwise "Add or remove some of these interests to/from your own".
- When clicked on, this link leads to a new page (actually, a new mode of editinfo.bml, mode=interests) which displays all the interests of this user with a checkbox. The common interests have the checkbox checked already, and are bolded.
- You can select interests to add them to your list, and deselect common interests to remove them from your list.
- This doesn't clutter any page because it only adds a small link to an existing page. Everything else is on a new page.
- This feature was suggested here and seems to be welcome.
- Please test. Feel free to create new accounts.
I've been playing around with the update page a little, reworking the "logprop" UI at the foot of the “full” update page. It occurs to me that, right now, we have a ton of clients each supporting a different number of logprops which have been added over time. Semagic is about the only non-web client release which supports the backdated property, for example.
The first part of my plan was to make the update page produce a form automatically based on the logproplist table. The logproplist table was obviously designed with something like this in mind, as it has captions, descriptions and an ordering field. With a few minor adjustments I got it working as dynamically-generated UI. I added two fields to the logproplist table: “specialui” and “internal”, both bool. specialui indicates that the client must be aware of a special UI requirement for this property, while internal means that clients don't get to know about it at all. The former is used for music, mood and picture keyword and the latter is used for unknown8bit. The “internal” field could be replaced by setting sortorder to some special value, such as zero.
Adding it to the web-based update page was pretty easy. My code just does
SELECT name,datatype,specialui,prettyname FROM logproplist WHERE internal=0 ORDER BY sortorder then iterates over the returned rows. However, it would also be neat to add this to the “login” client protocol mode as an option. Clients which know how to use this can then build a dynamic UI based on the data returned. This has some advantages:
- Clients automatically support new properties when they are added. Also, when editing an entry which contains a userprop the client doesn't know about, the client will have a guide on what kind of UI to present for it based on the datatype of the logprop.
- Some LJ installations could theoretically remove certain userprops or add site-local userprops while still retaining client compatibility. Also, other software could make use of the LJ client protocol to support LJ clients, as my old “weblog” software did, without having to map the LJ ‘standard’ userprops on to unrelated things. (My software, for example, used “current_moodid” for “Section to post in” because the LJ clients can't flexibly change the UI)
- The logprop names can be translated using the translation system pretty easily. My web-based login page is already doing that, although I don't have any data in the language tables so it's falling back on the default text right now. I'm already working on making the client protocol translatable so that non-English clients can get server-supplied data which fits in with their interface language if available.
( Collapse )
- I have spared editinfo.bml and moved everything into interests.bml instead.
- Since /interests.bml?mode=interests is stupid, I called it mode=enmasse instead.
- The link on user info pages still only shows up if you're logged in, but you can nevertheless go to /interests.bml?mode=enmasse and be presented with the same username/password form as on editinfo.bml and use that to change your interests without actually logging in.
- The "Success!" page now links both to your own user info page, and - if different - to the user info page you originally came from (the fromuser= argument).
- You can see the patches here: interests.bml, userinfo.bml, and the translation file.
[UPDATE] ... I forgot to say you're obviously supposed to test this. :>