Like Carlos demonstrated in his example it is there. The form items will update the data model but if the autoCommit is false nothing will be sent to the server. Once there user does decide that he/she wants the data to be updated, then they hit the "Save" button or whatever and it will invoke the SaveCommand and tell the DS to commit() all changes to the server.
Thats the way I do it and my SaveCommand does actually a lot more than that
based on failure or success. Its a bit different, yes, but its better because
so much happens automatically.... so let Flex do its magic :)
Dimitrios Gianninas
Optimal Payments Inc.
-----Original Message-----
From: flexcoders@yahoogroups.com on behalf of Carlos Rovira
Sent: Fri 2/23/2007 5:25 PM
To: flexcoders@yahoogroups.com
Subject: Re: [flexcoders] Re: FDS and Cairngorm / Individual Item Updates
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
--
WARNING
-------
This electronic message and its attachments may contain confidential,
proprietary or legally privileged information, which is solely for the use of
the intended recipient. No privilege or other rights are waived by any
unintended transmission or unauthorized retransmission of this message. If you
are not the intended recipient of this message, or if you have received it in
error, you should immediately stop reading this message and delete it and all
attachments from your system. The reading, distribution, copying or other use
of this message or its attachments by unintended recipients is unauthorized and
may be unlawful. If you have received this e-mail in error, please notify the
sender.
AVIS IMPORTANT
--------------
Ce message électronique et ses pièces jointes peuvent contenir des
renseignements confidentiels, exclusifs ou légalement privilégiés destinés au
seul usage du destinataire visé. L'expéditeur original ne renonce à aucun
privilège ou à aucun autre droit si le présent message a été transmis
involontairement ou s'il est retransmis sans son autorisation. Si vous n'êtes
pas le destinataire visé du présent message ou si vous l'avez reçu par erreur,
veuillez cesser immédiatement de le lire et le supprimer, ainsi que toutes ses
pièces jointes, de votre système. La lecture, la distribution, la copie ou
tout autre usage du présent message ou de ses pièces jointes par des personnes
autres que le destinataire visé ne sont pas autorisés et pourraient être
illégaux. Si vous avez reçu ce courrier électronique par erreur, veuillez en
aviser l'expéditeur.
<<winmail.dat>>
