Skip to content
This repository has been archived by the owner on Jun 24, 2021. It is now read-only.

JDK-8091189: Make BehaviorBase Public API #241

Open
DJViking opened this issue Oct 6, 2018 · 3 comments
Open

JDK-8091189: Make BehaviorBase Public API #241

DJViking opened this issue Oct 6, 2018 · 3 comments
Labels
enhancement New feature or request

Comments

@DJViking
Copy link

DJViking commented Oct 6, 2018

We should have Behavior as public API, so we can get all aspect of MVC available in JavaFX.

Are there any plans for doing this?
This sentence has been a part of the JavaFX javadoc for a very long time.

at present there is no public API for the "controller" aspect


I was creating my own Behavior class to use in my Skin. Since I do not want to rely on the private API com.sun.javafx.scene.control.behavior.BehaviorBase, my Behavior does not extend anything. It contains the behavior which is accessed from the Skin. I have done as suggested in the Javadoc to delegate out from the Skin the behavior in a seperate class.

This one here got me to laugh a bit while I was reading the code in TextFieldBehavior for inspiration.

  // An unholy back-reference!
  public void setTextFieldSkin(TextFieldSkin skin) {
      this.skin = skin;
  }

Why does the behavior have an unholy back-reference? Perhaps some further explanation should be written along with this statement.

@kevinrushforth
Copy link
Collaborator

kevinrushforth commented Oct 6, 2018

This is tracked by JDK-8091189. The short answer is that we have no plans to do this.

Making behaviors public is a very large project, and not something we would do without a compelling reason. It was originally proposed as part of JEP 253, but was decoupled after some investigation. Unlike the public Skin APIs, which were relatively straight-forward and are necessary to allow third-party developers to implement their own controls, a public Behavior API was larger in scope and not as clearly a requirement. Additionally, there was a not-fully-answered discussion about design direction.

I recommend reading the long discussion in JDK-8091189 starting with about this comment to the end.

@kevinrushforth kevinrushforth changed the title Make BehaviorBase Public API Make BehaviorBase Public API - JDK-8091189 Oct 6, 2018
@kevinrushforth kevinrushforth changed the title Make BehaviorBase Public API - JDK-8091189 JDK-8091189: Make BehaviorBase Public API Oct 6, 2018
@eugener eugener added the enhancement New feature or request label Oct 9, 2018
@madoar
Copy link

madoar commented Oct 10, 2018

@kevinrushforth thank you for the summary about the current state.

I've also stumbled over the "problem", that I would like to model my applications according to the MVC pattern.
In my personal opinion, it is not really an issue, that the controller can not be implemented separately yet (i.e. in a behavior class).

The more important issue for me is, that I couldn't really find a guide, which explains the recommended way to implement custom components, i.e. how the different aspects of a custom component should be divided to different classes.
It is quite clear in my opinion, that the model part should be implemented in a class extending the Control class, while the view part should be implemented in a class extending the Skin interface.
What remains unclear is, where should I implement the controller/behavior part?

Most articles I found about this topic suggest implementing the behavior part in a class extending the BehaviorBase class, which is not public/does not exist.
An example for such an article is the one located on the GuiGarage homepage.

I believe it would help a lot of people (including myself), if someone, working on JavaFX/OpenJFX, writes a new article, which explains the current state and provides a recommendation about how a custom component should be implemented in a MVC way.

@DJViking
Copy link
Author

The Skin could separate out the controller functionality into another class. Depending on the control you extends you would get the default behavior for that control, and still be able to implement additional behavior on top.

From the Javadoc:

Controls follow the classic MVC design pattern. The Control is the "model". It contains both the state and the functions which manipulate that state. The Control class itself does not know how it is rendered or what the user interaction is. These tasks are delegated to the Skin ("view"), which may internally separate out the view and controller functionality into separate classes, although at present there is no public API for the "controller" aspect.

I have created a CustomBehavior for my CustomSkin, which does not extend anything, but is used from within the Skin to affect the behavior of the control. That way I get the separation of concern with MVC.
Model > Custom
View > CustomSkin
Controller > CustomBehavior

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants