> You want me to create a one line file and include it because Pivot doesn't > support lifecycle notification? That's absurd. A one line bxml file. Is > there any conceivable use for a one line bxml file aside from working around > this problem? And I'm supposed to create these files every time I want a > notification?
The point is that BXML (intentionally) doesn't define any kind of "lifecycle notification". It is a shortcut for creating Java class instances. Java's support for "lifecycle notifications" includes the constructor, methods, and the finalizer. You have access to the same facilities in BXML. The Bindable#initialize() method only exists because, without it, a root element would have no way of knowing that all of the page variables had been fully processed. In essence, initialize() is a "constructor" for functional modules defined in BXML. Just like you partition functionality into classes in Java, you can partition it into separate includes in BXML. > Here's the thing. I have a component. It has a button for adding children, > but it has to know what wtkx file to include and it has to know the value of > one other property. I want it to create one child (like pressing the 'add > child' button) after its properties have been set (so it knows how to do it) > by the serializer so that one child item appears in the UI when the user sees > it. From there they can click the 'add child' button to their heart's > content. This makes an even stronger case for separating your BXML file into includes. In the BXML that declares your button, you can include the BXML that defines the child component. Then, the button press listener can use BXMLSerializer to load new instances of the child component every time it is pressed. Now, with that said, I would like to provide some hopefully constructive feedback. While I sincerely appreciate your interest in the platform and suggestions for how to improve it, your approach to communication on the mailing lists often borders on antagonistic and arrogant when those suggestions are rejected. This makes me (and possibly others) reluctant to want to help you. I recommend that you try asking questions about how your design issues might be solved within the existing framework before suggesting changes to it. Note that I'm not attempting to discourage you or anyone else from challenging elements of Pivot's design - that's how the platform evolves. However, a lot of thought has gone into the existing design, and I think it's pretty good. The constant onslaught is getting a bit frustrating. Greg
