Wait..i cannot really follow you ;-)
Just a guess: Try to implement a state machine with transitions between
those states.
Your states have IDs and so the transitions do. Whenever you transition
IN a new state you can
setup your controller, show your views and so forth. I expect you to
have some kind of a rule, when
each view in combination with others is shown, right? Or do they popup
individually every time?
Glen Pike schrieb:
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
_______________________________________________
Flashcoders mailing list
[email protected]
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
