"Chad" innocentkiller@gmail.com wrote in message news:AANLkTimLNFEWAzemTST4sV2uJexJ-f-UJpf+SRGoOWQZ@mail.gmail.com...
On Thu, Mar 10, 2011 at 1:50 PM, Neil Kandalgaonkar neilk@wikimedia.org wrote:
FYI, there are classes in MediaWiki like HTMLForm and HTMLFormField which abstract a lot of form creation in MediaWiki already. They are not used universally, but very very often.
Actually, HTMLForm isn't used all that much. It's fairly new, and only came around when Andrew redid the preference system not too long ago.
Indeed, it's currently only used in Special:ComparePages, Special:DisableAccount, Special:EmailUser, Special:Preferences and the new Special:Upload. I've been one of the more prolific implementers of it since Andrew drew it up for the preferences rewrite in 1.16; I have it in a mostly-completed cleanout of the Augean stables that is Special:Blockip, and a rather unpolished rewrite of Special:UserLogin which uses it as well.
Those libraries are more useful for the technical details of forms (for instance, preventing cross-site request forgery is built-in) but if you want to standardize usability and style maybe you should start there.
...
+1. I think this is a great idea, and helps enforce UI consistency rather than hoping people Get It Right.
+1 from me to. I'm absolutely of the opinion that HTMLForm abstraction should be used much more widely; and this is one good reason of many. HTMLForm produces a form which has a clear and (most importantly) consistent structure, and also means we can apply style guidelines like these in one fell swoop.
An example of a UI element I thought of recently that could be used in lots of places and add a level of usability would be an auto-suggesting text field for places you type in a username (Email, blocking, dozens of other places).
I've been thinking about that too; it would be completely invaluable. One thing I've been slowly working towards is a JS module for htmlforms, which is now in existence (/resources/mediawiki/mediawiki.htmlform.js). HTMLForm is highly extensible by creating new HTMLFormField subclasses; for the Upload form btongminh created a field for the file-on-your-computer input, with various bells and whistles attached for previewing, client-side validation, etc. A user field could very happily be implemented in exactly the same way, indeed probably should. I fairly recently introduced a field type for "select-dropdown-created-from-a-parsed-system-message-plus-optional-additional-reason-text-field" like we see on the deletion/protection/upload/block forms, in much the same vein.
--HM