Hi,
I am reworking an application we use for a touchscreen interface and
am trying to design the architecture for all the right reasons.
I am currently wrangled in MVC-ness and trying to work out the best
way to move forward. Having immersed myself in many books and texts, I
still find myself going around in circles some of the time and would
like to make some choices with possible help from you guys...
The app talks to a back end control system via an XML socket. The
system has a number of devices attached and the screen controls allow
for changing stuff on the devices and monitoring them too along with the
application navigation, etc.
Requirements:
It be easy to add new "screens" later on.
The coupling of component interaction to back end needs to be fairly
fast - we use sliders and trackpads to move devices in real-ish time.
The application may use different languages which affect text and
content.
My "screens" are essentially composite views or possibly composites
of views - one screen may have controls that interact with more than one
device.
I am trying to decide about "arrangment" of my Models Views and
Controllers.
Essentially my components will be grouped into Views, but I do not
know whether it is a good or bad idea to mix controls for different
devices within a single view. Also, is it better to have a single
controller responding to messages from all views to route these to the
appropriate model, or should I create a controller for each view. I am
thinking the latter would be overkill possibly, but I am still not sure
whether to create a composite of controllers, or separate them, use
simple "commands" and some kind of factory / lookup, etc. - some
component events will be routed to devices, some to the application, etc.
At the other side of the controller, my models will be for instances
of devices and will send updates to the backend & other bits of the
app. Is it better here to send these updates directly to all the views
or a controller(s), or is this choice affected by others above?
The other question is, do I lever the existing Flash event mechanism
for communications across the app, or will this slow it down - is it
better to use basic observer for the model updating other things???
I have looked at a number of frameworks and the idea of PureMVC with
it's very loosely coupled elements seems very sensible. As most of the
frameworks are constraining in some way and I need the experience, I am
hedging towards designing my own "framework" here to fit in with the
requirements above - mainly, getting component interaction to the back
end as fast as possible. In the current AS1 functional type code the
button onRelease, etc. functions are pretty much wired directly to
sending of data over the wire. Whilst this is good (fast), the
maintainability of the project is not. Different wiring, change to
spec's, etc. the bits I am trying to clean up along with porting to AS3
/ AVM2.
Does anyone have any advice here particularly with regard as to how
to layout my MVC'ness - can I enclose entire MVC elements within another
M, V or C, or do I nest M-in-M, etc???
Thanks in advance.
Glen
_______________________________________________
Flashcoders mailing list
[email protected]
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
