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

[Daniel Zwolenski]

So this one has me intrigued. I sort of assumed that building a Scene per
page and throwing it away (or worse just removing it from the scene but
keeping it in memory) would be way too heavy a thing to do in desktop land.
But then I guess that's what Chrome, Firefox and IE must be doing, so why
can't we.

This does kind of open up a whole new set of pathways for doing what Flow
is trying to achieve and here's a bit of random, thinking out loud.

As an experimental starting point, I've just knocked up a very crude (one
class) 'FXML Browser', which basically can browse FXML files from the web,
much like Chrome browses HTML files.


http://code.google.com/p/jfxee/source/browse/trunk/jfxbrowser/


I've ignored the 'controller' aspect for now, and just done a bit of a hack
where I scan the built Node for any 'Hyperlink' elements, and then I use
the 'userData' attribute to hold the URL (i.e. to act like the 'href'
property in a web anchor). When the Hyperlink gets clicked, the Browser
navigates to the new URL and shows that (i.e. builds a new scene from the
new FXML). The previous page (i.e. node) is removed from the scene but
cached in a list so the 'back' button can reshow it without loading (i.e.
just like a web browser). I'm sure we could do something similar with a
'form' concept - effectively achieving the entire web experience (minus
JScript) without touching controllers at all.

Remarkably simple and nothing to it really. Are you telling me that
navigating loads of 'pages' (i.e. FXML files) in this sort of fashion
shouldn't be a problem and the Scene graph is basically designed to handle
this? All I do is remove the node from the Scene graph, I don't have to
manually tell it to release any resources or anything like that?

I've uploaded two hardcoded, dumb FXML files to my server just for testing
(the above code will open one of them on startup, which then links to the
second page).

http://zenjava.com/demo/browser/fxml/hello-world.fxml
http://zenjava.com/demo/browser/fxml/another.fxml


Obviously there would be nothing stopping the Browser from pointing to a
dynamic webapp such as a SpringMVC one that generates FXML instead of the
normal HTML. Basically achieving the exact same experience we can get with
HTML-based web-apps right now, it's just that the display is FXML (instead
of HTML) and the browser is a Java one (instead of Chrome/IE/Firefox).

I'm not too sure what I want to do with this yet. The 'controller' side of
things would be the obvious next bit to work out, which means getting into
the classloading side of it. I guess it's conceptually the same as a web
browser loading a JavaScript file when the page loads - a direct mapping of
this would pretty much be a separate classloader for each 'page'. Not sure
that'll scale in a proper Java environment (but maybe). Alternatively maybe
some sort of application boundary - where all URLs within the same context
share a classloader which is loaded once.

I feel like this could all be valuable but I'm not sure a raw FXML browser
like this would be the actual target solution. Maybe. But the web has been
moving away from server side stuff to 'rich clients' with AJAX, so a more
inline solution could be for the server just to send down data (e.g. as
JSON) and for the client then to do the template rendering, i.e. pass the
data through a template to generate the page to build and then show the
Node. This would allow the client to not be so totally constrained by the
'page-based' structure and instead use the generator to throw away and
re-assemble sub-sections of the overall view (i.e. very much like AJAX).
Perhaps the sweet spot between the web's page-based approach, and the
desktop's normal monolithic UI paradigm.

I think I'll mull over this for a while but if anyone wants to throw in
some comments, feel free.


On Fri, Aug 31, 2012 at 11:39 PM, Richard Bair <richard.bair at oracle.com>wrote:

> Hi Daniel,
>
> Ok, so really we're just talking about a new type of layout pane than has
> a concept of lines and wrapping as part of its layout algorithm?
>
>
> Yes, exactly.
>
> > That is true, although I think that is also why people who hate
> programming for the web hate it so much -- it tries to see the entire world
> through
> > the lens of a document, when really that only covers some of the use
> cases. But in our world, you can put a full TabPane or other layout
> container
> > in the Paragraph, or vice versa, as your mood or fancy or use case
> requires. But really Paragraph exists not for laying out the entire
> application, but
> > for rich text scenarios. Word allows you to embed graphs and tables, we
> need to allow for the same.
>
> I agree with your conclusion but I'm not sure the 'page' concept is what
> people hate about web programming (or at least its not my main gripe). For
> me the big, big problem is that layout management doesn't really exist and
> we have to use CSS, which is just not built for it as well as all the
> horrid cross-browser compatibility issues (and then the fact we have to use
> untyped JScript to do anything dynamic with the page). Your combination of
> 'Paragraph' layout and the normal desktop-like layouts does sound like the
> best of both worlds (without cross-browser problems and with real Java)
>
>
> No, the page concept I think is wonderful, when what you are doing is a
> page. But when what you are trying to do is a traditional application UI /
> desktop layout, then it is fighting against you (as you mentioned above).
> That's what I was getting at. You basically have two layout metaphors --
> grids and flows. For flows, text based flow (ie: HTML) works really well.
> For grid like layouts, traditional layout managers (hbox, vbox, grid,
> contraint-based, whatever) work really well. Unfortunately HTML tries to
> treat everything as a nail 'cause all it has is a hammer.
>
> Would it be possible (i.e. performant/practical)  to do something where we
> use a templating language (I've just been using google-closure-templates
> instead of JSPs and it's pretty nice, but any templating language would do)
> to generate a scene.
>
> So we would have a template like:
>
>     <Group>
>         <P styleClass="paragraph">
>             <Span styleClass="span1">{$myTitle}</Span>
>             {foreach $thing in $list}
>                 <Button text="{$thing.name}"
> onAction="handleButtonClick({$thing.id})"/>
>             {/foreach}
>             <Span styleClass="span3"> World</Span>
>         </P>
>     </Group>
>
> And then in my code I get my data from the server, run it through this
> template and end up with my Nodes (the onAction/binding side of things
> might run into problems, but let's not worry about that just yet).
>
> My question is really how 'heavy' is the current scene graph. Can I create
> and dump 'pages' as casually as a Browser does - is there a way to keep the
> 'model' of the page (so I can go 'back' to it) but detach it from the scene
> and have all the rendering resources get freed up and the re-attach it? Is
> this a practical option or is there any viable way to do something like
> this?
>
> I feel like there's an application structure option here that could take
> the bits that work from web land and combine it with the bits that work
> from desktop land. This would suit the typical "web form " style of
> application. Currently the closest I've been able to get is JFX Flow but it
> could be a lot better.
>
>
> Absolutely, this application strategy was designed for from the get-go. We
> just don't have a reliable way to host a web server (you wouldn't believe
> it, but it is true) so we haven't developed applications that do this
> ourself, and nobody else has yet given it a go. There may well be issues
> with it once it is attempted, but all the main architectural / structural
> bits are in place and it should work, and like I said this style of thin
> client was planned for from the start (and FXML was explicitly designed for
> such a case).
>
> Cheers
> Richard
>