Question

I’m creating a web based application (i.e. JavaScript with jQuery and lots of SVG) where the user interacts with “objects” on the screen (think of DIVs that can be draged around, resized and connected by arraows – like a vector drawing programm or a graphical programming language).

As each “object” contains individual information but is allways belonging to a “class” of elements it’s obvious that this application should be programmed by using an OOP approach.

But where do I store the “objects” best?

• Should I create a global structure (“registry”) with all (JS native) objects and tell them “draw yourself on the DOM”?
• Or should I avoid such a structure and think of the (relevant) DOM nodes as my objects and attach the relevant data as .data() to them?

The first approach is very MVC – but I guess the attachment of all the event handlers will be non trivial.

The second approach will handle the events in a trivial way and it doesn’t create a duplicate structure, but I guess the usual OO stuff (like methods) will be more complex.

What do you recomend? I think the answer will be JavaScript and SVG specific as “usual” programming languages don’t have such a highly organized output “canvas”.

Answer 1

In such circumstances in the past (I’ve hit this about 5 times) I always create OOP in JS (global “classes”, non-global data structures as appropriate). Each class typically has a .g property that points to its graphical representation. (And before jQuery’s .data I used expando properties on the DOM instances pointing back to the class instance, when event handlers or the like needed to look the other way.)

I too think of this as MVC, but of course it’s easy to blur the lines (or hard to keep them separate) when you have a single JS interpreter that is storing your models, acting as controller, and also manipulating the view.

I don’t find that adding event handlers is hard under this system: instantiating a new object (in code) is responsible for instantiating its representation in the view, and attaching its own event handlers that trigger instance-based callbacks. This code maps input-specific events (e.g. mousedown) into logical events based on state (e.g. selected). Other code registers to these logical events on the instances.