Skins vs FXML

[stefanofornari]

Hi,
I'd be interested to know what are the design decisions for the Skinning mechanism in MaterialFX? in particular, why there is no use instead of FXML?

The current implementation put a lot of UI and controlling stuff in the Skin classes which is something I find not very clean nor handy. To tell the true, even new languages like dart/flutter seem to take this route, so you are not alone.

However from a user perspective (a developer that wants to develop an app on top of the framework) I found quite difficult to understand the behaviour of the complex controls. And above all, even to just reshape a dialog you need to write code, while instead it would be super easy with FXML.

many thanks in advance.

[palexdev]

FXML is very very slow. It uses reflection to create the actual views. In some cases, heavy uses of FXML could cause some serious performance issues. Now think about a GUI framework, controls, widgets and so on are to be used in large quantities (not all the time, but a big UI is not unusual), they need to be created and disposed fast, FXML is not the best idea.
For an app (so the user pov), FXML is more than fine.

[stefanofornari]

What you say make sense, in particular for the basic controls (I mean single elements like MFXButtons and even MFXTables) because they may actually be used to build a UI where performance is critical.
Don't you think that instead for composite elements like dialogs the benefit in terms of performant does not compensate the customization effort? I am thinking about MFXFillterDialog for example. In this case the performance gain is clearly negligible with even pretty old CPUs.

[palexdev]

It's true for components like table views, but for buttons FXML could actually be fine since there's just one element

Dialogs are definitely a no go for FXML, especially common ones that need to be used frequently.
Also, there would be two performance issues for dialogs, the FXML loading and the Stage creation.

In MaterialFX you can do it though. MFXStageDialog allows you to use an FXML view as the content

[stefanofornari]

Dialogs are definitely a no go for FXML, especially common ones that need to be used frequently.

Why do you say so? what's the difference from a user perspective between loading a dialog in 100ms without FXML and 500ms with FXML? (numbers totally random, but you get the isea) Plus, in a particular situation where you are really concerned about the performance of building a dialog you could cache it, FXML or not. But I would say that if you have a performance problem with the appearance of dialog the bottleneck is surely not due to FXML and you should review your design.

In MaterialFX you can do it though. MFXStageDialog allows you to use an FXML view as the content

indeed, but this not the point, because I would like to easily reuse what the framework provides rather than reinventing the wheel.

[palexdev]

If you aim to build a responsive UI then you want to avoid those delays. As I previously told you, for dialogs there's yet another performance issue which is Stage creation. I've yet to see a case for which using a dialogs on the go doesn't make the UI thread lag, this is a big downside of JavaFX dialogs. In fact what I prefer to do usually is to have one and only MFXStageDialog for everything and then just change its content.

Yes, you can cache it if the dialog is always the same and it's built to be reusable. But that's not the responsibility of the framework, app specific dialogs are dev's responsibility.
In such case I can suggest to make your dialog in FXML, load it at startup on a background thread, store it somewhere (cache it), then use it in a Stage (MFXLoader is an example) .

[stefanofornari]

As I previously told you, for dialogs there's yet another performance issue which is Stage creation. I've yet to see a case for which using a dialogs on the go doesn't make the UI thread lag, this is a big downside of JavaFX dialogs. In fact what I prefer to do usually is to have one and only MFXStageDialog for everything and then just change its content.

I am not questioning the separation of MFXStageDialog and content, that is fine, and it is a different story. I am talking about the content of the dialogs provided by MaterialFX. Take MFXTableView/MFXFilterDialog as an example. In order to make even simple changes to the UI I have to deal with the code. If they used FXML instead, I could just tweak those with no, I am sure, noticeable performance impact.

Yes, you can cache it if the dialog is always the same and it's built to be reusable. But that's not the responsibility of the framework, app specific dialogs are dev's responsibility.

I think it is for the dialogs provided by the framework.

[palexdev]

Then please describe to me what you are trying to achieve
If an improvement can be done on the dialogs API I'm more than happy to implement it

But. FXML is out of question, I rather prefer to offer it as an alternative, meaning that the use can use it if he wants but it's not the default framework's path

[stefanofornari]

Please see #255 , it should be enough to get the use case. If we had the FMXL for TableView and MFXFilterDialog we could already work around some limitations applying the styles directly in he FXML instead of creating a new table view just to create a new skin which would be a copy of the MaterialFX one.
But more in general, let's say I want to change the layout of the MFXTableView for example to move the filter icons somewhere else; or more importantly change MFXFilterDialog to be harmonized with my app. If I had the FXML, I could simply hack it in a blink without coding and without changing/breaking any controlling code.
Let me know if it is not clear.

[palexdev]

We have to separate two issues here:

1. Layout customization
2. CSS customization

For the first one, there's little I can do. If you want to change the arrangement of things, the proper way is to learn to create skins and make your own.
Also, if you want to create a skin more easily with FXML, can't you already do it? I think you just need a "fake" skin class which will load the FXML as it's "root" and then override the control inline to use the custom skin. Something like this...

public class FXMLSkin<T> extends SkinBase<MFXTableView<T>> {
    public FXMLSkin(MFXTableView table) {
        Parent root = // Load FXML
        getChildren().setAll(root);
    }
}

MFXTableView<?> cust = new MFXTableView<>() {
    // Here override the createSkin method to use the above one
    // Or make a new class if you do not like inline override
} 

For the second one, I'm well aware of the issues caused by CSS. This is one of the reasons for which the next major version of MaterialFX won't use the "getUserAgentStylesheet()" method anymore, and will implement a Theming API. For the time being though, it is what it is, it's a JavaFX issue, not much I can do to fix it

[stefanofornari]

I think we are going in circle now, so I'll note your point, you are the boss here, after all! :)

I was not looking for workarounds, indeed I know I could do what you say above (and I found my workaround already ;) ). Just in case you want to give it a thought, if you give up on the messy skinning approach and you provide FMXL for TableView and FilterDialog, you kill the two birds with one stone ;).

Thanks anyway for taking the time to answer my questions and keep up he great work!

[stefanofornari]

For the second one, I'm well aware of the issues caused by CSS. This is one of the reasons for which the next major version of MaterialFX won't use the "getUserAgentStylesheet()" method anymore, and will implement a Theming API. For the time being though, it is what it is, it's a JavaFX issue, not much I can do to fix it

Thinking about it... if you accept an advice, don't do it, you have already a lot on your plate. Just get rid of getUserAgentStylesheet and keep CSS styling which is an established pattern for users of the framework.

[palexdev]

I never said I'll get rid of CSS, I just won't use that damn bugged thing which is "getUserAgentStylesheet()" ;)