Lou Hamers

Also:

It's a good idea to specify the generic type of the ComboBox. It helps the IDE's autocompletion in addition to adding compile time type safety. Yours might be ComboBox<String> but maybe ComboBox<Integer>.

And a nitpick, your naming convention is too snakey (horrible Python-ish underscores! haha):
tab_extract_info_cbo_Extract_Type
is normally lowerCamelCase in Java:
tabExtractInfoCboExtractType
(which I would try to also shorten if you can, ex. extractTypeCbx) (and don't forget to change the fx:id in the .fxml to match so your @FXML injection still works)

I don't think what you've provided has enough context to determine what's happening. Maybe something focus related you're doing elsewhere. Are you binding the value of the ComboBox to OC's extractType value or something (which changes on focus...)?

I wouldn't use a focus listener anyway. I would instead watch valueProperty. (Although there are other options too.)
       cbTest.valueProperty().addListener((observable, oldValue, newValue) -> {            //Do something with newValue which would be an Integer in this case        });                //This is the expanded non-lambda version which is more verbose but clearer        cbTest.valueProperty().addListener(new ChangeListener<Integer>() {            @Override            public void changed(ObservableValue<? extends Integer> observable, Integer oldValue, Integer newValue) {                //Do something with newValue            }        });
   //Just to show context    @FXML    ComboBox<Integer> cbTest;    cbTest.setItems(FXCollections.observableArrayList(1, 2, 3, 4));
If you're still stuck, what are you initializing the ComboBox with? I guess it's a list of Strings containing numbers? I used int (autoboxed to Integers) above but it's basically the same.

What was happening with the bind() line is the tags (InputFields) had their preferred height following the overall container itself. Which I'm pretty sure you don't want to do.

Not sure if this is exactly what you have in mind, but it does seem functional:

Try removing this line at 115:

inputTextField.prefHeightProperty().bind(this.heightProperty());

And line 67, go back to FlowPane:

public class AutocompleteMultiSelectionBox extends FlowPane {

Still testing but I was surprised to see that it looks like it's pretty close to reasonable behavior (I didn't think it would be that easy to get such a result).

No problem - it'll take a little bit to go through the code to figure out what it's doing.

A quick test in Scene Builder to see how a FlowPane reacts to TextInput children seems to indicate that it does do what you want "by default". The problems look like 1) styling (solvable for sure) and 2) automatic width sizing of the TextInput (this could be tricky with that component).



This code does make it act strange big time though. Every letter I type in a new tag makes the tag heights grow, but then they right-size again. And row 2+ TextInput heights kind of go crazy. So yeah, I'll take a closer look...

I'll have a look at it! I haven't actually used FlowPane before but I imagine that'd be your best container.

What's probably happening is just the automatic sizing of your containers isn't defaulting to decent values, so we probably just need to set some specific max/min/preferred sizes.

If you want to drop your css in here I'll use that to get a more similar look. But regardless I'll take a look at the code here...

I don't know if front end framework recommendations are very useful without first laying out what your priorities are (even then it's hard to get non subjective answers). Since we're discussing hiring I'm assuming the OP isn't the actual lead dev.

So if "faster for development" is the only criteria, I would say you don't choose a framework at all! You should just ask the developer(s) what they already know or prefer. (And hopefully they agree, otherwise let the lead be the final decider since they're the most accountable.) That said there might be situations where you want to veto the decision, if they want to try something "new and innovative" which is way out there and clearly risky. But this is unlikely if they know the sword is going to fall on them first for making a wild decision.

Reasoning:
If it's something they already know and like, obviously they'd be quick at using that. If they're wanting to try something new, they're probably still going to be more efficient than had they been forced to use something they don't want to use, because they'll be far more motivated to learn and succeed at the new thing they chose. Not to mention, their reputation is on the hook if they were the ones who selected this thing and it fails.

------
That concludes my own reply to the OP but I couldn't help but write an addendum section:

https://svelte.dev <-This is what I've been hearing about lately. It's supposed to be faster than both of those. Finding developers who know it already would be harder obviously, but IMO an experienced developer should be able to pick up a new JS framework fairly quickly. The front end ones should be used to doing this every other month anyway.  

Also I'm disappointed that nobody ever seems to mention https://vaadin.com . They appear to have a very efficient workflow going for them and the fact that you're doing most of your UI coding in Java is great when the same developers are also supporting a Java backend. I assume it's because most web developers are hipster types addicted to always using something "new" (which usually isn't really especially new) and would never prefer a mature, stable language like Java, just because it's old.

I think that's what the entire industry is just like Tim. It's pretty annoying too. The frustrating thing for me sometimes is that sometimes the details that are overlooked aren't even hard to address.

I'm a little bit of a code quality geek and I guess there's some OCD in play when I see sloppy code. Misspellings, horrible naming, copy-pasted junk, not even bothering to auto-format, pointless interfaces seemingly just to use an interface, "helper" and "impl" classes all over, useless obvious comments that add no value. (Comments on trivial getters and setters really trigger me.)

Oh man, I could go on and on. Y'all think I got a problem? lol

