So if I have a basket with 7 similar boxes, that each have a geen bag with several pouches of different tokens, with a bunch of brown bag attribues, and similar blue and orange bags (I am very color coordinated), each with pouches and such that organize my 50 bazillion square, round, oval, rectangular and flat multi-colored beads into kind of like soldiers in platoons in groups and divisions of battalions, I think want a single a single interface controller that instantiates disposeble display modules, while the data itself remains isolated behind arrayCollections, but what about the business logic? Should I just set a bunch of singletons that I switch the data in and out of, or should I maintain it in 3 or 4 master classes based on general functionality?
Sure can...
I inherited a a project that is cumbersome, error prone, slow and unreliable. The application consists of about 25 different views into a data subset There can be a maximum of 10 complex but identical data units. The way it is written, as each unit comes in, it is broken up and distributed into the view modules which are then assembled into 3 viewstacks. The display is divded into 4 sections, 3 for the stacks plus 1 common interface module stack.
As subsequent units come in, the view stacks are indexed and stacked on top of each other The current set of view stacks is selected by a buttonbar across the top. The system sucks. I have up to 10 pages, each of which has 3 stacks of 8 display pages. Not only are they always full of data that is constantly changing, but the display logic is part of the module. It all gets backed up behind a radidly growing stack of 'callLater()' functions.
My plan is to maintain each unit in a separate instance of an actionscript class, turn the display into mxml only modules and swap the data in and out on demand. The data from the server is already in heirarchial groups, with each child node already packaged into an arraycollection. So my top level node consits of a small group of attributes
My question then becomes: Is there a reason to extract the logic from the individual display modules? Provided I am careul to destroy each one as the data page changes of course. The logic can be somewhat complex in certain cases and there will be processing happening to the display data in the main application (Actionscript class) so I think I might want to leave just the mxml in each module, do nothing but dump a display-ready arrayCollection into the dataprovider and add a few event listeners to handle user interaction
I am fairly new to actionscript, and the 'data - logic - interface - view' leaves me feeling like I am missing something that might be important to know before I paint myself into a corner. Where exactly does the interface fit in? Is there a reason I should not just dump an arraycollection into a data provider? The interface loses me....
I hope that was a little more clear. I have read it through a couple times, but I have the benefit of knowing what it is I am describing.. lol.
data-logic-interface-view sounds like a reasonable architecture. whether it's implemented properly or not in your project, i can't say.
but the data class should hold all the data. it could retrieve the data from a server or the data could be hard-coded into that class.
the interface class should intialize the controls the user sees and process the user input. that input should be communicated to the logic class.
the logic class should contain the logic and be the hub of your project receiving data from the interface and data classes and sending data to the view class.
the view class should present what the user sees.
North America
Europe, Middle East and Africa
Asia Pacific