High performance text component

[Richard Bair]

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