Hi Glen.
Normally you can/should combine UI elements logically together. Your ui
elements for the video player, the ones
for the jukebox etc.There is no need for an individual controller for
every button. To emphasize the state machine again you can
enable/disable controllers during state transition. so why do you want
to "wire" things differently in each view?
And yes, stick with events when you build your app, even if you might
know, that there is only on controller for the view.
Glen Pike schrieb:
Hi Dr Ache,
Yes - the state machine idea was something I had for a kind of
"screen manager" class to transition between the "screens" - View1 &
View2 below.
My screens contain 1 or more views depending on how complex the
views are (trying to break stuff down), but to keep the loose coupling
between views and controllers, I was trying to find a way of setting
controllers on a view in a more dynamic way because I was using Events
to communicate between view and controller and wanted to hookup the
appropriate controller for it's corresponding events, e.g.
View1:
(Do I put Button1 & Slider1 in their own view? - not just for 2
components, maybe for many components with the same controller)
Button1 (Plays music on the Jukebox device)
Slider1 (changes volume on the Jukebox)
Button2 (Plays video on the VideoPlayer device)
Slider2 (changes colour on Lighting device #1)
View2:
Sliders 1 - 4 (Lighting devices #1-#4)
Controller & Models:
Jukebox
VideoPlayer
Lighting:Array = [Light #1, ...]
So being as my various buttons are linked up to different "device"
instances, rather than wiring the controller into the individual
buttons directly - my view still needs some control over the
functionality of buttons under different circumstances - I wanted to
wire the controllers up to the view. As the things being controlled,
hence controllers don't change for each screen, just what controls are
"exposed", I wanted to create an API to attach my controllers in a
more abstract way, which is why I thought about interrogating the
controllers for the events they want - then they become more pluggable
like the views...
Hope this helps explain my ideas a bit more..
Thanks
Glen
dr.ache wrote:
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
_______________________________________________
Flashcoders mailing list
[email protected]
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
