<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>I think there is definitely room for improvement here, but I
think most controls can currently be build externally, if you are
willing to do all the work. Your control may suffer however when
you need to integrate with event, focus handling or keyboard
navigation. Skins and Behaviors are not something that are a
requirement to use to build a custom control, although they can
make it easier to adapt existing controls, up to a point.</p>
<p>The problem with making things public is that this means they
must be specified, and that we must be **very** sure that it is a
solid API that will stand the test of time. That's often a
significant time investment that could seriously delay building a
complicated control like TableView.</p>
<p>I think Skins especially are very hard to design in such a way
that they have sensible public/protected methods. They often deal
with very specific layout or design problems, that could restrict
the evolution of the control if there is a fundamental change in
how the Skin is constructed. Just imagine if the very first
TableViewSkin had all its methods public, and that they couldn't
be changed up to this day because the Skin may have been
subclassed by 3rd parties.</p>
<p>This is why I would advocate instead to make it easier to replace
Skins entirely (by being able to copy the code). The biggest issue
there is that Skins contain many non-public helpers, primarily
their Behaviors. Making Behaviors public would first require
unblurring the lines between what is Skin and what is Behavior
(not doing so will just make it a bad API that will cause many
bugs and problems over the coming years). That would also mean
that some controls need some rework to divide the work over their
Skin and Behavior correctly, as for many controls the split is
there only in name, and is discarded as soon as it was
inconvenient.</p>
<p>With Behaviors public and some helpful API's (like Font
measurement) having a public equivalent, the route to just copy
only a Behavior or Skin opens up. Being able to copy them means
that you don't need to fully open up and specify every private
method in Skins/Behaviors (designing API's is hard, but designing
API's that can be sub classed while not restricting an endless set
of possibilities that a Skin subclass may need is impossible).</p>
<p>--John<br>
</p>
On 08/03/2024 00:40, Marius Hanl wrote:<br>
<blockquote type="cite"
cite="mid:trinity-5e766a67-a319-4538-b267-7180ad8f805a-1709854826237@3c-app-webde-bap43">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div style="font-family: Verdana;font-size: 12.0px;">
<div>One note here regarding that a lot of things are final in
JavaFX:</div>
<div>
<div> </div>
<div>The problem is not that everything is final - this is
intended and makes sense, since we speak mostly of
properties here. Overriding those will not give you any
benefit.</div>
<div>You mostly want to override e.g. Controls if you add
something new to it (a new property) or may just want to set
another default skin.</div>
<div>This design is mostly superior than e.g. Swing, where you
can override things and easily break something if not too
careful.</div>
<div>Pretty sure that this were some lessons learned from the
development of Swing.</div>
<div> </div>
<div>The biggest problem is rather that a lot of methods are
package private or 'Accessors' are used to call specific
methods, which is not just a questionable design but also
restrict the usage.</div>
<div> </div>
<div>It is often not possible to override even a minor feature
inside the skin.</div>
<div>So you may rather want to recreate the skin then, and
copy the existing skin and just change some stuff. But this
will mostly not work either, as there is a lot of internal
API usage, e.g. Accessors or
some com.sun.javafx.scene.control.skin.Utils usage.</div>
<div> </div>
<div>
<div>Want to set the width of a TableColumn? Well, the
internal
com.sun.javafx.scene.control.TableColumnBaseHelper.TableColumnBaseAccessor can
do that, you can not.</div>
<div>Get the width of a text String? Well, you can use
com.sun.javafx.scene.control.skin.Utils.computeTextWidth...</div>
<div> </div>
<div>Offtopic: Maybe we should collect the things which
should be public in our opinion at one point to (better)
get this started as well?</div>
</div>
</div>
<div>
<div> </div>
<div>-- Marius</div>
<div>
<div name="quote" style="margin:10px 5px 5px 10px; padding:
10px 0 10px 10px; border-left:2px solid #C3D9E5;
word-wrap: break-word; -webkit-nbsp-mode: space;
-webkit-line-break: after-white-space;">
<div style="margin:0 0 10px 0;"><b>Gesendet:</b> Montag,
04. März 2024 um 08:13 Uhr<br>
<b>Von:</b> "Robert Lichtenberger"
<a class="moz-txt-link-rfc2396E" href="mailto:r.lichtenberger@gmail.com"><r.lichtenberger@gmail.com></a><br>
<b>An:</b> <a class="moz-txt-link-abbreviated" href="mailto:openjfx-dev@openjdk.org">openjfx-dev@openjdk.org</a><br>
<b>Betreff:</b> Re: Validation Support</div>
<div name="quoted-content">First off, as the original
author of ValidatorFX I feel flattered by the<br>
suggestion of including it into the JavaFX core :-).<br>
<br>
Some thoughts / insights I gained from developing
ValidatorFX:<br>
<br>
* ValidatorFX is (with the possible exception of
GraphicDecoration.java)<br>
rather trivial code and also very small (< 1k lines
of library code).<br>
But it seems to have filled a market gap according (a
few thousand<br>
unique ip downloads every month, issues from ca. a dozen
people so far,<br>
even a few PRs). These "market gaps" get filled rarely
because they are<br>
not a commercially attractive opportunity. On the other
hand if you<br>
decide (like I did with ValidatorFX) to take your closed
source solution<br>
and make it open source, you are "rewarded" by increased
overhead at<br>
first. But the market gaps exist and hinder broader
JavaFX adoption.<br>
<br>
* ValidatorFX is probably only one part needed for
application<br>
developers. The other part is a form library that allows
to layout<br>
fields, have buttons (that are connected to field
validation, etc.). It<br>
looks like this is written again and again by every
application developer.<br>
<br>
* To answer John's question if JavaFX could do more to
help make tools<br>
like ValidatorFX easy to build:<br>
<br>
** There's the TooltipWrapper class in ValidatorFX which
works around<br>
JDK-8090379. Not a big deal but something many
application developers<br>
will probably be annoyed by.<br>
<br>
** On a more general note, if I were the king of the
JavaFX universe for<br>
one day, I would forbid anyone to make classes or
methods final. As an<br>
application developer I prefer to be able to tweak
things easily, even<br>
if they may break in the future (which they will anyway
...). Don't take<br>
that decision away from me, it's patronizing. But I
guess this is one of<br>
those things that depend very much on which side of the
equation you<br>
are, so don't take my troll bait :-).<br>
<br>
<br>
--Robert<br>
<br>
<br>
Am 03.03.24 um 02:10 schrieb John Hendrikx:<br>
> Hi Dirk,<br>
><br>
> That is a very nice framework, and although I
wouldn't be against its<br>
> inclusion in FX, I'm more wondering if JavaFX could
do more to help<br>
> make tools like ValidatorFX easy to build.<br>
><br>
> I'm not quite sure how one can use not having
validation as an<br>
> argument against using FX, when there clearly are
free alternatives<br>
> available. Surely not everything can or should be
part of the base<br>
> framework? A line must be drawn somewhere,
especially when there are<br>
> very few core FX developers.<br>
><br>
> I'd much rather see work being done on things that
can't be provided<br>
> by 3rd parties, preferably by opening up more parts
of FX with well<br>
> specified API's.<br>
><br>
> --John<br>
><br>
> On 01/03/2024 11:59, Dirk Lemmermann wrote:<br>
>> Hi everyone,<br>
>><br>
>> I updated the validation framework ValidatorFX
today in our project<br>
>> to the latest release and I really like it a
lot. It is a small<br>
>> compact API and works with any observable as
opposed to the<br>
>> validation support provided by ControlsFX.<br>
>><br>
>> Using it made me wonder whether it would make
sense to bundle it or<br>
>> something like it directly with JavaFX.
Developers often mention<br>
>> missing validation support as a drawback of
using JavaFX. Adding this<br>
>> would take one item off from the list of
arguments against using JavaFX.<br>
>><br>
>> Many UI frameworks do have built-in validation
support, e.g. Vaadin<br>
>> [0], Angular, [1], or QT [2]<br>
>><br>
>> What do you think?<br>
>><br>
>> —Dirk<br>
>><br>
>> [0]<br>
>> <a
href="https://vaadin.com/docs/latest/binding-data/components-binder-validation"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://vaadin.com/docs/latest/binding-data/components-binder-validation</a><br>
>> [1] <a
href="https://angular.io/guide/form-validation"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://angular.io/guide/form-validation</a><br>
>> [2] <a
href="https://doc.qt.io/qt-6/qtquick-input-textinput.html"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://doc.qt.io/qt-6/qtquick-input-textinput.html</a><br>
>></div>
</div>
</div>
</div>
</div>
</blockquote>
</body>
</html>