Oh I didn't get the impression HH was saying this is more secure or a security silver bullet - just less complex. And of course using a JWT has a lot of benefits as Tim already spelled out above so I won't repeat.

Stephan van Hulst wrote:
CSRF attacks are possible any time the browser can be tricked into submitting user credentials automatically. This is true for a JWT stored on the client side the same way it is for a session cookie. It just depends on the way you handle your JWT.

For instance, if you authorize your requests by putting your JWT in a cookie, you're still vulnerable to CSRF attacks.

"So I just won't store my JWT in a cookie then!" you might say. Well, you need to store the JWT somewhere, and most of the other options are vulnerable to XSS attacks. That means you've just moved the complexity of securing your application from the back-end to the front-end.

No cookies? No problem - cut the browser out entirely and store your JWT in the memory heap of your JavaFX application! lol

But seriously, yeah I was under the impression this was more about one of the advantages of stateless REST, not that it's better security. Unless I missed something. You won't get any disagreements from me saying there isn't a such thing as a silver bullet for flawless security.

...Well, maybe quantum encryption would be decent. Still doesn't protect you from a basic keylogger. Or the old "look over the guy's shoulder" trick. Or phishing...

Actually just to get conversation going... I've been under the impression that stateless REST is typical or even "favored" these days. Is that not the case?

Especially with cloud and microservices tearing through everything... Something which I advise taking with a grain of salt, but as for stateless/sessionless applications in general, I'm a fan for sure.

Did you figure this out? I'll be honest and confess, although I do use Scene Builder a lot for JFX UIs, I don't really do much (if anything) with custom components in Scene Builder. Generally it's too much hassle and you don't get much in return. What I'll do instead is use Scene Builder to configure a container that a custom component will go into, and then I'll create the custom component in code, adding it to that container at runtime.

If you still REALLY want to get this working, you could try loading some open source 3rd party libs into Scene Builder, and then take a look at how they created the components in their repo. ControlsFX for example is one you could try. (I suspect the 2nd video shows how to do that but it looks like that video is gone now...)

From my own experiments messing around with it before, it seemed like simply pointing SB to any jar, it would magically just find some "components" to add. I never looked into how that works - maybe it's just auto-detecting anything that inherits from Node or something like that.

That code you have above might just work if you point scene builder to it. Just find the jar that it's creating after you do a build and try loading it in SB. You might need to re-create ToggleSwitch as a regular public Java class instead having it private and inline like that, though.

I'd prefer a JavaFX client application (haha) but I generally agree with the concept of using stateless REST, yes.

I started a more elaborate reply before I saw the age of the first post and realized that the OP is probably an expert by now. I guess 4 years late is better than never! Don't think I was active back then or I'd have definitely replied.

We do need some new blood injected in here, are visitors not posting because it looks inactive?

Thanks for the activity though Victor. Good to see new JFX users around.

I've done that kind of thing but I would say it depends highly on how formal everything is expected to be run, how high visiblity it is (are you having to do weekly status presentations to management or something?), how large the project is, how much guidance and oversight you need to put on the rest of the team, and so on. It's fine if you're energetic and that stuff isn't too crushing. A little harder as you get older...

If the load is too much, something's going to suffer. Whether that thing was essential and will turn into a "problem" down the road.. is additional risk and guesswork. Yeah I'm pretty much +1'ing the above.

It's not often we get a real JFX question here lately. Imagine my disappointment to see this is a 6 year old thread that's already answered! lol (We need to get some new recruits in here...)

Anyway, there's usually a few ways to do this depending on what you're working with (in terms of desired behavior). I didn't bother carefully reading the older posts above but this is my take on it.

Adding a spacing property to your container like you did is one way, but if the container can grow larger, the buttons will stay too close (well, you may actually want that, but let's say you want to evenly space them even if the container grows).

What I often do is add spacer Panes. The Panes can be set to grow with the container's size AND will size themselves relative to the others. You can also use other containers like I did here for the middle spacer, but if I don't need VBox/HBox functionality I usually go with Pane, guessing that it might perform a bit better (I never looked into that).

<HBox alignment="CENTER" prefWidth="444.0" xmlns="http://javafx.com/javafx/21" xmlns:fx="http://javafx.com/fxml/1">   <children>      <Pane HBox.hgrow="SOMETIMES" />      <Button mnemonicParsing="false" text="Button" />      <VBox HBox.hgrow="SOMETIMES" />      <Button mnemonicParsing="false" text="Button" />      <Pane HBox.hgrow="SOMETIMES" />   </children>   <padding>      <Insets bottom="8.0" left="8.0" right="8.0" top="8.0" />   </padding> </HBox>
Padding and other HBox attributes added for fun (it make the preview look better in Scene Builder).

The HBox.hgrow attribute is key here. There's also ALWAYS, NEVER and INHERIT (default). Definitely play with this stuff in Scene Builder, you can get a live view of how it works (and even an interactive preview with the Preview menu), and it'll show you a lot of the different tools you have to "make it do the thing" that you want it to do. It's interesting how much you can do with just a combination of HBox/VBox containers and a few of these settings.