Review request for RT-19228

[Daniel Fuchs]

Hi,

On 3/30/12 7:50 PM, openjfx-dev-request at openjdk.java.net wrote:
>> >  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" />

<TableView columnResizePolicy="TableView.CONSTRAINED_RESIZE_POLICY" />
was also my favorite in the beginning.

However - I like the symetry of fx:constant with fx:factory:

<FXCollections fx:factory="observableArrayList"/>
  => The result is obtained by evaluating:
    FXCollections.observableArrayList()
    (static method call)

<TableView fx:constant="CONSTRAINED_RESIZE_POLICY"/>
  => The result is obtained by evaluating:
    TableView.CONSTRAINED_RESIZE_POLICY
    (static immutable final field)

[...]
> 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.

I am not a great fan of stuffing customized syntactic sugar inside
builders. Builders are mostly opaque to tools - and any customized
syntax supported by builders only usually need hand-crafted hacks on the
tool side. Such is already the case for Font, Image URL,
WebView location etc... Everything that is not a regular bean pattern is
a pain. I much prefer an explicit fx:constant attribute.

-- daniel

>
>> >  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
>