Hi everyone,
some of us at Wikidata[1] are currently thinking about the best approach to improve the connection between our backend (web API) and our JavaScript front-end. What we basically want is to make our data model available in the front-end in a broader span. This will allow us to go for more decoupled components (model/viewer) but hopefully it will also allow gadget developers to fetch, handle, present and store data with much less effort.
Since there might be some existing JavaScript frameworks well suited for this already, it might be worth considering them for the job. Backbone, Spine, Knockout, Serenade or Ember are just a few names out of many. Has there been any discussion touching this area so far or is this even used in some wip MediaWiki project? I could for example imagine the Visual Editor requiring some kind of approach going this direction... anything? I think this is similar to the decision to ship MW together with jQuery instead of a similar library. So I guess if we would choose any of these frameworks, it should be a lightweight one, allowing for great flexibility to reuse this in MW extensions and core, not having to introduce another one later which would just mean more confusion for new developers and additional load between clients and servers.
In Wikidata, the first thing we would use any of those frameworks would be to provide Wikidata Items[2] (or other entities) by fetching them via the web-API, allowing modification to those fetched objects and then storing all changes made back to the server via the web-API. Also see my draft[3] with the idea of introducing a JS prototype for Entity/Item as well as FetchedEntity/Item which could probably be implemented using one of those frameworks.
This discussion should be both, talking about experience with such frameworks as well as dealing with the question whether it would make sense to introduce something of this art into core in the near future or not. Any thoughts on this would be highly appreciated!
Cheers, Daniel W.
-- Daniel Werner Software Engineer
Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin Tel. (030) 219 158 26-0
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.
VisualEditor doesn't use a 3rd party framework, mostly because I don't really believe in them - that's another topic though. Here are some thoughts on this topic:
- I suggest you create some classes (JavaScript prototypes) in a namespace, such as a global 'WikiData' object (which can be aliased locally as 'wd'). These classes can be models, views, or whatever, and instantiated with the new keyword. - What you do in that namespace is up to you, but there are some normal practices that should be adhered to in the MediaWiki coding style guidelines on mediawiki.org. - As far as creating re-usable views and models, that's a good idea, but I doubt you need the bloat and limitation of a framework to do it. You should always look at your problem, decide what you need now and might need in the future, and build around that. If a framework happens to be useful then that might be a good way to go, but I would be careful about using one at all. - jQuery should be used for all DOM interaction unless performance is a concern and then direct DOM methods are acceptable. Bringing in another library to modify the DOM is going to be a serious problem. - QUnit should be used for all unit tests.
- Trevor
On Tue, Aug 21, 2012 at 11:36 AM, Daniel Werner daniel.werner@wikimedia.dewrote:
Hi everyone,
some of us at Wikidata[1] are currently thinking about the best approach to improve the connection between our backend (web API) and our JavaScript front-end. What we basically want is to make our data model available in the front-end in a broader span. This will allow us to go for more decoupled components (model/viewer) but hopefully it will also allow gadget developers to fetch, handle, present and store data with much less effort.
Since there might be some existing JavaScript frameworks well suited for this already, it might be worth considering them for the job. Backbone, Spine, Knockout, Serenade or Ember are just a few names out of many. Has there been any discussion touching this area so far or is this even used in some wip MediaWiki project? I could for example imagine the Visual Editor requiring some kind of approach going this direction... anything? I think this is similar to the decision to ship MW together with jQuery instead of a similar library. So I guess if we would choose any of these frameworks, it should be a lightweight one, allowing for great flexibility to reuse this in MW extensions and core, not having to introduce another one later which would just mean more confusion for new developers and additional load between clients and servers.
In Wikidata, the first thing we would use any of those frameworks would be to provide Wikidata Items[2] (or other entities) by fetching them via the web-API, allowing modification to those fetched objects and then storing all changes made back to the server via the web-API. Also see my draft[3] with the idea of introducing a JS prototype for Entity/Item as well as FetchedEntity/Item which could probably be implemented using one of those frameworks.
This discussion should be both, talking about experience with such frameworks as well as dealing with the question whether it would make sense to introduce something of this art into core in the near future or not. Any thoughts on this would be highly appreciated!
Cheers, Daniel W.
-- Daniel Werner Software Engineer
Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin Tel. (030) 219 158 26-0
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
wikitech-l@lists.wikimedia.org