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(a)wikimedia.de>wrote;wrote:
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
http://wikimedia.de
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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l