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

[John Hendrikx]

  I just wanted to add that in my application I'm already using quite a 
lot of dynamic content that is added/removed to/from the scene when the 
user navigates somewhere (specifically, information about the currently 
selected item, including about 10 images) -- apart from having to be 
careful to not leave listeners/bindings around, this approach performs 
great (<100ms).

Since the content can be created by various sources and needs to mesh 
together, I even constructed a special Pane, that I call AreaPane, in 
which one can define named areas (like "primary" "bottom", "title", 
etc.).  The various sources can then drop controls in these areas (with 
a double indicating sort priority) to construct a dynamic information 
pane.  This is really nothing more than a call to lookup() + a 
WeakHashMap that tracks the sort order of each component to put it at 
the right child index.

I was initially worried the Scene might flicker or something when it is 
altered in this kind of fashion, but surprisingly it looks solid, and 
the change is instant.

Anyway, I saw some parallels with the approach you outlined below (which 
is highly interesting) -- it makes me think I perhaps should have used 
FXML for this content meshing I'm doing in my application...

--John

On 2-9-2012 15:27, Daniel Zwolenski 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
>>