Hi Jean-Luc and others.
Let's see if we can break it down into simple terms.
- viewHelpers/viewLocator are utility classes that perform related functions
to a view. Instead of cluttering an MXML file with script functions, they are
separated for readability. There is debate which approach to use - some
use neither (an actual utility class). While a viewHelper provides better
association to a single view, a viewLocator allows for the centralization of
common view functions. I'm sure that whichever way works for you,
is acceptable here.
- Model and State are synonymous. If your view changes because of
a change to displayed data - bind the data to the view. If your
view needs to create dependant children - bind it (states or view
stack). Binding can come in different forms. For instatnce, an authorVO
may be bound to several views and/or components. In this case there
would be a one-to-many relationship. While you might have a state
variable in the ModelLocator that is only bound to one view (one-to-one).
- Commands do not receive parameters directly from views, they
receive them from events (CairngormEvent). This allows the command
to be triggered from anywhere in the application. Commands don't know,
or care, how or where, they were called into action. In addition, the
parameters received are usually used for such things as getting
data. For instance, a getAuthors command might have an authorID
parameter that it will pass on to a delegate for a data call. If you have
multiple views that use a command to update their states, you would
go ahead and update the state (ModelLocator) for all of the related views
in the command. The user will only be presented with the state change to
the view that is currently displayed. The other views that are effected, but not
currently displayed, can always be set to a desired state when they are
displayed. By doing it this way, your application won't break if a view is
removed. It will simply update a ModelLocator variable that has become
un-bound. You can see a simple example how to do this here:
http://www.cflex.net/showfiledetails.cfm?ChannelID=1&Object=File&objectID=422.
- Hypothetically, If you have two functions: getAuthors and filterAuthorsGrid, the
first would be a command and the second would be a viewHelper/viewLocator
function. When determining the difference, I think that you need to ask;
does this function need to be used by more than one view and/or does this
function need to be re-usable in the application?
I don't know if this is universal, but we can build upon it.
Tim Hoff
--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com
SPONSORED LINKS
| Web site design development | Computer software development | Software design and development |
| Macromedia flex | Software development best practice |
YAHOO! GROUPS LINKS
- Visit your group "flexcoders" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
