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
<[email protected]>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
> [email protected]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Reply via email to