Review request for RT-19228

[Greg Brown]

> I can understand the impatience but really there needs to be an affirmative answer before an API addition / change is made.

It's not a question of impatience - I just assumed that silence == acceptance, since the original request was posted well over a week ago.  ;-)

> It would be helpful to have a condensed description of the final solution with reasons behind it. I didn't just give it an immediate +1 because the final solution is OK but not what I had hoped for, and introducing a new syntax / special fx:attribute is kind of a bummer.

I don't personally think that the addition of a new keyword should be viewed as a negative; rather, just something that we missed the first time around. Also, as I mentioned in the JIRA ticket, the syntax is consistent with the existing fx:value and fx:factory attributes, both of which are also used to access static functionality.

> These are still my favorites:
> 
> <TableView columnResizePolicy="CONSTRAINED_RESIZE_POLICY" /> 

> <TableView columnResizePolicy="TableView.CONSTRAINED_RESIZE_POLICY" />


The problem with both of these is that they would require FXMLLoader to have knowledge of the nature of an attribute, which is something that, by design, we don't do. With the exception of the reserved attribute prefixes ($, %, and @), FXMLLoader treats attribute values as opaque text. It delegates responsibility for understanding the nature of that text elsewhere. If we didn't do this, FXMLLoader would quickly become very complex and unmanageable.

In general, type conversion is handled by BeanAdapter, which has built-in support for handling primitive types as well as enums. But BeanAdapter, in turn, delegates responsibility for any custom conversions to the target type (that is, the type of the property). So if the property type isn't an enum or a primitive, BeanAdapter looks for a static valueOf() method on the target type to perform the conversion.

Unfortunately, we can't use valueOf() here, because the type of the "columnResizePolicy" property is an interface, and interfaces (for some reason) don't support static methods. However, another option we could consider is a builder. Builders are commonly used to construct objects that don't adhere to bean conventions, but (among other things) they can also be used to perform custom type conversions. For example, when a hypothetical TableViewBuilder instance is given a String value for "columnResizeProperty", it would know that it should look for the value of that constant on the TableView class. That would allow us to support either of your proposed alternatives (I personally prefer #1 since it is less verbose). 

So a builder might be a good way to address this particular issue. However, I don't think that using a builder here necessarily invalidates the fx:constant concept. FXML currently lacks a standard way to refer to constants, and I think fx:constant would be a nice, consistent way to do it.

> How does this conflict with attached properties to not have fx:constant?

Sorry for the confusion - I thought there was another suggestion in there that used a syntax similar to what we do for attached properties, but I can't seem to find it now. You can ignore that comment.

G