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

[Mark Fortner]

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.

Riffing on your idea, I wonder how difficult it would be to have support
for different scripting languages?  Imagine something like Maven that can
download language support or other plugins from a trusted server, and cache
them locally.  Who's to say that a controller couldn't be a simple script?

Cheers,

Mark




On Sun, Sep 2, 2012 at 6:27 AM, Daniel Zwolenski <zonski at gmail.com> wrote:

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