Thoughts with >>>. My mail program did not auto > the previous email :-)
Thanks for responding to this. I'll close this out. -----Original Message----- From: Greg Brown [mailto:gkbr...@mac.com] Sent: Wednesday, June 23, 2010 2:41 PM To: dev@pivot.apache.org Subject: Re: [jira] Resolved: (PIVOT-542) enable the serializer to initialize components written in java code > The seriliazer already plays the initialization role. The serializer is the creator and the initializer. In the model you suggest, it is only the initializer - the new keyword is used to create the object. This is inconsistent. If you only need initialization, you should use the bind() method. >>>bind() cannot automatically perform full binding actually on its own without coding. Coding is not bad, but its not needed here. With the proposed approach, variables, not just @WTKX variables, including those defined in superclasses are automatically initialized because the xml is just the freeze dried version of the object. In fact the Bindable interface with the initialize method encourages you to reach in and get resources. A cleaner approach is that the properties at the root level of the serializer are really the properties of the object being created. > My understanding is that skins are views. Components are model/controllers. > The view should not be loading user data and other child content into the > mode/controller so I'm not sure I would agree that the skin should be doing > this at all because part of the initialization is also Component data such > as userData. Skins shouldn't get involved in the model data, but they are allowed to add sub-components. For example, all composite component skins do this (Spinner, ScrollBar, Frame, etc.). >>>That's a great point. And in fact, this initialize() proposal does not change this it all. > With the editor, there are a few ways to do this. This is actually a very > direct approach. In the thoughts below, I am still forced, at a minimum, to > use an interface and for me to write code for wiring. I'm not against > writing code but when the serializer can do it naturally, that's a win. The problem is that the suggested modifications to the serializer are not natural because they don't fit in with the overall design of the framework. >>>I think I get your point about skins and I think I appreciate skins more now than I did before. >>>But I can see from other recent changes to the Bindable interface that you are moving closer to this initialize proposal. If you take Bindable to the next step, you starting getting the initialize approach I am proposing. Not against Bindable, but its another interface that's not always needed and bind() cannot automatically initialize all of the object's properties automatically such as userData or other properties define in your code-behind. The serializer is actually inconsistent in its ability to initialize instance variables of the calling object when you call bind(). Bind() can only do @WTKX variables, but a component has a lot of variables in superclasses that could use similar help. >>>Lets say you remove the Bindable interface because you don't want component writers to have to worry about another interface and their methods for initialization. What would you do? The initialize() proposal is an answer and it does more initialization of variables since bind() only does @WTKX annotated variables. The semantics of Bindable combines two logical elements into one: some bind() which is instance variable initialization and notifying the object it has been bound (that it has been initialized through binding). @WTKX still stays because it initializes variables only in your subclass without any extra work, a huge convenience. >>Notifying that a bind has occurred is actually closer to @PostConstruct which is a java standard. It is called after instantiation and automatic variable initialization. But in pivot Bindable tries to do both. It combines two things into one. Teasing this apart slightly with this proposal around initialization semantics actually improves consistency of instance variable initialization and provides a new capability for clients. You can't annotate instance variables in superclasses without access to source code, but you still want them initialized from the serializer just like @WTKX variables in your subclass. It's a big convenience. >>>Example: Think about the MyDialog just posted to the user list. In it, you define a subclass of Dialog. But to allow them to use it they have to use an include in the bxml because the "contents" of the dialog are in the bxml. I say skip the include. When you need to use the MyDialog in code or bxml, just refer to the class as you would any other pivot-provided component. The bxml just backs the object being created. In this case, there is total consistency between code and bxml in terms of using MyDialog regardless of how its deployed by the client. The MyDialog.bxml would be used behind the scenes, using this proposal, to initialize the object whether the client created it in code or bxml. Of course, MyDialog could be coded other ways, such as creating a skin. But for this, would do really go through that effort? > It took me awhile to understand why I > had to always had to do extra work with includes or setting left and right > children in code until I realized that the serializer should be doing it for > me. Again, in frameworks that compile to classes, this makes sense. When I define MyClass.xaml and MyClass.cs, they are both combined such that the following both instantiates and initializes the class: MyClass myClass = new MyClass(); But this doesn't work for BXMLSerializer. >>> I am not totally familiar with the blending you describe but I don't think that object instantiation and initialization are directly tied to blending. I am not claiming that "you" create the element directly, just that the bxml file holds parts of the freeze dried version of the object whether you create the root object in code or bxml. In xaml, I don't think there are there are any "do an include to include your object" and you should not have to (but its an option), in pivot.
