On Thu, 2005-12-01 at 19:18 +0100, Erik Moeller wrote:
This is interesting. Based on my own experience, I can tell you that cross-browser compatibility is going to be a PITA.
Oh, I know. ;-) I actually got things working well in IE midway through developing this, which practically involved a rewrite. The IE bits tend to regress because keeping it working involves dealing with my wife's Windows box. That said, I think the scope of bugfixes needed to get things working well are small.
For Wikidata and Ultimate Wiktionary, I'm considering using this library:
Cool, thanks for the pointer. At first, I was really excited, because I thought that it was doing a bunch of really complimentary things like dealing with the extra WHAT-WG datatypes (e.g. <input type="date">), but it looks like he's just started with the repeat part. That said, it looks like a really small amount of code, which is nice.
It's built on top of Mochikit, a fairly powerful JavaScript library.
I'd looked at Mochikit briefly while I was developing this, but was running into performance issues that a library might exacerbate. I was using Behaviour.js at first, and found I got a big performance boost by writing custom code rather than using Behaviour the way that I was. The good thing about using Behaviour was that it made me think about cleaner approaches to attaching events to controls.
That said, I might be able to get some cross-browser and code clarity benefits by using Mochikit, so I may revisit that decision.
When dealing with complex forms on top of a relational database (which is essentially what Wikidata is going to be, plus versioning and other wiki-ness), safe failover is really hard to achieve. Essentially, one has to accept that applications of a certain complexity, especially dealing with data entry, require certain capabilities on the client end.
Yup. Even for something as simple and specific as what I wanted to do (configure an election with an arbitrary number of candidates) I ran into problems with plain ol' HTML forms.
The above forms are one example - where, with JavaScript, you can easily create complex relationships between different elements, without JavaScript, you would have submit the same form 10 or 20 times, use kludges like a fixed number of empty fields, etc. That doesn't even touch upon AJAX stuff like autocompletion, which is hard to do without in some contexts. So when it comes to building Wikidata UIs, I think it makes sense to apply the [[Pareto principle]].
Here's a way I think something like this could work with Wikidata. Right now, JSONwidget is doing all of the heavy lifting on the client, and doing it with two JSON-formatted components:
* The data * The schema describing the data format
My next step for JSONwidget is to add another piece, which is somewhat analogous to a style sheet. Currently with JSONwidget, the relationship between the datatype (e.g. string, int, bool) and the input control is a hard-coded, one-to-one relationship. My thought is to add a way of custom binding of nodes of the tree (even whole subtrees) to new controls. This could be on a per schema node (by identifier/tree location) or per datatype basis.
This same approach could be taken on the back end as well, where nodes in the schema get mapped to fields in the database. A default mapping could map this to a generalized but possibly suboptimal table layout. An administrator could then lock down a particularly popular schema, add a custom table, index the hell out of that table, and convert the existing data into the new database binding.
Anyway, food for thought.
Rob