Re: Use Elemental to optionally generate HTML on the server?

[Andrea Boscolo]

I'd give CellTable/DataGrid a try, if your model is suitable for it and your cells aren't so 'fancy'. You can use async requests, paging and lightweight widgets (cell widgets); should be more than enough to speed up fetching/rendering time.

There is also the ElementBuilder API that makes easy to create DOM elements from chaining calls in a builder fashion. Checkout some
examples in http://code.google.com/p/google-web-toolkit/source/browse/trunk/user/javadoc/com/google/gwt/examples/dom/builder/ .
One interesting point is that you can use such builders also on server-side (the server-side actual implementation uses string manipulation instead of DOM operations) and send back the generated string to the client (never tried though) http://gwt-code-reviews.appspot.com/1455802/

Also AFAICT Elemental does not work well (or at all) with IE prior to 9.

On Tuesday, October 9, 2012 4:08:56 PM UTC+2, Roy wrote:

I have a large GWT app which unfortunately is slow in some old browsers I need to support (IE7).  A major part of the slowness is my architecture - I am using GWT-RPC to download model objects from the server and then building a large HTML table in the browser using GWT Widgets.  The table is not fancy - just text, links, and images - but it can get pretty big.

I'm considering fixing this by building some of my HTML on the server and then downloading it over GWT-RPC as a string, and injecting it in to the DOM using setInnerHtml().  I will still have to do some manipulation later in the browser though (my UI refreshes periodically in the background).  What I would really like would be to write my code in such a way that I could decide at runtime if it was best to build the table on the server or in the browser.

Elemental looks like a promising way to do this - it would not be hard to generate a server-side implementation of the Elemental HTML interfaces that built up an HTML string, and then send that string over the wire to be injected in the browser.  My application logic would only interact with the Elemental interfaces, so I could decide at runtime which implementation to use.

Does this sound reasonable or am I barking up the wrong tree here? 

[Andrea Boscolo]

I'm using Cell widgets elsewhere but don't think they'll buy me enough here because I can't use paging in this UI - I need to display the whole table.  I'm already loading using an async request.

Even if you don't use paging, it can increase the rendering speed of a basic, say, flext table.

Thanks for the pointer to ElementBuilder.  That seems promising but has some drawbacks - it won't help me manipulate the DOM after it's been created.  Also it seems incomplete - it currently only has builders for <div>, <select>, <option> and styles.  Maybe it's a dead end and is going to be replaced with Elemental?

Well given a builder you can call its finish() method to return the actual built DOM element that can be later reused if stored somewhere, I guess. Also AFAICT the builders are all there http://gwt-code-reviews.appspot.com/1463812 and I don't think it's a dead end, for instance they are used internally in CellTable, they are just another (fast) way to build elements. And they have nothing to do with Elemental.

I haven't tried any of this yet but I assumed that Elemental would work on non-webkit browsers so long as you kept to the DOM they support (i.e. keep to the simple stuff).  Is that not correct?

Elemental is library generated automatically from the WebIDL specs, in particular the WebKit ones taken from the Dart project http://code.google.com/p/google-web-toolkit/source/browse/trunk/elemental/README thus I think they'll have problems with old IE versions (but maybe not with the very very basic stuff like elemental.dom.*, you need to try). Anyway I don't think it will buy you much in the short term.

The IsRenderable/PotentialElement strategy seems another way to singnificantly cut down rendering time, although its "very experimental" state and I've not yet figured out its usage. See https://groups.google.com/d/topic/google-web-toolkit/neeh5YxKm-I/discussion and https://groups.google.com/d/topic/google-web-toolkit-contributors/g8WPRxkdqPA/discussion

Thanks,
Roy

[Gal Dolber]

I'm also very much interested in this.

You can get Elemental to run on pure Java, but it will take a lot of work.

Before Elemental came out I did a very similar DOM abstraction and wrote a pure Java implementation for it as well, to get the tests running.

Implementing a java version of Elemental should be pretty much the same.

Take a look here for the GuitDom java implementation:

https://github.com/galdolber/Guit/tree/master/src/main/java/com/guit/junit/dom

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.

To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/lM1CfZvI2noJ.

To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

--

A world citizen