Re: [flexcoders] FDS, VOs, and ignoring client-side properties
2006/8/23, Seth Hodgson [EMAIL PROTECTED]: Try tagging the properties that you don't want managed in your [Managed] AS class as [Transient]. This should prevent changes to them from being logged/committed. Hahaha. That does exactly what I want! Thanks, Seth!! Incidentally, is that in the docs anywhere? I tried looking for it, but to no avail. Thanks to everyone for helping me track down this issue. Jim -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com 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/
Re: [flexcoders] FDS, VOs, and ignoring client-side properties
Again, thanks for the suggestions. I've tried manually implementing the IManaged interface and using a custom event name (per your suggestions), and I can't seem to get bindings to work on my unmanaged property. I've posted a simple test app at:
http://www.phlod.com/TestBinding/TestBinding.htmland the source code is available at:http://www.phlod.com/TestBinding/srcview/
According to what you're saying, this should work right? Unfortunately as you see, bindings don't work for the checked property. Am I doing something wrong?As I mentioned before, if I manually implement the propertyChange event or allow Flex to generate it, then the code above works as expected. However, in our app, the DataStore then recognizes a change in the Managed ProjectTypeVO object ... which is exactly what we *don't* want.
Also, our corporation has a support contract with Adobe for Flex. Is this an issue we should take up there? Or will they just redirect us back to you? Let me know, and thanks for all your help!Jim
2006/8/22, Jeff Vroom [EMAIL PROTECTED]:
I think the problem is that currently when
you specify [Managed] on a class, we will do code-generation for all properties
of the class, even those properties which explicitly specify the [Bindable(event="someEvent")]
metadata tag on them. (If your class specifies [Bindable], we do skip
code-gen for the property if it has a per-property metadata tag though). There
is a bug opened on this and I think we'll fix it soon. In the meantime,
probably the only option is to take out the [Managed] tag which would require
you to add the managed code yourself to that class. For the properties you
want to FDS to ignore, just do not fire the PropertyChangedEvent.
Jeff
From:
flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com]
On Behalf Of Matt
Chotin
Sent: Monday, August 21, 2006 9:54
PM
To: flexcoders@yahoogroups.com
Subject: RE: [flexcoders] FDS,
VOs, and ignoring client-side properties
Hmm, if you can send us a smaller example we can look but I believe
that the approach that I mentioned should work. If you have bindings that
fire because of events that aren't "propertyChanged" the
managed stuff shouldn't notice.
Matt
From: [EMAIL PROTECTED]
ups.com
[mailto:[EMAIL PROTECTED]ups.com]
On Behalf Of Jim Laing
Sent: Thursday, August 17, 2006
10:15 AM
To: [EMAIL PROTECTED]ups.com
Subject: Re: [flexcoders] FDS,
VOs, and ignoring client-side properties
I tried
doing exactly that (dispatching the custom event in my setter) when using implicit
getters/setters for my unmanagedProp ... but for some reason the bindings
didn't work. However, if I use a propertyChange event (either dispatching it
myself or letting Flex generate it), the bindings seems to work fine. However,
as I said, in this case it still doesn't accomplish what I want ( i.e. having
the DataStore ignore that property). Even if I could make the bindings with
with my custom binding event, I'm not sure it would accomplish what I want.
Jim
2006/8/17, Matt Chotin [EMAIL PROTECTED]
:
If you do [Bindable(event=unmanaged)]
it is your responsibility to dispatch the unmanaged event. If you just do
[Bindable] it will dispatch the propertyChange event which will case management
to notice.
So write a getter/setter with [Bindable(event=unmanagedPropChange)]
and then in the setter dispatch that event.
Matt
From:
flexcoders@yahoogroups.com
[mailto:flexcoders@yahoogroups.com]
On Behalf Of Jim Laing
Sent: Thursday, August 17, 2006
6:57 AM
To: flexcoders@yahoogroups.com
Subject: Re: [flexcoders] FDS, VOs,
and ignoring client-side properties
Thanks
for the idea, Matt. Unfortunately, it doesn't seem to work. I
forgot to mention that my unmanaged property needs to be bindable, and
it seems that enabling binding on this property causes the DataStore
to keep track of the property just like all the managed properties.
Curiously, binding on the unmanaged property only works when I don't
use a custom event name. Simply saying [Bindable] on the unmanaged
property causes the binding to work as it should (but also causes
the unmanaged property to become managed). Saying
[Bindable(event=someEvent)] causes the property to be treated as
unmanaged ... but also causes binding not to work. I also tried using
implicit getters/setters on the unmanaged property with similar
results.
Below is code similar to the code I used. Let me know if I'm doing
something wrong. And thanks for the suggestion!
Jim
package com.wgint.navigator.vo
{
import mx.data.utils.Managed;
import mx.data.IManaged;
import mx.utils.UIDUtil;
import mx.events.PropertyChangeEvent;
import flash.events.EventDispatcher;
import flash.events.IEventDispatcher;
import flash.events.Event;
[RemoteClass(alias=com.wgint.navigator.vo.ProjectTypeVO)]
public class ProjectTypeVO implements IManaged {
[Bindable(event=unmanagedPropChanged)]
public var unmanagedProp:
RE: [flexcoders] FDS, VOs, and ignoring client-side properties
Hi Jim, Try tagging the properties that you don't want managed in your [Managed] AS class as [Transient]. This should prevent changes to them from being logged/committed. Best, Seth From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Jim Laing Sent: Wednesday, August 23, 2006 11:31 AM To: flexcoders@yahoogroups.com Subject: Re: [flexcoders] FDS, VOs, and ignoring client-side properties Again, thanks for the suggestions. I've tried manually implementing the IManaged interface and using a custom event name (per your suggestions), and I can't seem to get bindings to work on my unmanaged property. I've posted a simple test app at: http://www.phlod.com/TestBinding/TestBinding.html and the source code is available at: http://www.phlod.com/TestBinding/srcview/ According to what you're saying, this should work right? Unfortunately as you see, bindings don't work for the checked property. Am I doing something wrong? As I mentioned before, if I manually implement the propertyChange event or allow Flex to generate it, then the code above works as expected. However, in our app, the DataStore then recognizes a change in the Managed ProjectTypeVO object ... which is exactly what we *don't* want. Also, our corporation has a support contract with Adobe for Flex. Is this an issue we should take up there? Or will they just redirect us back to you? Let me know, and thanks for all your help! Jim 2006/8/22, Jeff Vroom [EMAIL PROTECTED]: I think the problem is that currently when you specify [Managed] on a class, we will do code-generation for all properties of the class, even those properties which explicitly specify the [Bindable(event=someEvent)] metadata tag on them. (If your class specifies [Bindable], we do skip code-gen for the property if it has a per-property metadata tag though). There is a bug opened on this and I think we'll fix it soon. In the meantime, probably the only option is to take out the [Managed] tag which would require you to add the managed code yourself to that class. For the properties you want to FDS to ignore, just do not fire the PropertyChangedEvent. Jeff From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Matt Chotin Sent: Monday, August 21, 2006 9:54 PM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] FDS, VOs, and ignoring client-side properties Hmm, if you can send us a smaller example we can look but I believe that the approach that I mentioned should work. If you have bindings that fire because of events that aren't propertyChanged the managed stuff shouldn't notice. Matt From: [EMAIL PROTECTED] ups.com [mailto:[EMAIL PROTECTED] On Behalf Of Jim Laing Sent: Thursday, August 17, 2006 10:15 AM To: flexcoders@yahoogroups.com Subject: Re: [flexcoders] FDS, VOs, and ignoring client-side properties I tried doing exactly that (dispatching the custom event in my setter) when using implicit getters/setters for my unmanagedProp ... but for some reason the bindings didn't work. However, if I use a propertyChange event (either dispatching it myself or letting Flex generate it), the bindings seems to work fine. However, as I said, in this case it still doesn't accomplish what I want ( i.e. having the DataStore ignore that property). Even if I could make the bindings with with my custom binding event, I'm not sure it would accomplish what I want. Jim 2006/8/17, Matt Chotin [EMAIL PROTECTED] : If you do [Bindable(event=unmanaged)] it is your responsibility to dispatch the unmanaged event. If you just do [Bindable] it will dispatch the propertyChange event which will case management to notice. So write a getter/setter with [Bindable(event=unmanagedPropChange)] and then in the setter dispatch that event. Matt From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Jim Laing Sent: Thursday, August 17, 2006 6:57 AM To: flexcoders@yahoogroups.com Subject: Re: [flexcoders] FDS, VOs, and ignoring client-side properties Thanks for the idea, Matt. Unfortunately, it doesn't seem to work. I forgot to mention that my unmanaged property needs to be bindable, and it seems that enabling binding on this property causes the DataStore to keep track of the property just like all the managed properties. Curiously, binding on the unmanaged property only works when I don't use a custom event name. Simply saying [Bindable] on the unmanaged property causes the binding to work as it should (but also causes the unmanaged property to become managed). Saying [Bindable(event=someEvent)] causes the property to be treated as unmanaged ... but also causes binding not to work. I also tried using implicit getters/setters on the unmanaged property with similar results. Below is code similar to the code I used. Let me know if I'm doing
RE: [flexcoders] FDS, VOs, and ignoring client-side properties
I think the problem is that currently when
you specify [Managed] on a class, we will do code-generation for all properties
of the class, even those properties which explicitly specify the [Bindable(event=someEvent)]
metadata tag on them. (If your class specifies [Bindable], we do skip
code-gen for the property if it has a per-property metadata tag though). There
is a bug opened on this and I think well fix it soon. In the meantime,
probably the only option is to take out the [Managed] tag which would require
you to add the managed code yourself to that class. For the properties you
want to FDS to ignore, just do not fire the PropertyChangedEvent.
Jeff
From: flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] On Behalf Of Matt
Chotin
Sent: Monday, August 21, 2006 9:54
PM
To: flexcoders@yahoogroups.com
Subject: RE: [flexcoders] FDS,
VOs, and ignoring client-side properties
Hmm, if you can send us a smaller example we can look but I believe
that the approach that I mentioned should work. If you have bindings that
fire because of events that arent propertyChanged the
managed stuff shouldnt notice.
Matt
From: [EMAIL PROTECTED]ups.com
[mailto:[EMAIL PROTECTED]ups.com]
On Behalf Of Jim Laing
Sent: Thursday, August 17, 2006
10:15 AM
To: [EMAIL PROTECTED]ups.com
Subject: Re: [flexcoders] FDS,
VOs, and ignoring client-side properties
I tried
doing exactly that (dispatching the custom event in my setter) when using implicit
getters/setters for my unmanagedProp ... but for some reason the bindings
didn't work. However, if I use a propertyChange event (either dispatching it
myself or letting Flex generate it), the bindings seems to work fine. However,
as I said, in this case it still doesn't accomplish what I want ( i.e. having
the DataStore ignore that property). Even if I could make the bindings with
with my custom binding event, I'm not sure it would accomplish what I want.
Jim
2006/8/17, Matt Chotin [EMAIL PROTECTED]com:
If you do [Bindable(event=unmanaged)]
it is your responsibility to dispatch the unmanaged event. If you just do
[Bindable] it will dispatch the propertyChange event which will case management
to notice.
So write a getter/setter with [Bindable(event=unmanagedPropChange)]
and then in the setter dispatch that event.
Matt
From: [EMAIL PROTECTED]ups.com
[mailto:[EMAIL PROTECTED]ups.com]
On Behalf Of Jim Laing
Sent: Thursday, August 17, 2006
6:57 AM
To: [EMAIL PROTECTED]ups.com
Subject: Re: [flexcoders] FDS, VOs,
and ignoring client-side properties
Thanks
for the idea, Matt. Unfortunately, it doesn't seem to work. I
forgot to mention that my unmanaged property needs to be bindable, and
it seems that enabling binding on this property causes the DataStore
to keep track of the property just like all the managed properties.
Curiously, binding on the unmanaged property only works when I don't
use a custom event name. Simply saying [Bindable] on the unmanaged
property causes the binding to work as it should (but also causes
the unmanaged property to become managed). Saying
[Bindable(event=someEvent)] causes the property to be treated as
unmanaged ... but also causes binding not to work. I also tried using
implicit getters/setters on the unmanaged property with similar
results.
Below is code similar to the code I used. Let me know if I'm doing
something wrong. And thanks for the suggestion!
Jim
package com.wgint.navigator.vo
{
import mx.data.utils.Managed;
import mx.data.IManaged;
import mx.utils.UIDUtil;
import mx.events.PropertyChangeEvent;
import flash.events.EventDispatcher;
import flash.events.IEventDispatcher;
import flash.events.Event;
[RemoteClass(alias=com.wgint.navigator.vo.ProjectTypeVO)]
public class ProjectTypeVO implements IManaged {
[Bindable(event=unmanagedPropChanged)]
public var unmanagedProp: Boolean;
private var _managedProp: int;
private var _uid:String;
private var _eventDispatcher:EventDispatcher = new
EventDispatcher(IEventDispatcher(this));
// getters and setters for managed properties
[Bindable(event=propertyChange)]
public function get managedProp():int {
_managedProp = Managed.getProperty(this, managedProp,
_managedProp);
return _managedProp;
}
public function set managedProp(value:int):void {
var oldValue:int = _managedProp;
_managedProp = value;
Managed.setProperty(this, managedProp, oldValue, _managedProp);
}
// IManaged implementation
[Bindable(event=propertyChange)]
public function get uid():String {
if (_uid == null) {
_uid = UIDUtil.createUID();
}
return _uid;
}
public function set uid(value:String):void {
var oldValue:String = _uid;
if (oldValue !== value) {
_uid = value;
var e:PropertyChangeEvent =
PropertyChangeEvent.createUpdateEvent(this, uid,
oldValue, value)
dispatchEvent(e);
}
}
// IEventDispatcher implementation
public function addEventListener(type:String,
listener:Function, useCapture:Boolean = false, priority:int = 0,
weakRef:Boolean
RE: [flexcoders] FDS, VOs, and ignoring client-side properties
Hmm, if you can send us a smaller example
we can look but I believe that the approach that I mentioned should work. If
you have bindings that fire because of events that arent propertyChanged
the managed stuff shouldnt notice.
Matt
From: flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] On Behalf Of Jim Laing
Sent: Thursday, August 17, 2006
10:15 AM
To: flexcoders@yahoogroups.com
Subject: Re: [flexcoders] FDS,
VOs, and ignoring client-side properties
I tried doing exactly that (dispatching the custom
event in my setter) when using implicit getters/setters for my unmanagedProp
... but for some reason the bindings didn't work. However, if I use a
propertyChange event (either dispatching it myself or letting Flex generate
it), the bindings seems to work fine. However, as I said, in this case it still
doesn't accomplish what I want ( i.e. having the DataStore ignore that
property). Even if I could make the bindings with with my custom binding event,
I'm not sure it would accomplish what I want.
Jim
2006/8/17, Matt Chotin [EMAIL PROTECTED]com:
If you do [Bindable(event=unmanaged)]
it is your responsibility to dispatch the unmanaged event. If you just do
[Bindable] it will dispatch the propertyChange event which will case management
to notice.
So write a getter/setter with [Bindable(event=unmanagedPropChange)]
and then in the setter dispatch that event.
Matt
From: [EMAIL PROTECTED]ups.com
[mailto:[EMAIL PROTECTED]ups.com]
On Behalf Of Jim Laing
Sent: Thursday, August 17, 2006
6:57 AM
To: [EMAIL PROTECTED]ups.com
Subject: Re: [flexcoders] FDS,
VOs, and ignoring client-side properties
Thanks
for the idea, Matt. Unfortunately, it doesn't seem to work. I
forgot to mention that my unmanaged property needs to be bindable, and
it seems that enabling binding on this property causes the DataStore
to keep track of the property just like all the managed properties.
Curiously, binding on the unmanaged property only works when I don't
use a custom event name. Simply saying [Bindable] on the unmanaged
property causes the binding to work as it should (but also causes
the unmanaged property to become managed). Saying
[Bindable(event=someEvent)] causes the property to be treated as
unmanaged ... but also causes binding not to work. I also tried using
implicit getters/setters on the unmanaged property with similar
results.
Below is code similar to the code I used. Let me know if I'm doing
something wrong. And thanks for the suggestion!
Jim
package com.wgint.navigator.vo
{
import mx.data.utils.Managed;
import mx.data.IManaged;
import mx.utils.UIDUtil;
import mx.events.PropertyChangeEvent;
import flash.events.EventDispatcher;
import flash.events.IEventDispatcher;
import flash.events.Event;
[RemoteClass(alias=com.wgint.navigator.vo.ProjectTypeVO)]
public class ProjectTypeVO implements IManaged {
[Bindable(event=unmanagedPropChanged)]
public var unmanagedProp: Boolean;
private var _managedProp: int;
private var _uid:String;
private var _eventDispatcher:EventDispatcher = new
EventDispatcher(IEventDispatcher(this));
// getters and setters for managed properties
[Bindable(event=propertyChange)]
public function get managedProp():int {
_managedProp = Managed.getProperty(this, managedProp,
_managedProp);
return _managedProp;
}
public function set managedProp(value:int):void {
var oldValue:int = _managedProp;
_managedProp = value;
Managed.setProperty(this, managedProp, oldValue, _managedProp);
}
// IManaged implementation
[Bindable(event=propertyChange)]
public function get uid():String {
if (_uid == null) {
_uid = UIDUtil.createUID();
}
return _uid;
}
public function set uid(value:String):void {
var oldValue:String = _uid;
if (oldValue !== value) {
_uid = value;
var e:PropertyChangeEvent =
PropertyChangeEvent.createUpdateEvent(this, uid,
oldValue, value)
dispatchEvent(e);
}
}
// IEventDispatcher implementation
public function addEventListener(type:String,
listener:Function, useCapture:Boolean = false, priority:int = 0,
weakRef:Boolean = false):void {
_eventDispatcher.addEventListener(type, listener,
useCapture, priority, weakRef);
}
public function dispatchEvent(event:flash.events.Event):Boolean
{
return _eventDispatcher.dispatchEvent(event);
}
public function hasEventListener(type:String):Boolean {
return _eventDispatcher.hasEventListener(type);
}
public function removeEventListener(type:String,
listener:Function, useCapture:Boolean = false):void {
_eventDispatcher.removeEventListener(type, listener, useCapture);
}
public function willTrigger(type:String):Boolean {
return _eventDispatcher.willTrigger(type);
}
}
}
2006/8/16, Matt Chotin [EMAIL PROTECTED]com:
Hmm, you might need to implement mx.data.IManaged yourself instead of
relying on IManaged. IManaged extends IUID (you must have a string property uid)
and IEventDispatcher (must be an event dispatcher). You will then need to
implement any managed property as follows (I
Re: [flexcoders] FDS, VOs, and ignoring client-side properties
Thanks for the idea, Matt. Unfortunately, it doesn't seem to work. I
forgot to mention that my unmanaged property needs to be bindable, and
it seems that enabling binding on this property causes the DataStore
to keep track of the property just like all the managed properties.
Curiously, binding on the unmanaged property only works when I don't
use a custom event name. Simply saying [Bindable] on the unmanaged
property causes the binding to work as it should (but also causes
the unmanaged property to become managed). Saying
[Bindable(event=someEvent)] causes the property to be treated as
unmanaged ... but also causes binding not to work. I also tried using
implicit getters/setters on the unmanaged property with similar
results.
Below is code similar to the code I used. Let me know if I'm doing
something wrong. And thanks for the suggestion!
Jim
package com.wgint.navigator.vo
{
import mx.data.utils.Managed;
import mx.data.IManaged;
import mx.utils.UIDUtil;
import mx.events.PropertyChangeEvent;
import flash.events.EventDispatcher;
import flash.events.IEventDispatcher;
import flash.events.Event;
[RemoteClass(alias=com.wgint.navigator.vo.ProjectTypeVO)]
public class ProjectTypeVO implements IManaged {
[Bindable(event=unmanagedPropChanged)]
public var unmanagedProp: Boolean;
private var _managedProp: int;
private var _uid:String;
private var _eventDispatcher:EventDispatcher = new
EventDispatcher(IEventDispatcher(this));
// getters and setters for managed properties
[Bindable(event=propertyChange)]
public function get managedProp():int {
_managedProp = Managed.getProperty(this, managedProp,
_managedProp);
return _managedProp;
}
public function set managedProp(value:int):void {
var oldValue:int = _managedProp;
_managedProp = value;
Managed.setProperty(this, managedProp, oldValue, _managedProp);
}
//IManaged implementation
[Bindable(event=propertyChange)]
public function get uid():String {
if (_uid == null) {
_uid = UIDUtil.createUID();
}
return _uid;
}
public function set uid(value:String):void {
var oldValue:String = _uid;
if (oldValue !== value) {
_uid = value;
var e:PropertyChangeEvent =
PropertyChangeEvent.createUpdateEvent(this, uid, oldValue, value)
dispatchEvent(e);
}
}
//IEventDispatcher implementation
public function addEventListener(type:String,
listener:Function, useCapture:Boolean = false, priority:int = 0,
weakRef:Boolean = false):void {
_eventDispatcher.addEventListener(type, listener,
useCapture, priority, weakRef);
}
public function dispatchEvent(event:flash.events.Event):Boolean {
return _eventDispatcher.dispatchEvent(event);
}
public function hasEventListener(type:String):Boolean {
return _eventDispatcher.hasEventListener(type);
}
public function removeEventListener(type:String,
listener:Function, useCapture:Boolean = false):void {
_eventDispatcher.removeEventListener(type, listener, useCapture);
}
public function willTrigger(type:String):Boolean {
return _eventDispatcher.willTrigger(type);
}
}
}
2006/8/16, Matt Chotin [EMAIL PROTECTED]:
Hmm, you might need to implement mx.data.IManaged yourself instead of relying
on IManaged. IManaged extends IUID (you must have a string property uid) and
IEventDispatcher (must be an event dispatcher). You will then need to
implement any managed property as follows (I haven't tested this, it's based
on reading the generated actionscript for a [Managed] class):
import mx.data.utils.Managed;
private var _test1:int;
[Bindable(event=propertyChange)]
public function get test1():int
{
_test1 = mx.data.utils.Managed.getProperty(this, test1, _test1);
return _test1;
}
public function set test1(value:int):void
{
var oldValue:int = this._ test1;
_test1 = value;
mx.data.utils.Managed.setProperty(this, test1, oldValue,
_test1);
}
I have no guarantees, but see how it goes?
Matt
From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Jim
Laing
Sent: Wednesday, August 16, 2006 8:27 AM
To: flexcoders@yahoogroups.com
Subject: [flexcoders] FDS, VOs, and ignoring client-side properties
We're using FDS on our project, and we're using a single DataStore
with autoCommit=false on all of our DataServices. This way, we're able
to have a single, application-wide save button to commit all the
latest changes. This save
RE: [flexcoders] FDS, VOs, and ignoring client-side properties
If you do [Bindable(event=unmanaged)]
it is your responsibility to dispatch the unmanaged event. If you just do
[Bindable] it will dispatch the propertyChange event which will case management
to notice.
So write a getter/setter with
[Bindable(event=unmanagedPropChange)] and then in the setter
dispatch that event.
Matt
From: flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] On Behalf Of Jim Laing
Sent: Thursday, August 17, 2006
6:57 AM
To: flexcoders@yahoogroups.com
Subject: Re: [flexcoders] FDS,
VOs, and ignoring client-side properties
Thanks
for the idea, Matt. Unfortunately, it doesn't seem to work. I
forgot to mention that my unmanaged property needs to be bindable, and
it seems that enabling binding on this property causes the DataStore
to keep track of the property just like all the managed properties.
Curiously, binding on the unmanaged property only works when I don't
use a custom event name. Simply saying [Bindable] on the unmanaged
property causes the binding to work as it should (but also causes
the unmanaged property to become managed). Saying
[Bindable(event=someEvent)] causes the property to be
treated as
unmanaged ... but also causes binding not to work. I also tried using
implicit getters/setters on the unmanaged property with similar
results.
Below is code similar to the code I used. Let me know if I'm doing
something wrong. And thanks for the suggestion!
Jim
package com.wgint.navigator.vo
{
import mx.data.utils.Managed;
import mx.data.IManaged;
import mx.utils.UIDUtil;
import mx.events.PropertyChangeEvent;
import flash.events.EventDispatcher;
import flash.events.IEventDispatcher;
import flash.events.Event;
[RemoteClass(alias=com.wgint.navigator.vo.ProjectTypeVO)]
public class ProjectTypeVO implements IManaged {
[Bindable(event=unmanagedPropChanged)]
public var unmanagedProp: Boolean;
private var _managedProp: int;
private var _uid:String;
private var _eventDispatcher:EventDispatcher = new
EventDispatcher(IEventDispatcher(this));
// getters and setters for managed properties
[Bindable(event=propertyChange)]
public function get managedProp():int {
_managedProp = Managed.getProperty(this, managedProp,
_managedProp);
return _managedProp;
}
public function set managedProp(value:int):void {
var oldValue:int = _managedProp;
_managedProp = value;
Managed.setProperty(this, managedProp, oldValue,
_managedProp);
}
// IManaged implementation
[Bindable(event=propertyChange)]
public function get uid():String {
if (_uid == null) {
_uid = UIDUtil.createUID();
}
return _uid;
}
public function set uid(value:String):void {
var oldValue:String = _uid;
if (oldValue !== value) {
_uid = value;
var e:PropertyChangeEvent =
PropertyChangeEvent.createUpdateEvent(this, uid,
oldValue, value)
dispatchEvent(e);
}
}
// IEventDispatcher implementation
public function addEventListener(type:String,
listener:Function, useCapture:Boolean = false, priority:int = 0,
weakRef:Boolean = false):void {
_eventDispatcher.addEventListener(type, listener,
useCapture, priority, weakRef);
}
public function dispatchEvent(event:flash.events.Event):Boolean
{
return _eventDispatcher.dispatchEvent(event);
}
public function hasEventListener(type:String):Boolean {
return _eventDispatcher.hasEventListener(type);
}
public function removeEventListener(type:String,
listener:Function, useCapture:Boolean = false):void {
_eventDispatcher.removeEventListener(type, listener, useCapture);
}
public function willTrigger(type:String):Boolean {
return _eventDispatcher.willTrigger(type);
}
}
}
2006/8/16, Matt Chotin [EMAIL PROTECTED]com:
Hmm, you might need to implement mx.data.IManaged yourself instead of
relying on IManaged. IManaged extends IUID (you must have a string property
uid) and IEventDispatcher (must be an event dispatcher). You will then need to
implement any managed property as follows (I haven't tested this, it's based on
reading the generated actionscript for a [Managed] class):
import mx.data.utils.Managed;
private var _test1:int;
[Bindable(event=propertyChange)]
public function get test1():int
{
_test1 = mx.data.utils.Managed.getProperty(this,
test1, _test1);
return _test1;
}
public function set test1(value:int):void
{
var oldValue:int = this._ test1;
_test1 = value;
mx.data.utils.Managed.setProperty(this, test1,
oldValue, _test1);
}
I have no guarantees, but see how it goes?
Matt
From: [EMAIL PROTECTED]ups.com
[mailto:[EMAIL PROTECTED]ups.com]
On Behalf Of Jim Laing
Sent: Wednesday, August 16, 2006 8:27 AM
To: [EMAIL PROTECTED]ups.com
Subject: [flexcoders] FDS, VOs, and ignoring client-side properties
We're using FDS on our project, and we're using a single DataStore
with autoCommit=false on all of our DataServices. This way, we're able
to have a single, application-wide save button to commit all the
latest changes. This save button is enabled based upon
Re: [flexcoders] FDS, VOs, and ignoring client-side properties
I tried doing exactly that (dispatching the custom event in my setter) when using implicit getters/setters for my unmanagedProp ... but for some reason the bindings didn't work. However, if I use a propertyChange event (either dispatching it myself or letting Flex generate it), the bindings seems to work fine. However, as I said, in this case it still doesn't accomplish what I want (
i.e. having the DataStore ignore that property). Even if I could make the bindings with with my custom binding event, I'm not sure it would accomplish what I want.Jim2006/8/17, Matt Chotin
[EMAIL PROTECTED]:
If you do [Bindable(event="unmanaged")]
it is your responsibility to dispatch the unmanaged event. If you just do
[Bindable] it will dispatch the propertyChange event which will case management
to notice.
So write a getter/setter with
[Bindable(event="unmanagedPropChange")] and then in the setter
dispatch that event.
Matt
From:
flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com]
On Behalf Of Jim Laing
Sent: Thursday, August 17, 2006
6:57 AM
To: flexcoders@yahoogroups.com
Subject: Re: [flexcoders] FDS,
VOs, and ignoring client-side properties
Thanks
for the idea, Matt. Unfortunately, it doesn't seem to work. I
forgot to mention that my unmanaged property needs to be bindable, and
it seems that enabling binding on this property causes the DataStore
to keep track of the property just like all the managed properties.
Curiously, binding on the unmanaged property only works when I don't
use a custom event name. Simply saying [Bindable] on the unmanaged
property causes the binding to work as it should (but also causes
the unmanaged property to become managed). Saying
[Bindable(event=someEvent)] causes the property to be
treated as
unmanaged ... but also causes binding not to work. I also tried using
implicit getters/setters on the unmanaged property with similar
results.
Below is code similar to the code I used. Let me know if I'm doing
something wrong. And thanks for the suggestion!
Jim
package com.wgint.navigator.vo
{
import mx.data.utils.Managed;
import mx.data.IManaged;
import mx.utils.UIDUtil;
import mx.events.PropertyChangeEvent;
import flash.events.EventDispatcher;
import flash.events.IEventDispatcher;
import flash.events.Event;
[RemoteClass(alias=com.wgint.navigator.vo.ProjectTypeVO)]
public class ProjectTypeVO implements IManaged {
[Bindable(event=unmanagedPropChanged)]
public var unmanagedProp: Boolean;
private var _managedProp: int;
private var _uid:String;
private var _eventDispatcher:EventDispatcher = new
EventDispatcher(IEventDispatcher(this));
// getters and setters for managed properties
[Bindable(event=propertyChange)]
public function get managedProp():int {
_managedProp = Managed.getProperty(this, managedProp,
_managedProp);
return _managedProp;
}
public function set managedProp(value:int):void {
var oldValue:int = _managedProp;
_managedProp = value;
Managed.setProperty(this, managedProp, oldValue,
_managedProp);
}
// IManaged implementation
[Bindable(event=propertyChange)]
public function get uid():String {
if (_uid == null) {
_uid = UIDUtil.createUID();
}
return _uid;
}
public function set uid(value:String):void {
var oldValue:String = _uid;
if (oldValue !== value) {
_uid = value;
var e:PropertyChangeEvent =
PropertyChangeEvent.createUpdateEvent(this, uid,
oldValue, value)
dispatchEvent(e);
}
}
// IEventDispatcher implementation
public function addEventListener(type:String,
listener:Function, useCapture:Boolean = false, priority:int = 0,
weakRef:Boolean = false):void {
_eventDispatcher.addEventListener(type, listener,
useCapture, priority, weakRef);
}
public function dispatchEvent(event:flash.events.Event):Boolean
{
return _eventDispatcher.dispatchEvent(event);
}
public function hasEventListener(type:String):Boolean {
return _eventDispatcher.hasEventListener(type);
}
public function removeEventListener(type:String,
listener:Function, useCapture:Boolean = false):void {
_eventDispatcher.removeEventListener(type, listener, useCapture);
}
public function willTrigger(type:String):Boolean {
return _eventDispatcher.willTrigger(type);
}
}
}
2006/8/16, Matt Chotin [EMAIL PROTECTED]:
Hmm, you might need to implement mx.data.IManaged yourself instead of
relying on IManaged. IManaged extends IUID (you must have a string property
uid) and IEventDispatcher (must be an event dispatcher). You will then need to
implement any managed property as follows (I haven't tested this, it's based on
reading the generated actionscript for a [Managed] class):
import mx.data.utils.Managed;
private var _test1:int;
[Bindable(event=propertyChange)]
public function get test1():int
{
_test1 = mx.data.utils.Managed.getProperty(this,
test1, _test1);
return _test1;
}
public function set test1(value:int):void
{
var oldValue:int = this._ test1;
_test1 = value;
mx.data.utils.Managed.setProperty(this, tes
[flexcoders] FDS, VOs, and ignoring client-side properties
We're using FDS on our project, and we're using a single DataStore with autoCommit=false on all of our DataServices. This way, we're able to have a single, application-wide save button to commit all the latest changes. This save button is enabled based upon on the DataStores' commitRequired property. In a few of my VOs, I have properties that do not have a corresponding property in my server-side POJO. The reson is that these properties are strictly used for keeping track of client-side state and are not persisted in our database. My problem is this: setting these properties on the client causes commitRequired to become true on our DataStore. This is sort of annyoing, as there really are no changes that need to be persisted. Of course, hitting the save button sends back the objects to the server where they are simply ignored because nothing has actually changed on them. So is there a way that I can force these properties to be ignored? Is there some type of undocumented metadata tag that I'm missing? I seem to remember something similar in Flex 1.5 to make serialization ignore a property, but this is a slightly different case. Jim -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com 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/
RE: [flexcoders] FDS, VOs, and ignoring client-side properties
Hmm, you might need to implement mx.data.IManaged
yourself instead of relying on IManaged. IManaged extends IUID (you must have
a string property uid) and IEventDispatcher (must be an event dispatcher). You
will then need to implement any managed property as follows (I havent
tested this, its based on reading the generated actionscript for a
[Managed] class):
import mx.data.utils.Managed;
private var _test1:int;
[Bindable(event=propertyChange)]
public function get test1():int
{
_test1 =
mx.data.utils.Managed.getProperty(this, test1, _test1);
return _test1;
}
public function set
test1(value:int):void
{
var oldValue:int = this._ test1;
_test1 = value;
mx.data.utils.Managed.setProperty(this,
test1, oldValue, _test1);
}
I have no guarantees, but see how it goes?
Matt
From: flexcoders@yahoogroups.com [mailto:flexcoders@yahoogroups.com] On Behalf Of Jim Laing
Sent: Wednesday, August 16, 2006
8:27 AM
To: flexcoders@yahoogroups.com
Subject: [flexcoders] FDS, VOs,
and ignoring client-side properties
We're
using FDS on our project, and we're using a single DataStore
with autoCommit=false on all of our DataServices. This way, we're able
to have a single, application-wide save button to commit all the
latest changes. This save button is enabled based upon on the
DataStores' commitRequired property.
In a few of my VOs, I have properties that do not have a corresponding
property in my server-side POJO. The reson is that these properties
are strictly used for keeping track of client-side state and are not
persisted in our database.
My problem is this: setting these properties on the client causes
commitRequired to become true on our DataStore. This is sort of
annyoing, as there really are no changes that need to be persisted. Of
course, hitting the save button sends back the objects to the server
where they are simply ignored because nothing has actually changed on
them.
So is there a way that I can force these properties to be ignored? Is
there some type of undocumented metadata tag that I'm missing? I seem
to remember something similar in Flex 1.5 to make serialization ignore
a property, but this is a slightly different case.
Jim
__._,_.___
--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com
SPONSORED LINKS
Software development tool
Software development
Software development services
Home design software
Software development company
YAHOO! GROUPS LINKS
Visit your group "flexcoders" on the web.
To unsubscribe from this group, send an email to:[EMAIL PROTECTED]
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
__,_._,___
