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?
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".
Interactive Objects are special objects that have the ability to respond to the user's input in pre-specified manners. They enhance the interaction and communication between the course contents and learners.
JavaScript is a scripting language that enables you to create dynamically updating content, control multimedia, animate images, and pretty much everything else.
JavaScript allows us to modify just about every aspect of the page: content, styling, and its response to user interaction. However, JavaScript can also block DOM construction and delay when the page is rendered.
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.
I would use JSON (as an object registry) and keep it all in your script block. You can then easily store and recover the data without parsing.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With