Programmatic (Java) access to style / layout ?

Tom Eugelink tbee at
Wed Dec 18 03:09:01 PST 2013

Small side remark: in order to stay compliant with the Java Bean specification, these kind of setters are often implemented as withers (which call the setter and return this):


Or as plain methods:


On 2013-12-18 12:03, Assaf Yavnai wrote:
> I agree that different people would like different things....
> here is mine ;)
> button.border().hover().setColor(red);
> This styling is widely used in scripting languages, jQuery is a good example. Its done by always return an object from an operation, in this example setColor() will return the same object that was returned from hover(), allowing further manipulation in the same line of code. For example button.border().hover().setColor(red).setStrokeWidth(10).setBlink(false).setHandler(()->{}); If readability is an issue it can be formatted as:
> button.border().hover()
>     .setColor(red)
>     .setStrokeWidth(10)
>     .setBlink(false)
>     .setHandler(()->{});
> And this reminds me another issue, which may be a fork, but in my point of view its originated from the same approach, which is users manipulate internal data structures directly to do operations.
> I didn't understand the design decision to expose internal structures in FX to do operations and manipulate them directly. In this case properties, another example is root.getChilderen().add(). This not only expose the internal data structure, but also requires more coding for simple trivial operation. users >90% don't need/care about the internal data structures, but 100% want to write less and simpler code. Usually user just want to do some trivial thing, add, remove, traverse..., for those common cases an alias can be used that encapsulate inside it the data structure used and the language quirks. In this example root.add() would do the trick. Other operations could look similar, like root.clear(), root, remove(...). root.traverse()(will return an iterator). For those edge cases which requires manipulating the data structure directly API can expose them, like root.getChildrensAsList(), or root.getChildren()
> Combining the 2 approaches and the ability to retrieve the nodes related to the operations in 2 levels, say through .base() and .parent(), would yield the results that Oliver suggested (as I understood them)
> (hope the layout wouldn't get scrambled upon send)
> Group root = new Group()
>                             .add( new Button()
>                                                 .border()
>                                                     .hover()
> .setColor(red)
> .setStrokeWidth(10)
> .setBlink(false)
> .setHandler(()->{})
>                                                 .parent() //parent() return border
> .setColor(blue)
> .setBlink(true)
>                                                 .base().caption() //base() return button
> .setText("button1")
> .setFontSize(30)
>                                     .base(),
>                                     new Button("button 2").caption()
>                                       .setSize(25)
>                                       .setHandler(()->{}))
>                                     .base()
>                         )//end of add()
>                         .some().other().operation.onGroup()
>                     );
> my 0.002$
> Assaf
> On 12/17/2013 11:18 PM, David Grieve wrote:
>> It is possible, but probably not in the way that would provide. By that I mean, it would be nice to be able to progammatically say "the border color for this button when hovered is red." This can be done now by adding an invalidation listener to the hoverProperty and setting the border on Region, but I don' t think this is what you are after.
>> I think RT-17923 means different things to different people. I'd be interested to know what such and API would look like to you.
>> On Dec 17, 2013, at 3:39 PM, Oliver Doepner <odoepner at> wrote:
>>> Hello,
>>> This might have been asked before but I haven't found it:
>>> Is it possible to style JavaFX components using pure Java (i.e. without
>>> CSS)?
>>> If this is being worked on, does anyone know what the status is?
>>> I think this is one of the areas where JavaFX can actually be better than
>>> HTML5/CSS because a nicely typed Java representation of CSS could provide
>>> great tooling and features that others had to invent LESS or SASS for.
>>> I have seen this (from Oct 2012):
>>> I have also seen this:
>>> Last update: Brian
>>> Beck<>added
>>> a comment - Mar,
>>> 12 2012 09:01 PM : "It is now past the point where this feature can be
>>> added for 2.1. Will need to be considered for a future release"
>>> Thanks
>>> Oliver
>>> -- 
>>> Oliver Doepner

More information about the openjfx-dev mailing list