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: [email protected] [mailto:[email protected]] On Behalf Of Gregor Kiddie Sent: Tuesday, October 27, 2009 10:15 AM To: [email protected] 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.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 [email protected] ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Battershall, Jeff Sent: 27 October 2009 13:43 To: '[email protected]' 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
