RE: [flexcoders] Cairngorm .99 + VOs + DataBinding

Fri, 03 Jun 2005 03:12:07 -0700

 
Hi Dave,

 
I have a question about best practices and methodologies dealing with the ValueObjects.

 
Let me have a stab at this...
 
 
  1. Should I set the ValueObject by calling it from the onResult handler. Is there a more direct way to set and populate values in both the form AND the VO? Right now, I'm calling the Helper and I somehow think I'm missing something with the VO....
  2. Should I include the MX Databinding (do i have to?) and if so, should I include it in the VO class or as part of the viewHelper class?
  3. Should I set and get individual fields (firstname, lastname, email) or should I use one big function that acts as a setter and getter for a whole form to populate the VO?
  4. Is it better to set the VOs inline (ex: text={delegate.setFirstName (vo.firstname)} or should I call a function that gets and sets the values?  
 
I'm not quite sure I understand your question here, but let's see where we go with this.  In your result handler, onResult,
the result should *already be* a value object.  If your command execute() method is calling a business delegate class,
that business delegate should be returning value object(s).  If your business delegate is calling through to a server, then
on the other side of the wire, your server-side service should be returning value objects.  You do all the Object.registerClass()
magic, and those server-side VOs should be typed by the Remoting gateway and "appear" in your onResult handler as
typed ActionScript value objects.
 
In your onResult method, I'd like to see you do something like:
 
var lineManager : ManagerVO = ManagerVO( event.result );
viewHelper.setManagerForm( lineManager );
 
I'd then like to see your View Helper not accepting loosely typed objects, but strongly typed value objects,
eg:
 
public function setManagerForm( manager : ManagerVO )
{
    view.tiFirstName.text = manager.FIRSTNAME;
 
    // etc
 
}
 
However, you might get away with not using the view helper here at all ... I don't know in what context you
are using this object called manager, but if it's important client-side state, then you might want to consider
keeping it on the ModelLocator, so that in your model locator, you define "lineManager" as an instance of
ManagerVO.
 
Then, in your result handler, rather than call the view helper to populate the form, your onResult method
would update the "lineManager" instance on your ModelLocator, ie replace the call to viewHelper.setManagerForm()
with:
 
ModelLocator.lineManager = ManagerVO( event.result );
 
In this way, you can then just use data-binding to bind your form to the ModelLocator.lineManager attributes,
and if you have multiple views all rendering the same model, you don't have to do any additional work.
 
I'm not sure if I'm answering your question, but perhaps the discussion above will give you some clarity
in your own thoughts ?
 
Does this help ?
 
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

Reply via email to