Writing Custom UI Controls

[Elisa Deaibess]

Thank you all for your valuable and helpful information

Regards,
Elisa

On Mon, Jul 16, 2012 at 8:15 PM, Richard Bair <richard.bair at oracle.com>wrote:

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