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

[Daniel Zwolenski]

On 04/09/2012, at 9:23 PM, Greg Brown <greg.x.brown at oracle.com> wrote:

> Can't speak for Rich, but I have been thinking of something along the lines of #2. I can imagine a system where FXML is generated from database tables (or other structured data repository) for example.

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. Which I feel like is the implied setup that you guys are hinting at?

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). The server then just sends 'data' (eg json) not FXML to the client and the client updates its views from this data. 

Currently this is what most people would be doing though (it's the pattern that my blog walks through) and is the fairly traditional desktop client-server approach. 

So then if we drop out 'server side' FXML generation then I really like the potential of 'client side' fxml generation using a templating engine. This is basically option #3 and if there's no compelling reason to base a ui around server-side FXML then this client-side fxml generation option is probably the one I'd be inclined to explore further. 

> Another possible scenario is a form authoring tool (for example, for internal corporate apps). The forms would be stored on the server and loaded dynamically by the client. The logic for the forms would be implemented in script code rather than a compiled controller so it could be updated easily, like HTML.

Yea, dynamic (ie user customizable) forms are a good use case for the server to dish up raw FXML (I actually did this for some customizable 'report' screens). This seems mostly useful when you don't know your screen structure at build time (ie they are configured and edited at runtime), such as for custom forms and reports. 

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).  

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. For your bog standard app you'd just build your screens rather than making them dynamically customizable at runtime. 

All good thoughts to have in the mix. I just keep bringing it back to how I would use this in a real app. I'm currently designing a web based one which is very much your bread and butter business/data/forms webapp. 

The company I'm with is tech/innovative enough to be open to JFX if I could demonstrate a clear win over webapps. So I'm basically trying to work out how to sell jfx over webapps. Currently I have to admit that webapp still wins, but elements of this discussion are certainly adding areas to explore for more competitive edge over web.