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.
I briefly mentioned above the “special” field which indicates a special UI. This exists because some of the logprops require special presentation: the picture keywords and mood/moodid require a combobox, and music can have a little detect button attached to it. This does require that a client be taught about special userprops specifically, but after consideration I decided that this wasn't a major issue since most userprops we might want to add from here on are going to be simple boolean options or basic text which can be handled by a char datatype. When a “special” property is returned which a client doesn't know how to deal with, it should simply ignore that property. In some cases, a client might want to use this occurance as a “check for updates” trigger, if the client does that.
The protocol part of this is pretty easy (A lot like the “Web Menu”, but not heirarchical). The Win32 MFC clients (Visions' client and Semagic) currently use prefabricated dialog resources for everything, so dynamically generating a form might be quite a “challenge” for them, but other clients, for example console-based clients, should find this easy and useful.