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

[Daniel Zwolenski]

So I'm still puzzling over how to make good use of this.

We *could* have an FXML based browser that basically replaces the Internet.
You browse around add-hoc FXML pages via casual URLs (like browsing HTML).
Like with web pages these could be written by anyone (i.e. not just one
app) and each page would come with its own code (controllers etc) that runs
(like JScript) on just that page (with all the security problems that come
with that). But why would anyone want to use this browser instead of a
normal web browser?

We *could* have some sort of application framework where your local
application has all the controller code already bundled into it, but then
calls out to a server (i.e. a Servlet or SpringMVC style page generator) to
dynamically render FXML page content which then gets downloaded and shown.
Why do the rendering on the server though? Since you'll have to have the
controller pre-bundled with your code (or downloaded jnlp-style). What's
the advantage of then having dynamic server-side 'pages', why not just
download these (or the templates for these) with the Controllers? Maybe
there's some merit in the 'browser' effectively being a thin 'app launcher'
but then you'll still have to install the browser in the first place so why
not install the app as well and use Auto Updating to get updates.

We *could* just use this 'browser/page' style UI approach on the client,
where all the code (controllers and fxml/views) are already installed as
part of the app. The 'page' approach is just a simple way of doing in-app
navigation between screens - i.e. like Flow does now but using this 'build
a new scene for every page' approach (currently Flow reuses pages) to make
it a little nicer. Potentially a templating system (like Velocity or
google-closure-templates) could be used to generate FXML screens based on
data (which could be pulled from a URL/database, etc). This would make the
programming experience simpler (like web programming), so each page is
rendered much like a JSP is, but all on the client side. This is all just a
local ui-design-pattern though, not really any kind of remote browsing as
such.

I feel like maybe Richard and Greg are hinting at features in JFX/FXML that
have been included specifically to allow for things like the first two
options above, and these things do 'feel' like they could be useful. I'm
struggling to work out concrete, real-world use cases for them though. The
third option is just a better implementation of Flow and if I get another
client wanting to do JFX, I'd probably use this approach - it's not really
the 'next generation of browsing though', just a UI style and coding
pattern that helps make nice client side apps with good usability and
simple code.

If we decided to unleash the power of the FXML browser, what, if anything,
would we do with it?



On Mon, Sep 3, 2012 at 9:39 PM, Greg Brown <greg.x.brown at oracle.com> wrote:

> > Actually that's what I originally thought FXML was for.  It was only
> later
> > after I started using FXML that I realized it wasn't the case.  But it
> > strikes me that FXML could be used like Flex -- a downloadable scene
> > specification.
>
> Are you suggesting that MXML files can be processed dynamically? I thought
> they had to be compiled first, but maybe I'm mistaken.
>
> In any case, yes - FXML files can be used as a downloadable scene
> specification.
>
> > Riffing on your idea, I wonder how difficult it would be to have support
> > for different scripting languages? … Who's to say that a controller
> couldn't be a simple script?
>
> This is already supported. You can use any JVM-compatible scripting
> language to define the logic for an FXML document.
>
>
>