An FXML Browser (topic branched from Re: High performance text component)

[Greg Brown]

> Yea, dynamically generating screens from a database feels like the logical use case but when I sit down and try and map this out I keep ending up with the conclusion that there's no real benefit from 'server side' FXML generation.

I think the benefit would be the same as for HTML - you can change the definition of the UI without needing to deploy a new version of the app.

> Server side HTML generation works because you can leverage the fact that the user already has a browser and can just run your app without 'installing', but for us the user will have to install the jfx browser first anyway. So in that case the 'browser' install may as well be the 'app' install and include the screens (as Java or static FXML or dynamic FXML or whatever).

I'm not sure how much value there might be in a generic "FXML browser", but I can definitely envision a hybrid approach, where some of an app's UI is static and other parts are defined dynamically.

> The server then just sends 'data' (eg json) not FXML to the client and the client updates its views from this data. 

If your UI structure is fixed and only the data changes, this approach works well. However, if your UI is likely to change significantly over time, FXML might be a better option. Since JSON is primarily a data transfer format, you'd end up having to encode your UI structure using JSON primitives. For these cases, dynamically generating FXML might be a better option.

> I think this is really powerful and a forms/reporting framework based around this that could be plugged into an app would be super useful, and is an awesome idea (something like JFX survey monkey).  

Right - this is a good example of what I'm describing above.

> Personally though I don't see this as a pattern you would use if you knew the screen structure up front, which is the standard 80% case.

Agreed. However, it's nice to have the option of using server-generated FXML for the remaining 20% case.