Hi,
Thanks for your answer. I like the idea of loose coupling very much
and the speed issue is important, but like you said, I need to test this
out really.
I still have an issue with how to do the "layout" of my M's, V's &
C's because like I mentioned, my application "Screens" compose Views for
various associated Controllers/Models and the screens are essentially
what the application shows and switches between...
I am thinking that because there are fairly fixed controllers +
models in my application (to start with) these pairs should be somehow
handled by the application. Because of loose-coupling & there being
screens with many views in, I don't think my controllers should be
creating the individual view - there are a number of different views
utilising a single controller so how does the controller know what to
create?
I am thinking about allowing the Application to some how wire in the
controllers to my Screens - the composite of Views - dynamically and
somehow allow this to wire up my event listeners according to what
events the controller(s) respond to. I don't know if this is a bad
thing, so any critique is welcome, but my idea is somehow to implent the
following:
IController::whatEventsDoYouHandle()
ICompositeView::addController(control:IController) {
var desired:Array = control.whatEventsDoYouHandle();
for each(evt in desired) {
addEventListener(evt.type, evt.func...)
}
}
Apart from making sure I remove all listeners, is this a sensible way of
utilising the same controllers & models - for my same devices whilst
just changing the button screens which interact with the devices???
When my system adds another device, I can add appropriate controllers
and models then create my new screen(s) to utilise these as desired??
Any suggestions caveats, etc.
Glen
dr.ache wrote:
Hi Glen.
I would defenitively go with lose coupling and one controller by one
device.
You mentioned one requirement being the scaleability what new views
are concerned - so there is no others choice.
To proof the speed of that setup you need to implement a prototype of
a likely application state. How should someone else know?
But as a general tip: Always go with the better architecture - the
speed comes with better hardware (or flash player).
Glen Pike schrieb:
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
_______________________________________________
Flashcoders mailing list
[email protected]
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
_______________________________________________
Flashcoders mailing list
[email protected]
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
