Hi,
If you use autoCommit="false" in your dataservice (in a normal application
this should be normal since you must to do validations) , I recommend you to
have the following code in your update method;
public function update(someVO:SomeVO):void {
if(service.commitRequired) {
var token:AsyncToken = service.commit();
token.operation = OpConstants.UPDATE;
token.addResponder(responder);
}
}
In this way you could handle updates in a good way.
2007/2/23, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
Yup, that's pretty much the way mine works now, though (before I change
it) it works a bit more optimistically. For every field I have on my form I
have an <mx:Binding /> back to the object so that the form works
bidirectionally. But it's a little too aggressive J
It seems like this approach is almost a little "too good to be true"
though, it seems like it's going to cause problems with the logic later on.
Maybe not, maybe _*I'm*_ just being pessimistic ;)
It still seems a little odd that the U in my CRUD is the only one that's
not handled by Cairngorm. Maybe it's that since all of the explicit
DataService calls are tied up in Cairngorm Commands, I sort of have to trust
that the object is actually, actively Managed, and that it hasn't been
released.
It's funny that the functionality is there and available for me to send an
object back to the server, just not implemented in DataService :P If
DataService were open source, maybe I could extend it to pass the request
along :P
*Jay Proulx*
[EMAIL PROTECTED]
------------------------------
*From:* flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] *On
Behalf Of *billy_d_white
*Sent:* February 23, 2007 4:26 PM
*To:* flexcoders@yahoogroups.com
*Subject:* [flexcoders] Re: FDS and Cairngorm / Individual Item Updates
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 flexcoders@yahoogroups.com <flexcoders%40yahoogroups.com>, <
[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
>
--
::| Carlos Rovira
::| http://www.carlosrovira.com
::| http://www.madeinflex.com
