High performance text component

[Daniel Zwolenski]

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?

I think that would be pretty useful but I do think the layout 'constraints'
(in particular things like inline, baseline, padding, margin) will have to
be sorted out to make it useful.

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

Since we've now touched on this idea of a 'page-based' UI, I want to run
something past you.

Currently in web-land we get a 'DOM' from the server (i.e. a 'model' of the
document) sent down to the browser. This model is more or less a legitimate
model (i.e. the actual view/display is not constructed until its shown) so
it is light enough that for every 'page' the browser can download and
render it, surprisingly in a fairly responsive way. When I then navigate to
a new page, the whole scene gets thrown away (as far as I can tell) and the
new one is built and displayed. When I hit the back button it reshows the
previous view again based on the old DOM (which was cached).

There is something to be said for the resulting UI page-based pattern and
the simplicity of it is part of why web development is so popular. I've
wondered before whether it would be possible to achieve something similar
in JFX, especially in the context of FXML.

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.



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

> Actually, it is a *lot* simpler than you fear. (brought the subject back).
> It isn't a DOM in the HTML sense, but more in the generic sense, I guess
> the name in the WIKI title is confusing.
>
> When we say DOM, we mean in the generic sense of some object model that
> represents your text. The alternative is the programmatic attributed string
> approach, where you have a StringBuffer type object and you tell it which
> ranges of characters have which attributes. The DOM approach instead uses
> the Scene Graph as the document object model.
>
> Just to be abundantly clear, we're NOT talking about the HTML DOM in any
> of this. That document object model has a whole lot of subtle differences
> such as event handling etc, and there is no way we're going down that road.
> SO when Felipe says "DOM API", what he means is, we're using the Scene
> Graph to model the text, and not an AttributedString style API.
>
> Felipe, we should update the documents on the WIKI to refer to the "Rich
> Text API" instead of DOM API because I fear this can get confusing! Other
> than those of us internally who have argued for / against the Attributed
> String style vs. the DOM style, most people probably won't get the
> subtlety, having missed the context.
>
> > First reaction is why do we have two things a "Scene Graph" and a "DOM",
> why not just one. Also "laying out" will inevitably creep in here for 'rich
> text' if you go down this road (see 'overflow: hidden' comment below,
> what's next, 'padding', 'height', or shudder 'position', 'float', etc).
>
> There is only the SceneGraph. Everything is in the scene graph. My current
> favorite as far as the proposal is to introduce 1 new node class, lets call
> it Paragraph. It is like a DIV in HTML (but not a DIV, hence a different
> name), and it contains all Text nodes, and can handle any other type of
> node you throw in there.
>
> So for example, I'm taking Sample 1 from Felipe's Samples WIKI
> https://wikis.oracle.com/display/OpenJDK/DOM+API+Samples, but modifying
> it for my current feelings on the naming and such (since we have to pick
> something, and for the sake of this I want to avoid DIV / SPAN since that
> has specific HTML connotations).
>
> @Override
> public void start(Stage stage) throws Exception {
>     String family = "Helvetica";
>     double size = 20;
>
>     Paragraph p = new Paragraph(40, 40);
>     Text hello = new Text("Hello ");
>     hello.setFont(Font.font(family, size));
>     Text bold = new Text("Bold");
>     bold.setFont(Font.font(family, FontWeight.BOLD, size));
>     Text world = new Text(" World");
>     world.setFont(Font.font(family, FontPosture.ITALIC, size));
>     p.getChildren().addAll(hello, bold world);
>
>     Group group = new Group(p);
>     Scene scene = new Scene(group, 500, 500, Color.WHITE);
>     stage.setTitle("Hello Rich Text");
>     stage.setScene(scene);
>     stage.show();
> }
>
> So as you can see, the "document object model" here is just the scene
> graph (there are many DOMs in the world, Bilbo, and none of them should be
> used lightly!).
>
> The Paragraph node is just a very specialized layout container, which
> knows how to layout text nodes properly. Felipe, can you add a sample of
> complex text and show how that works? That really motivates the complex
> scenario that cannot just be handled by a FlowPane with text nodes. Another
> case is where you break at the word boundary for line breaking, but the
> word being broken is in a Text node (such that part of the Text node is on
> one line, and part of it on the next). All flowing and working with complex
> text. That's the work of the Paragraph node and why we need an additional
> node beyond FlowPane.
>
> I can definitely see in the future people wanting to add more web layout
> functionality (flowing text around an Image, for example). We will have,
> for example, padding and borders and such by virtue of using Region (which
> supports these things). I would be cautious about adding overflow controls
> and such, although it is certainly possible, it would require us adding a
> new NGParagraph node type so that we could handle it without modifying the
> scene graph (the user might have their own clip on Paragraph, and so we
> cannot set the clip on the Paragraph itself but would have to handle it
> further down), and I certainly wouldn't want Paragraph to require a
> ScrollPane (breaks our modularity).
>
> And although I feel that at some point in the future we will inevitably be
> drawn into more complex layout support (flowing text around Image!), it
> doesn't have to go that way and certainly by choosing names other than Div
> and Span we can emphasize this is something different.
>
> > Your comment:
> > > which might make sense in some document heavy scenarios
> >
> > A webapp (even the richest of rich) is a 'document heavy scenario', i.e.
> all things can be seen in this category, where's the line (lessons from the
> web would say there isn't one).
>
> 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 think I need to digest a little more though, this feels like a
> fundamental change in the way things could/should be done.
>
> I don't think so, I think some people might prefer the document approach
> and go crazy with it, but I expect for the most part Paragraph and Text are
> used for rich text scenarios, including scenarios where you are embedding
> images and such in the rich text.
>
> Cheers
> Richard