> On Mon, Jan 3, 2011 at 8:38 AM, Greg Brown <[email protected]> wrote: >> If the attribute was processed in the opening tag, we'd get an >> IndexOutOfBoundsException, since the Labels would not have been added yet. >> >> This is the problem I faced. But most of other attribute seems OK to set at >> the opening tag. > > Correct - many attributes can be set in the opening tag, but any that have > dependencies on child elements cannot. Since there is no harm in setting all > attributes in the closing tag, that is what we do. > >> If Pivot is used only through BXML, these order are hidden from user, it may >> not matter. >> But if it is directly used in Java codes, this makes code hard to read. > > Agreed, but if you are hand-coding using your builder style, you can put the > setters wherever you like. If you are using a BXML to Java converter, it > doesn't really matter where they go because the generated code isn't really > meant to be human-readable (that's what BXML is for). > > This is quite opposite for my purpose. I would want to have human readable > Java code. In fact, If we do start using this builder style, we will not need > BXML file nor this converter.
Though you may prefer to use the builder pattern exclusively, others may prefer to continue working with BXML. The converter would be a nice way to ensure that a BXML source is valid. >> Also this cases, I wonder why it just can't set the initial index value. The >> Pivot code may select element after tabs tag is closed if selectedIndex is >> defined. > > Not sure what you mean. TabPane has a default value for selectedIndex. > However, TabPane doesn't know anything about a closing tag - only > BXMLSerializer knows about that. > > I have not looked at the current codes for selectedIndex, but if it creates > a selectedIndex function and register in a list of post evaluation function > associated with the corresponding element, when the tag is closed, it can > start evaluation these functions. ... > Essentially it is hard for user to remember which attributes must be set > after elements declaration, "selectedIndex" simply maps to TabPane#setSelectedIndex(). Obviously, you can't call setSelectedIndex() until the tabs have been added. So I don't think there should be any confusion on the developer's part. It would probably help for you to look at the Java APIs themselves rather than trying to reverse-engineer them from BXML. I think that may help clarify some things for you. BTW, I believe I understand the issue with the non-struct final classes now - since you can't create anonymous inner subclasses of them, it breaks your builder pattern. I can see an argument for making those classes non-final - however, the struct classes need to stay final for performance reasons (and, as I mentioned, aren't really meant to be used in markup anyways). G
