1. Where does filter and sort functions go? I am leaning toward the view since it doesn't actualy alter the data but changes the way it is displayed, or rather what portion is displayed. But I could see it going in the model.
It can go either place, depending on your needs. If you want all your views to have access to the the same filter then put it in the Proxy. If you only want that filter on a specific view, then put it in the view.
2. Where do i put the processing for getting data from forms (especialy dynamicaly generated forms with unknown number of elements)? It would be nice to have a "code behind" to do this but i don't want to abuse the mediator as one. (on that note, is there a good way to get data from a dynamically generated form... binding a model isn't always practical?)
In this case your view component needs to step up and encapsulate its internal behavior with respect to the dataset its given and how it modifies said data set. This means either binding to or otherwise interrogating a value object or composing one to be passed backward into the system. This simplifies communication with (and dependence on the specific implementation of) the view component, making it loosely coupled to the rest of the system (by using value objects and events as a protocol), thus maximizing the the view component's portability.
3. On a similar note as #2, where do i put more complex visual manipulations like drag and drop operations? Is it wrong to create a code behind like file?
The principle of Encapsulation leads us to build this into the view component. A component should not have to rely on other classes for its own behavior. It would be like carrying your brain around in a jar, not really very useful.
I recently had a Tree that could be dropped to from itself, another tree or a list, all of which packaged their drag data differently. Having taught as a certified Adobe Flex instructor, I can tell you from class after class that drag and drop is one of the toughest aspects of Flex for most students. It is hard enough to understand which components need to have handlers for which events and what they need to do in their handlers for it all to work correctly.
If you lobotomize the components and all and move their brains into separate vats, now you have 6 classes to deal with this scenario, and additionally have the overhead of having three of those classes (the code-behinds) having to listen and respond to their subjects (the view components) so that they can perform the same functions on their behalf. In the battle against complexity there isn't much justification for it.
I just subclass tree or list and add the handlers that are appropriate; it's not really that involved, and the from an encapsulation standpoint, responsibilities aren't misplaced.
4. Should I embed icons in the model or the view? I could see them as data but technically they are visual data.
If you only want the icon in a specific view component and nowhere else, you might put them in the view component. In Flex, since I usually have more than one icon, reuse them in different places, and to bake them into the app rather than load them, I usually do something like this:
package com.me.myapp.common.constants
{
public class MyAppIcons
{
[Embed(source="assets/icons/accept.png")]
public static const ACCEPT:Class;
[Embed(source="assets/icons/add.png")]
public static const ADD:Class;
[Embed(source="assets/icons/arrow_down.png")]
public static const ARROW_DOWN:Class;
[Embed(source="assets/icons/arrow_left.png")]
public static const ARROW_LEFT:Class;
[Embed(source="assets/icons/arrow_up.png")]
public static const ARROW_UP:Class;
...
}
}And then in any view component that needs an icon:
<mx:Image source="{MyAppIcons.DISCONNECTED}" />I am used to the DAO concept and try to keep them to just queries. If i need further data manipulation i create toolkit like classes that help them out. Is there a good design to do this in the Model? Is this a case of using a Proxy to modify the data and use a Delegate like a DAO?
Proxies act as local providers of data, shielding the application from needing to know anything about interacting with services. They may instantiate and call services themselves, and expose some or all of the services methods if it makes sense. Proxies also handle any translation of the received data into a format used by the rest of the system if it differs (such as wrapping an XML response in a 'Smart VO'
[1]).
(thereby placing the knowledge of the service in one actor - the Delegate)
If a service is used by more than one Proxy in your application, you may want to create a Delegate for accessing that service (thereby placing the knowledge of the service in one actor - the Delegate). The Delegate typically instantiates the service exposes the methods of the service as identical Delegate methods, and handles setting the responses to go back to the caller. Have a look at the CafeTownsend Flex demo for an example of the use of Delegates.
7. I don't find myself using commands all that much. When I made up my own MVC architecture in previous projects I did a lot in the Controller. It just seems weird. I feel like I either used to put to much in the Controller or now I don't put enough. Thoughts?
In a previous framework I used, I found myself writing commands for everything. But the responsibilities of the Model were ill-defined as were the View.
In PureMVC, there is more distribution of responsibility into the Model and View tiers. View components are meant to take on a bit of responsibility for encapsulating their behaviors, and they have Mediators that make sure they are fed and cared for. The Model has Proxies (and Delegates if you wish) that encapsulate the domain logic, and interfacing with services.
Also, Mediators decouple the view components from the Model apparatus, and are able to translate simple events to Proxy calls that kick off async service interactions, the results of which can later be consumed via notification by those same or different Mediators, without the need for a middleman Command.
So, what are Commands to do? Well first they're great for coordinating startup. They really make sense when you start using the State Machine. They are a good answer for things like having the same action occur if you click a button in one view component, select a menu item in another or use a keyboard shortcut. And if you want undoability, using the Undo utility will certainly give you ideas about what to do with commands.
A quick peek at the application I'm currently working on (and about to release) shows:
1 Flex app
1 Application Facade
18 Commands
15 Mediators
21 View Components
10 Proxies
1 Event
1 VO
-=Cliff>
[1]See an example of a 'Smart VO' here:
http://forums.puremvc.org/index.php?topic=1293.msg5973#msg5973
