Mike,
If you look at the Cairngorm Store sample that we shipped with
Cairngorm 0.99 recently, you'll see the ModelLocator pattern
that we advocate.
Essentially, the ModelLocator provides you with a single place
in your application where client-side state (the model) is
held, and easily accessed from elsewhere in your application.
You may have one model, the population of which happens over
several MXML files ... that's as it should be. There is really
no need to have a one-to-one correspondence between views
and your database tables; indeed that's very much a user-experience
anti-pattern.
Think of the model as a business object, and of your various
different MXML files as several views or cuts onto the single
business object; each of these views can manipulate/populate/
interrogate the appropriate part of your model, and at an
appropriate point in time, you can submit the model, or a part
of the model, to the server/etc. This divorcing of the model
and the view is critical to *any* guidelines on client-side
architecture.
> Yes, I am familiar with using the "Object" object to collect
> & retain the information, but how do I have a single Object
> grab the data from all the Fields, when the data is spread
> across multiple forms, and the time comes to send it all to
> the server?
You want to understand client-side data models (either using
the mx:Model tag, or just having objects on the ModelLocator)
and learn how to setup bindings between your views and model.
>
> Then send that Object to my Remoting Call when the time comes
> to Send (or Receive) the data from the server.
>
You can then use the model in your RemoteObject calls...
> Thanks for any advice you can provide me!
I think there are several related concepts to grasp here; those
of data-binding and of client-side models being the key ones.
I hope this makes sense; if not, I'm happy to try and
clarify further...
Best,
Steven
--
Steven Webster
Technical Director
iteration::two
This e-mail and any associated attachments transmitted with it may contain
confidential information and must not be copied, or disclosed, or used by
anyone other than the intended recipient(s). If you are not the intended
recipient(s) please destroy this e-mail, and any copies of it, immediately.
Please also note that while software systems have been used to try to ensure
that this e-mail has been swept for viruses, iteration::two do not accept
responsibility for any damage or loss caused in respect of any viruses
transmitted by the e-mail. Please ensure your own checks are carried out
before any attachments are opened.
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/flexcoders/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
