I'm a big fan of the Eclipse plug-in model, though it's been a while since I looked at how they do Perspectives, for example.
I take Alex's point (I think), but I'm not sure we're on the same page regarding what is "the model". The end goal is that a configuration file (XML, say) could describe a layout by specifying a template and a bunch of things to place at various named locations in that template. By definition, the config file has to know the names of the locations, so I don't see how that is a violation of encapsulation. To validate the description, one needs that knowledge. I suppose if one had a layout editor (something I'm not planning at this time), once you'd filled in a template, it could persist the description, but then the layout editor would need that knowledge. The list of places you can put stuff *is* part (all) of the interface of the template. However, I am persuaded to make a template base that consumes a "description model". That's basically what I was doing in the DynamicLayout that contains (and creates) the template instance. Thanks for the input. On Thu, Aug 21, 2008 at 11:33 PM, Rick Winscot <[EMAIL PROTECTED]>wrote: > Just a .02 clink... Alex is recommending a hallmark architectural > pattern for building an application from constituent parts ( > http://tinyurl.com/9js2e). <http://tinyurl.com/9js2e%29.> One of the > hurdles in implementing this in Flex has to deal with how creation policy > plays with loosely tied models; if it hasn't been touched yet – it doesn't > exist, visual updates fail, and runtime errors usually follow. > > On a couple occasions I had to resort to have the template base listen for > any data changes on the model and when data change events fire – to pull > those changes local and update internal bindable variables that are used in > the template and drive the UI. Duplication you say? Yes... sadly there is > duplication involved. > > Why do it this way? I've found that no matter how 'late' you try and > capture a data event... That there are times when controls like the view > stack just don't play nice. Fiddling with creationPolicy can help but > doesn't address the root cause. So... tight coupling within the template > with loose coupling to the model was a reasonable approach. > > Rick Winscot > > > On 8/22/08 12:27 AM, "Alex Harui" <[EMAIL PROTECTED]> wrote: > > > > > creationCOmplete is a better bet, but pushing stuff into the template is > potentially bad design. It means you know something about the template and > have broken encapsulation. Other designs like model/view would have the > template pull from a data model. Other designs would have an interface to > the template that abstracts what children do what. That's how many of our > components work and they use the lifecycle events and methods to validate > properties "later" > > > ------------------------------ > > *From:* [email protected] [mailto:[EMAIL PROTECTED]<[EMAIL > PROTECTED]> > *On Behalf Of *Richard Rodseth > *Sent:* Thursday, August 21, 2008 2:28 PM > *To:* [email protected] > *Subject:* [flexcoders] Template architecture > > > I'm prototyping a system where a view is built dynamically from an XML > description (converted to VOs). The description refers to a template > (hard-coded in MXML). The dynamic view observes the description (which is a > part of its model) , and creates a child (the template) and adds it as a > child. However, it also needs to "fill in" the template which involves > accessing some of its children by id (eg. template["slot1"], > template["slot2"] ). > > If I construct the template via new Template1(), the children are not yet > created. Their ids show up in the debugger, but the values are null. Should > I add a listener for creationComplete, or is this a case where callLater() > could be put to good effect? > > > > > >
