Writing Custom UI Controls

[Richard Bair]

Ya. And to provide a little background, originally in 1.0 we talked about making Behavior a public API along with Skin and Control. It was always the idea. However as we got close we realized that Behavior just wasn't (a) strictly necessary and (b) vetted enough to be public. In particular, I always wanted the same kind of functionality in UI controls that we had with Actions and ActionMaps in Swing components. But we didn't have time to do a proper Action / Command pattern investigation and implementation, and so I didn't think Behavior was ready to be public API, since it would necessarily have some overlap there. And strictly speaking until we expose the action map concept, there is no need for Behavior to be public (and maybe, depending on how we do it, you won't need to have Behavior public anyway). So instead it became an aid in our implementation to help separate the UI design from the interaction logic. In some cases this was very clean and helpful (since in theory unit testing a Behavior should be much, much easier than testing a Skin) and also has the benefit that in some cases it makes it easier to write new skins and reuse existing behaviors. In some controls like TextInputControl, this breaks down quickly and requires some extra complication because the UI design and interaction design are so closely linked (as opposed to something like, say, a Button).

Long story short, it just isn't ready for prime time, but it is on the plan for 3.0 to get this sort of infrastructure (as far as we are able in the time) public.

Richard

On Jul 16, 2012, at 9:09 AM, Christian Schudt wrote:

> Hi,
> 
> I wondered about that topic, too.
> 
> I do it that way, that I only use Control and Skin<C> (public API)
> I put all the behavior in the class which implements Skin<C>.
> 
> Sometimes, I also derive from layout containers or other controls.
> I think this depends on what you want to achieve and what base implementation helps you most.
> If you want to layout stuff, use layout containers. If you want to extend some functionality (e.g. I added maxLength to the TextField), derive from an existing control.
> Otherwise derive from Control.
> 
> Just the use of the BehaviorBase is questionable.
> 
> Regards
> Christian
> 
> 
> 
> Am 16.07.2012 um 14:33 schrieb Elisa Deaibess:
> 
>> Hi,
>> 
>> We are writing a new application using JavaFX 2.x. Our application needs
>> some custom controls such as a searchfield, listoptions, ribbon,
>> breadcrumbs, etc...
>> 
>> We decided to write common reusable controls; To do that we have 2 ways:
>> 
>>  1. Make our controls extends Control and create new skin
>>  2. Extend some layout container or other control
>> 
>> 
>> Which one do you recommend?
>> Is it safe that our custom controls extends Control and to use the
>> skin/behavior? Or com.sun.javafx.scene.control.skin.SkinBase is a private
>> class and risk to be removed in the next releases
>> 
>> In JavaFXPro book I read the following:
>> 
>> *Caution *In the discussion that follows, we mention Java classes in
>> packages whose names begin with com.sun.
>> These classes are implementation details of the JavaFX runtime system and
>> are not meant to be used in normal JavaFX applications.
>> And they may change in future releases of JavaFX.
>> 
>> Could you please advise?
>> 
>> Regards,
>> Elisa
>