This is working out quite nicely, but I'd like some validation. Rather than using an init event as described here:
http://livedocs.adobe.com/flex/3/html/help.html?content=templating_3.html I have a property setter for the template contents (or a definition object in my more complex cases). The setter calls invalidateProperties() (and sets _contentsChanged) and an override of commitProperties() does the actual child manipulation. An override of commitProperties doesn't feel too out of place in an MXML file. By including a "contentHolder" child (or several), I can do a contentHolder.removeAllChildren(), otherwise I would have to save off _oldContent in addition to _newContent. At first I hadn't related my XML-driven template to these simple ones as described in the livedocs, but it makes sense I think. Would you agree that the docs above should suggest the commitProperties approach ? On Fri, Aug 22, 2008 at 8:03 AM, Richard Rodseth <[EMAIL PROTECTED]> wrote: > 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? >> >> >> >> >> >> > >
