I think the updates should take care of themselves.  In my app (which
uses Cairngorm, FDS, Java, Hibernate, Spring) I have all my
actionscript domain objects on the flex side declared with the
[Managed] and [RemoteClass] tags.  So if you call the fill method to
populate a collection, you can then take any object from that
collection and update its properties.  Then FDS will figure out
automatically that the object has been updated and make the call to
the server.  In my case with Java, I've got an Assembler and FDS willc
all the updateItem method anytime I edit an object in that collection.

So when I have an form, I create the fields on the form, then populate
them with the value of the object (from the filled collection) that is
 being edited. When the user hits the 'save' button, I copy the values
back into the object that was selected for editing, at which point the
call to the updateItem method on the backend occurs automatically.

:)

--- In [email protected], <[EMAIL PROTECTED]> wrote:
>
> Hey All,
> 
>  
> 
> I'm having an issue finding a best-practice approach for CRUD operations
> with FDS.  Create/Read/Delete are easy, I'm having a problem with
> updates.
> 
>  
> 
> I can easily encapsulate CRD's in my Commands, but there doesn't seem to
> be an option to explicitly commit only a single record with FDS.
> 
>  
> 
> In a non-cairngorm application, this is pretty easy, I can create a
> record, then call ds.createItem(), update it and then ds.commit().  The
> DataService object is local to the interface that is managing the
> record.  No problem, one record committed (correct?).
> 
>  
> 
> However, with Cairngorm:
> 
>  
> 
> 1.    Get a list of records 
> 
>       a.      dispatch ProductEvent.GET_ALL
>       b.      GetAllProductsCommand.execute()
>       c.      ds = new DataService("productHome");
>       d.      ds.fill(model.products);
> 
> 2.    Edit a product
> 
>       a.      myList.dataProvider = model.products
>       b.      dispatch ProductEvent.EDIT, event.product =
> myList.selectedItem
>       c.      interface changes to the product form
>       d.      make modifications via a form
>       e.      dispatch ProductEvent.SAVE, event.product =
> myform.product
>       f.      SaveProductCommand.execute()
>       g.      ds = new DataService("productHome");
>       h.      ......  how do we commit just this one record?
> 
>  
> 
> Even if I still had a reference to the original DataService from the
> fill operation, I may not want to commit all records that changed, only
> the one that I'm interested in.  This would be equivalent to keeping my
> DataService in my ServiceLocator.
> 
>  
> 
> The only other option I can think of is that SaveProductCommand works
> like this, which messes up conflict checks:
> 
>  
> 
> 1.    product = (event as ProductEvent).product;
> 2.    ds = new DataService("productHome");
> 3.    ds.getItem({product_id: product.product_id});
> 4.    locally synchronize the item retrieved from ds.getItem() with
> the product we received in the product event
> 5.    ds.commit()
> 
>  
> 
> When we do this though, we very likely have the most recent copy of the
> object from the database, so we're not sure that something hadn't
> changed before getting it.
> 
>  
> 
> Am I making this too complex?  Is there another way to simply commit one
> particular record?  I can think of all sorts of workarounds, but all of
> them violate the Cairngorm protocols.  I can definitely see the other
> developers on the team bypassing our Command logic making Cairngorm a
> little useless :-)
> 
>  
> 
> Jay Proulx
> 
> Application Developer
> 
> Internet Delivery Services - eVision Team
> 
> [EMAIL PROTECTED]
> 
> (613) 783-6711
>


Reply via email to