RE: [flexcoders] Binding Model Objects
If you can't change the DTO in anyway you might be out of luck. There's
a couple of hacky techniques that could help if you can change the
DTO...
You might be able to get away with making the bindable properties
transient, so that AMF doesn't try to get / set them during
(de)serialization, and a separate set of non-bindable properties which
are used for setting up the object, both of which point to the same
private variable internally. You'd need to find some way of triggering
the binding update event once the object had been deserialized into an
AS3 object, and this is a really horrible hack...
Something like
public class Foo extends EventDispatcher {
private var _bar : String;
[transient]
[Bindable(fooChanged)]
public function get bar() : String {
return _bar;
}
public function set nbBar( nbBar : String ) : void {
_bar = nbBar;
}
public function get nbBar() : String {
return _bar;
}
public function dispatchChangeEvent() : void {
dispatchEvent( new Event( fooChanged ) );
}
}
That's really horrible though...
Gregor Kiddie
Senior Developer
INPS
Tel: 01382 564343
Registered address: The Bread Factory, 1a Broughton Street, London SW8
3QJ
Registered Number: 1788577
Registered in the UK
Visit our Internet Web site at www.inps.co.uk
blocked::http://www.inps.co.uk/
The information in this internet email is confidential and is intended
solely for the addressee. Access, copying or re-use of information in it
by anyone else is not authorised. Any views or opinions presented are
solely those of the author and do not necessarily represent those of
INPS or any of its affiliates. If you are not the intended recipient
please contact is.helpd...@inps.co.uk
From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On
Behalf Of Richard Rodseth
Sent: 27 October 2009 16:09
To: flexcoders@yahoogroups.com
Subject: Re: [flexcoders] Binding Model Objects
This is consistent with the way I've done things. In my case conversion
was necessitated by needing a dirty flag on each record, but I also
like it philosophically.
However, in another portion of the application that I don't own, there
is a large DTO displayed in a table (with user-configurable columns),
and I don't think we can pay the price of conversion without also
implementing pagination/lazy loading.
RE: [flexcoders] Binding Model Objects
Having your DTOs physically different from your Domain Objects has a lot of benefit using the assembler pattern to map between the two. You can have entirely different structures for your DTOs, map multiple DOs to DTOs, keep your transport and domain layers separate (also allowing you to use different transport mechanisms AMF or XML over HTTP both easily swapped), and allow you a great deal of flexibility in structuring your application. Downside, yes the conversion process can be expensive, BUT only if you are planning on throwing around massive objects all the time. Taylor your service layer to be more responsive to your needs. Don't write a service which requires the whole object when all you need to send is an id (example, it's the difference between sending a whole email back to the server with the 'read' status marked as true, and just calling a 'markAsRead' service with the id of the email). Use paging techniques to break up your dataset, do you really need to fetch all 10k items now? If you are only showing them in 10 item chunks (i.e. in a datagrid) why not fetch them in 10 item chunks (or a few more for visual performance reasons). Well thought out business services can both reduce the amount of traffic you need to send, and allow DTO mapping to be realistic (on both ends of the wire). Gk. Gregor Kiddie Senior Developer INPS Tel: 01382 564343 Registered address: The Bread Factory, 1a Broughton Street, London SW8 3QJ Registered Number: 1788577 Registered in the UK Visit our Internet Web site at www.inps.co.uk blocked::http://www.inps.co.uk/ The information in this internet email is confidential and is intended solely for the addressee. Access, copying or re-use of information in it by anyone else is not authorised. Any views or opinions presented are solely those of the author and do not necessarily represent those of INPS or any of its affiliates. If you are not the intended recipient please contact is.helpd...@inps.co.uk From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf Of Richard Rodseth Sent: 26 October 2009 20:02 To: flexcoders@yahoogroups.com Subject: Re: [flexcoders] Binding Model Objects Jeff I hope we see some responses to this. I like the idea of non-bindable and immutable DTOs, but isn't it true that if you have a very large list, you've got substantial memory overhead in the conversion of those DTOs to the bindable objects. Or are people tackling that with virtualized collections?
RE: [flexcoders] Binding Model Objects
Gregor, I'm doing a good bit of what you describe already - like chunking the number of objects transferred, only transferring what is needed, etc. My big question based on Sean's preso was making domain objects bindable. Right now, I am, for the most part. For example, when editing a specific record in a datagrid, it makes it so much easier to have that object bindable so I can load it into a form and have the UI reflect that object instance. To NOT make domain model objects bindable would mean creating a third layer for binding and loading a non-bindable model object into it. That is a total headache, but I'd do it, if it really made that much difference. I'm a little skeptical that a bindable AMF model object is going to fire off a bunch of events when received by the Flex client. Jeff From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf Of Gregor Kiddie Sent: Tuesday, October 27, 2009 6:18 AM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Binding Model Objects Having your DTOs physically different from your Domain Objects has a lot of benefit using the assembler pattern to map between the two. You can have entirely different structures for your DTOs, map multiple DOs to DTOs, keep your transport and domain layers separate (also allowing you to use different transport mechanisms AMF or XML over HTTP both easily swapped), and allow you a great deal of flexibility in structuring your application. Downside, yes the conversion process can be expensive, BUT only if you are planning on throwing around massive objects all the time. Taylor your service layer to be more responsive to your needs. Don't write a service which requires the whole object when all you need to send is an id (example, it's the difference between sending a whole email back to the server with the 'read' status marked as true, and just calling a 'markAsRead' service with the id of the email). Use paging techniques to break up your dataset, do you really need to fetch all 10k items now? If you are only showing them in 10 item chunks (i.e. in a datagrid) why not fetch them in 10 item chunks (or a few more for visual performance reasons). Well thought out business services can both reduce the amount of traffic you need to send, and allow DTO mapping to be realistic (on both ends of the wire). Gk. Gregor Kiddie Senior Developer INPS Tel: 01382 564343 Registered address: The Bread Factory, 1a Broughton Street, London SW8 3QJ Registered Number: 1788577 Registered in the UK Visit our Internet Web site at www.inps.co.ukblocked::http://www.inps.co.uk/ The information in this internet email is confidential and is intended solely for the addressee. Access, copying or re-use of information in it by anyone else is not authorised. Any views or opinions presented are solely those of the author and do not necessarily represent those of INPS or any of its affiliates. If you are not the intended recipient please contact is.helpd...@inps.co.uk From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf Of Richard Rodseth Sent: 26 October 2009 20:02 To: flexcoders@yahoogroups.com Subject: Re: [flexcoders] Binding Model Objects Jeff I hope we see some responses to this. I like the idea of non-bindable and immutable DTOs, but isn't it true that if you have a very large list, you've got substantial memory overhead in the conversion of those DTOs to the bindable objects. Or are people tackling that with virtualized collections?
RE: [flexcoders] Binding Model Objects
Jeff,
Yeah, I just jumped all over the DTO part of the discussion. Our DOs
never get near AMF.
We convert everything btw... each record in the DG ends up as an
instance of a DO (which is why the performance of the service layer is
so important).
With DOs, we do make them bindable, but we use custom events to fire the
bindings, and we never ever make the entire object bindable, only the
fields required for the UI. The cheat here is when assembling the DO
from a DTO, use a method that doesn't go through the setters, and then
dispatch the change event once done, that way the binding operations can
be done in a single frame rather than being spread out.
Example (not the best architecture though).
public class fooDO extends EventDispatcher {
private var _bar : String;
public function set bar( b : String ) : void {
if ( _bar != b ) {
_bar = b;
dispatchEvent( fooChanged );
}
}
[Bindable(fooChanged)]
public function get bar() : String {
return _bar;
}
public function assemble( dto : FooDTO ) : void {
_bar = dto.bar;
dispatchEvent( fooChanged );
}
}
Quickly written out, but if all the bindable properties are fired off
fooChanged then the non-bindable DTO can be assembled into a Bindable
DO and cut down on the number of change events being fired. If the
default changeEvent is used, events will fire on each setter used
which is where the presentation is going.
Is that explained badly? Non-bindable DTOs assemble to bindable DOs in a
way that minimizes the amount of event slinging going on...
Gk,
Gregor Kiddie
Senior Developer
INPS
Tel: 01382 564343
Registered address: The Bread Factory, 1a Broughton Street, London SW8
3QJ
Registered Number: 1788577
Registered in the UK
Visit our Internet Web site at www.inps.co.uk
blocked::http://www.inps.co.uk/
The information in this internet email is confidential and is intended
solely for the addressee. Access, copying or re-use of information in it
by anyone else is not authorised. Any views or opinions presented are
solely those of the author and do not necessarily represent those of
INPS or any of its affiliates. If you are not the intended recipient
please contact is.helpd...@inps.co.uk
From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On
Behalf Of Battershall, Jeff
Sent: 27 October 2009 13:43
To: 'flexcoders@yahoogroups.com'
Subject: RE: [flexcoders] Binding Model Objects
Gregor,
I'm doing a good bit of what you describe already - like chunking the
number of objects transferred, only transferring what is needed, etc.
My big question based on Sean's preso was making domain objects
bindable. Right now, I am, for the most part. For example, when
editing a specific record in a datagrid, it makes it so much easier to
have that object bindable so I can load it into a form and have the UI
reflect that object instance. To NOT make domain model objects bindable
would mean creating a third layer for binding and loading a non-bindable
model object into it. That is a total headache, but I'd do it, if it
really made that much difference. I'm a little skeptical that a
bindable AMF model object is going to fire off a bunch of events when
received by the Flex client.
Jeff
RE: [flexcoders] Binding Model Objects
Thanks Gregor,
I think I'm starting to get it. - by having client-side bindable objects,
using custom events, that are generated from DTOs, you minimize the amount of
generic change events being fired.
What about ObjectProxy? Can't similar results be obtained there?
(http://blogs.digitalprimates.net/codeSlinger/index.cfm/2007/8/20/Making-the-unbindable-bindable-with-Object-Proxy).
Jeff
From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf
Of Gregor Kiddie
Sent: Tuesday, October 27, 2009 10:15 AM
To: flexcoders@yahoogroups.com
Subject: RE: [flexcoders] Binding Model Objects
Jeff,
Yeah, I just jumped all over the DTO part of the discussion. Our DOs never get
near AMF.
We convert everything btw... each record in the DG ends up as an instance of a
DO (which is why the performance of the service layer is so important).
With DOs, we do make them bindable, but we use custom events to fire the
bindings, and we never ever make the entire object bindable, only the fields
required for the UI. The cheat here is when assembling the DO from a DTO, use a
method that doesn't go through the setters, and then dispatch the change event
once done, that way the binding operations can be done in a single frame rather
than being spread out.
Example (not the best architecture though).
public class fooDO extends EventDispatcher {
private var _bar : String;
public function set bar( b : String ) : void {
if ( _bar != b ) {
_bar = b;
dispatchEvent( fooChanged );
}
}
[Bindable(fooChanged)]
public function get bar() : String {
return _bar;
}
public function assemble( dto : FooDTO ) : void {
_bar = dto.bar;
dispatchEvent( fooChanged );
}
}
Quickly written out, but if all the bindable properties are fired off
fooChanged then the non-bindable DTO can be assembled into a Bindable DO and
cut down on the number of change events being fired. If the default
changeEvent is used, events will fire on each setter used which is where the
presentation is going.
Is that explained badly? Non-bindable DTOs assemble to bindable DOs in a way
that minimizes the amount of event slinging going on...
Gk,
Gregor Kiddie
Senior Developer
INPS
Tel: 01382 564343
Registered address: The Bread Factory, 1a Broughton Street, London SW8 3QJ
Registered Number: 1788577
Registered in the UK
Visit our Internet Web site at www.inps.co.ukblocked::http://www.inps.co.uk/
The information in this internet email is confidential and is intended solely
for the addressee. Access, copying or re-use of information in it by anyone
else is not authorised. Any views or opinions presented are solely those of the
author and do not necessarily represent those of INPS or any of its affiliates.
If you are not the intended recipient please contact is.helpd...@inps.co.uk
From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf
Of Battershall, Jeff
Sent: 27 October 2009 13:43
To: 'flexcoders@yahoogroups.com'
Subject: RE: [flexcoders] Binding Model Objects
Gregor,
I'm doing a good bit of what you describe already - like chunking the number of
objects transferred, only transferring what is needed, etc.
My big question based on Sean's preso was making domain objects bindable.
Right now, I am, for the most part. For example, when editing a specific
record in a datagrid, it makes it so much easier to have that object bindable
so I can load it into a form and have the UI reflect that object instance. To
NOT make domain model objects bindable would mean creating a third layer for
binding and loading a non-bindable model object into it. That is a total
headache, but I'd do it, if it really made that much difference. I'm a little
skeptical that a bindable AMF model object is going to fire off a bunch of
events when received by the Flex client.
Jeff
RE: [flexcoders] Binding Model Objects
I've only ever used ObjectProxy in spikes as a replacement for real objects which weren't available, never in a production app. My impression of them was they were quite slow (as with all dynamic classes), but YMMV... Gk. Gregor Kiddie Senior Developer INPS Tel: 01382 564343 Registered address: The Bread Factory, 1a Broughton Street, London SW8 3QJ Registered Number: 1788577 Registered in the UK Visit our Internet Web site at www.inps.co.uk blocked::http://www.inps.co.uk/ The information in this internet email is confidential and is intended solely for the addressee. Access, copying or re-use of information in it by anyone else is not authorised. Any views or opinions presented are solely those of the author and do not necessarily represent those of INPS or any of its affiliates. If you are not the intended recipient please contact is.helpd...@inps.co.uk From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf Of Battershall, Jeff Sent: 27 October 2009 14:34 To: 'flexcoders@yahoogroups.com' Subject: RE: [flexcoders] Binding Model Objects Thanks Gregor, I think I'm starting to get it. - by having client-side bindable objects, using custom events, that are generated from DTOs, you minimize the amount of generic change events being fired. What about ObjectProxy? Can't similar results be obtained there? (http://blogs.digitalprimates.net/codeSlinger/index.cfm/2007/8/20/Making -the-unbindable-bindable-with-Object-Proxy). Jeff
Re: [flexcoders] Binding Model Objects
This is consistent with the way I've done things. In my case conversion was
necessitated by needing a dirty flag on each record, but I also like it
philosophically.
However, in another portion of the application that I don't own, there is a
large DTO displayed in a table (with user-configurable columns), and I don't
think we can pay the price of conversion without also implementing
pagination/lazy loading.
On Tue, Oct 27, 2009 at 7:15 AM, Gregor Kiddie gkid...@inpses.co.uk wrote:
Jeff,
Yeah, I just jumped all over the DTO part of the discussion. Our DOs never
get near AMF.
We convert everything btw… each record in the DG ends up as an instance of
a DO (which is why the performance of the service layer is so important).
With DOs, we do make them bindable, but we use custom events to fire the
bindings, and we never ever make the entire object bindable, only the fields
required for the UI. The cheat here is when assembling the DO from a DTO,
use a method that doesn’t go through the setters, and then dispatch the
change event once done, that way the binding operations can be done in a
single frame rather than being spread out.
Example (not the best architecture though).
public class fooDO extends EventDispatcher {
private var _bar : String;
public function set bar( b : String ) : void {
if ( _bar != b ) {
_bar = b;
dispatchEvent( “fooChanged” );
}
}
[Bindable(“fooChanged”)]
public function get bar() : String {
return _bar;
}
public function assemble( dto : FooDTO ) : void {
_bar = dto.bar;
dispatchEvent( “fooChanged” );
}
}
Quickly written out, but if all the bindable properties are fired off
“fooChanged” then the non-bindable DTO can be assembled into a Bindable DO
and cut down on the number of change events being fired. If the default
“changeEvent” is used, events will fire on each setter used which is where
the presentation is going.
Is that explained badly? Non-bindable DTOs assemble to bindable DOs in a
way that minimizes the amount of event slinging going on…
Gk,
*Gregor Kiddie*
Senior Developer
*INPS*
Tel: 01382 564343
Registered address: The Bread Factory, 1a Broughton Street, London SW8 3QJ
Registered Number: 1788577
Registered in the UK
Visit our Internet Web site at www.inps.co.uk
The information in this internet email is confidential and is intended
solely for the addressee. Access, copying or re-use of information in it by
anyone else is not authorised. Any views or opinions presented are solely
those of the author and do not necessarily represent those of INPS or any of
its affiliates. If you are not the intended recipient please contact
is.helpd...@inps.co.uk
--
*From:* flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] *On
Behalf Of *Battershall, Jeff
*Sent:* 27 October 2009 13:43
*To:* 'flexcoders@yahoogroups.com'
*Subject:* RE: [flexcoders] Binding Model Objects
Gregor,
I’m doing a good bit of what you describe already – like chunking the
number of objects transferred, only transferring what is needed, etc.
My big question based on Sean’s preso was making domain objects bindable.
Right now, I am, for the most part. For example, when editing a specific
record in a datagrid, it makes it so much easier to have that object
bindable so I can load it into a form and have the UI reflect that object
instance. To NOT make domain model objects bindable would mean creating a
third layer for binding and loading a non-bindable model object into it.
That is a total headache, but I’d do it, if it really made that much
difference. I’m a little skeptical that a bindable AMF model object is
going to fire off a bunch of events when received by the Flex client.
Jeff
RE: [flexcoders] Binding Model Objects
Gregor, Now that I look at it, I see what you're getting at - dynamic classes by nature are going to tax the JIT more. Binding is encouraged by the framework, and in numerous examples, but you don't learn of the potential downside to overuse until months or even years having solved problems a particular way. But this is the nature of the beast, isn't it. Welcome to the world of software development. Jeff From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf Of Gregor Kiddie Sent: Tuesday, October 27, 2009 10:58 AM To: flexcoders@yahoogroups.com Subject: RE: [flexcoders] Binding Model Objects I've only ever used ObjectProxy in spikes as a replacement for real objects which weren't available, never in a production app. My impression of them was they were quite slow (as with all dynamic classes), but YMMV... Gk. Gregor Kiddie Senior Developer INPS Tel: 01382 564343 Registered address: The Bread Factory, 1a Broughton Street, London SW8 3QJ Registered Number: 1788577 Registered in the UK Visit our Internet Web site at www.inps.co.ukblocked::http://www.inps.co.uk/ The information in this internet email is confidential and is intended solely for the addressee. Access, copying or re-use of information in it by anyone else is not authorised. Any views or opinions presented are solely those of the author and do not necessarily represent those of INPS or any of its affiliates. If you are not the intended recipient please contact is.helpd...@inps.co.uk From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf Of Battershall, Jeff Sent: 27 October 2009 14:34 To: 'flexcoders@yahoogroups.com' Subject: RE: [flexcoders] Binding Model Objects Thanks Gregor, I think I'm starting to get it. - by having client-side bindable objects, using custom events, that are generated from DTOs, you minimize the amount of generic change events being fired. What about ObjectProxy? Can't similar results be obtained there? (http://blogs.digitalprimates.net/codeSlinger/index.cfm/2007/8/20/Making-the-unbindable-bindable-with-Object-Proxy). Jeff
[flexcoders] Binding Model Objects
I happened across the slides from a presentation that Sean Chirstmann did at
Max 2008 about memory optimization in AIR
(http://www.craftymind.com/wp-content/uploads/2008/11/sean_christmann_optimizing_air_final.pdf).
One of his points was NOT to make DTOs or AMF objects bindable. I've been
making my AMF model objects bindable for a long time and I just wanted to get
second opinions from the list.
I can see the point - if model objects are bindable and are bound using strong
references to display object properties using {}, it could result in object
instances persisting when they should be available to the GC. If true, I have
to do significant re-factoring.
I'm looking for corroboration here - anyone care to share their thoughts on
this?
Jeff Battershall
Application Architect
Dow Jones Indexes
jeff.battersh...@dowjones.com
(609) 520-5637 (p)
(484) 477-9900 (c)
Re: [flexcoders] Binding Model Objects
Jeff
I hope we see some responses to this. I like the idea of non-bindable and
immutable DTOs, but isn't it true that if you have a very large list, you've
got substantial memory overhead in the conversion of those DTOs to the
bindable objects. Or are people tackling that with virtualized collections?
On Mon, Oct 26, 2009 at 12:10 PM, Battershall, Jeff
jeff.battersh...@dowjones.com wrote:
I happened across the slides from a presentation that Sean Chirstmann did
at Max 2008 about memory optimization in AIR (
http://www.craftymind.com/wp-content/uploads/2008/11/sean_christmann_optimizing_air_final.pdf
).
One of his points was NOT to make DTOs or AMF objects bindable. I’ve been
making my AMF model objects bindable for a long time and I just wanted to
get second opinions from the list.
I can see the point – if model objects are bindable and are bound using
strong references to display object properties using {}, it could result in
object instances persisting when they should be available to the GC. If
true, I have to do significant re-factoring.
I’m looking for corroboration here – anyone care to share their thoughts on
this?
Jeff Battershall
Application Architect
Dow Jones Indexes
jeff.battersh...@dowjones.com
(609) 520-5637 (p)
(484) 477-9900 (c)
