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]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
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 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
YAHOO! GROUPS LINKS
__,_._,___
|
