Re: [flexcoders] Mediators, Presentation Models and Flex 4 Components
Thanks Gabirel. I'm also thinking about the case when we use some flex framework like Parsley. For performance reasons it is generally advised to only manage lightweight classes by the framework and for views mediators are used. So any suggestion on how to create mediators that fit good in the new Flex 4 component/skin architecture? Thanks, Haykel Ben Jemia Allmas Web RIA Development http://www.allmas-tn.com 2010/5/4 gabriel montagné gabr...@rojored.com Hi, On 04/05/2010, Haykel BEN JEMIA hayke...@gmail.com haykelbj%40gmail.com wrote: with the new Flex 4 components architecture which actually separates logic from design with the Skin paradigm, what is the best way to implement Mediators/Presentation Models that best uses the capabilities of this architecture (partAdded, partRemoved, getCurrentSkinState etc.). The new Flex 4 skin architecture allows a clean enough separation of layout and behavior concerns to be able to do without other options which aim at the same kind abstraction but cannot achieve the same degree of integration with the framework. For now I'm simply using the AS class of a component as a mediator and the skin as a view. I would say this is perfectly complete, I wouldn't go looking for any more levels of indirection. Cheers, Gabriel -- gabriel montagné láscaris comneno http://rojored.com +44 (0) 7500 709 209
Re: [flexcoders] Mediators, Presentation Models and Flex 4 Components
Hi, On 05/05/2010, Haykel BEN JEMIA hayke...@gmail.com wrote: I'm also thinking about the case when we use some flex framework like Parsley. For performance reasons it is generally advised to only manage lightweight classes by the framework and for views mediators are used. So any suggestion on how to create mediators that fit good in the new Flex 4 component/skin architecture? I'd say that first there's the Flex framework level---it's component and application lifecycles---with which you should be very familiar with if you're concerned about your application's performance. If used properly it will hide from you most of the problems associated with flash performance like frame render cycles and the order in which things are measured and laid out. And then the micro-architecture level, also called framework, but which is a different level---the level at which Parsley would be described---which guides you about how components and other classes are grouped into larger applications. It is at this level a one can appreciate a light weight, non intrusive frameworks which reduce the need to write boiler plate code and will let you aggregate features to your application in a way that you can always make sense of what's going on... but performance at this level is perhaps more of a programmer's performance: how can these guidelines and helper classes keep the accumulating code readable for programmer whose job, more than anything else, is to read lots and lots of ageing code. I've been using Swiz lately ---which is somewhat related to Parsley--- and the guys that build it insist on not having to extend their classes but only mark here and there with metadata to let the framework fill in the gaps for you. This is not, I think, to make the app go faster but to keep you from becoming confused with myriads of strange unfamiliar voodoo classes which multiply in between the parts you do properly understand: your components and your data. But this is not at the skin-host level but higher up. So regarding your question, if in your host component you understand the lower level interactions of your skin parts (clicked this, typed that) and can translate them into higher level gestures (attempt a login, make a search) which you can just dispatch in the simplest way possible and let your Swiz or Parsley, etcetera, classes magically forward that gesture your controllers, mediators, I guess you should be fine. hth, gabriel -- gabriel montagné láscaris comneno http://rojored.com +44 (0) 7500 709 209
[flexcoders] Mediators, Presentation Models and Flex 4 Components
Hi, with the new Flex 4 components architecture which actually separates logic from design with the Skin paradigm, what is the best way to implement Mediators/Presentation Models that best uses the capabilities of this architecture (partAdded, partRemoved, getCurrentSkinState etc.). For now I'm simply using the AS class of a component as a mediator and the skin as a view. How do you handle this? Haykel Ben Jemia Allmas Web RIA Development http://www.allmas-tn.com
Re: [flexcoders] Mediators, Presentation Models and Flex 4 Components
Hi, On 04/05/2010, Haykel BEN JEMIA hayke...@gmail.com wrote: with the new Flex 4 components architecture which actually separates logic from design with the Skin paradigm, what is the best way to implement Mediators/Presentation Models that best uses the capabilities of this architecture (partAdded, partRemoved, getCurrentSkinState etc.). The new Flex 4 skin architecture allows a clean enough separation of layout and behavior concerns to be able to do without other options which aim at the same kind abstraction but cannot achieve the same degree of integration with the framework. For now I'm simply using the AS class of a component as a mediator and the skin as a view. I would say this is perfectly complete, I wouldn't go looking for any more levels of indirection. Cheers, Gabriel -- gabriel montagné láscaris comneno http://rojored.com +44 (0) 7500 709 209
