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.
( Implementation details…Collapse )