Generalizing GWT bootstrap to support SVG

[Archie Cobbs]

Advice needed...

We are starting to experiment with moving some of our current product into the browser using GWT. Currently it's a Swing-based Java application that uses the Apache Batik library for rendering SVG. Our experiments involve rendering SVG inside FireFox, and using GWT-compiled Javascript to animate that SVG. Initial tests are promising but have also brought up some issues with our using GWT in this somewhat unorthodox manner, and I'd like to get some expert opinions on how to proceed.

To clarify the motivation here, here's an example: Batik provides a standalone SVG browser (called "Squiggle") that works just like a web browser, but renders SVG documents instead of HTML documents. SVG defines a <script> tag just like HTML, and so you can embed JavaScript inside SVG just like you can with HTML. This all works fine in Batik: you have the entire DOM reflected into JavaScript and you can do all the usual DOM operations, capture mouse events and so on to create animations, interactivity, etc.

Now suppose you want to write the animation code in Java and use GWT to compile it into JavaScript, because GWT provides the only sane way to manage a large body of such code... hmm....

Well this is just the same problem GWT already solves, only with "HTML" replaced by "SVG", and "(some set of supported HTML browsers including FF, IE, ...)" replaced with "(some set of supported SVG browsers including Squiggle, FF, ...)". You can see where this is going...

JavaScript is of course independent of HTML and so it would seem a big shame if GWT's compiler only produced JavaScript that could run in a web browser and assumed an associated HTML document. Fortunately, (as I understand things) the browser-specific " cache.js" files that GWT generates have nothing inherently HTML-specific about them (unless of course you are compiling Java files that themselves assume HTML). They are for the most part a straight conversion of your Java classes into JavaScript, whatever those classes may be.

That's great.. we're most of the way there, but this still leaves a couple of remaining problems:

1. The GWT bootstrap "nocache.js" script is very HTML-specific (e.g., it uses document.write ())
2. GWT's DOM implementation is HTML-specific; something else is needed
   

(By the way all of this applies analogously to XHTML or any other type of XML document, e.g. Firefox's XUL: if you were writing Firefox extensions, wouldn't it be nice to be able to use GWT?)

So I've started going down this road...

For #2, I've written a (partially complete) "wrapper" DOM implementation that implements the org.w3c.dom interfaces by simply wrapping the browser's underlying DOM implementation (this is tedious but fairly straightforward). This seems to work well and allows the Java code to program to the normal org.w3c.dom APIs (including specialized APIs like org.w3c.dom.svg), utilize XML namespaces, etc. simply by including this GWT module. I imagine the best home for this stuff would be in a separate Google code project and that's where it would probably end up. This solves #2 and doesn't require any changes to GWT itself.

Note, I am not trying to write a new "vector API" or add any widget classes... providing the appropriate "widget library" or whatever is a separate issue and can be addressed elsewhere by independent modules.

However #1 is a little more challenging and affects GWT directly.

So far I've started looking at this simplistic strategy: modify the GWT code to generate additional bootstrap scripts for the different document types, e.g., "foo.svg.nocache.js", "foo.xhtml.nocache.js", etc. These additional scripts don't affect existing GWT functionality; they just add new "launching pads" for new document types.

The goal is to make GWT more amenable to this kind of generalization, but of course without violating any of GWT's core principles. It seems like it can be done simply by adding new bootstrap scripts, and (at least initially) leaving the "widget library" details to the user. I am of course prepared to do the work, get it reviewed, CLA, etc.

Some issues:

• How important is IE wrt. SVG? Basically Microsoft has chosen not to support SVG; so as long as "browser independence" is defined only over the domain of browsers that actually support the target document type, this shouldn't be a problem. Different browsers exist for different document types. Is accepting this as a fact of life reasonable?
  
• What about hosted mode? It doesn't handle SVG for now, but what would be the longer term plan?
• Is it more important to add support for new document types (makes some developers happy) or to ensure a perfect "developer experience" with a widget library, hosted mode support, etc. first (makes other developers happy).

What do the GWT experts think?

Thanks.

--
Archie L. Cobbs
CTO, Awarix, Inc.
http://www.awarix.com

[Scott Blum]

You raise a lot of interesting issues.  I'll have to think about this a lot more, but I would encourage you to continue in the direction you're heading, and let us know what roadblocks you run into.

I will say that GWT's primary focus is on DHTML, but that doesn't rule out the possibility of other doc types.  One thing you might be interested in is that we've been talking recently about the idea of a backend "linker" that would be pluggable/configurable, so that the compiler output is a lot more customizable.  This sounds like a good use case for that architectural idea.

[Archie Cobbs]

Thanks for the feedback. I'll continue on this track and let you know what I come up with (so far so good).

-Archie

On 11/7/07, Scott Blum <sco...@google.com> wrote:

You raise a lot of interesting issues.  I'll have to think about this a lot more, but I would encourage you to continue in the direction you're heading, and let us know what roadblocks you run into.

I will say that GWT's primary focus is on DHTML, but that doesn't rule out the possibility of other doc types.  One thing you might be interested in is that we've been talking recently about the idea of a backend "linker" that would be pluggable/configurable, so that the compiler output is a lot more customizable.  This sounds like a good use case for that architectural idea.

[Archie Cobbs]

On 11/7/07, Scott Blum <sco...@google.com> wrote:

You raise a lot of interesting issues.  I'll have to think about this a lot more, but I would encourage you to continue in the direction you're heading, and let us know what roadblocks you run into.

I will say that GWT's primary focus is on DHTML, but that doesn't rule out the possibility of other doc types. 

Here's a first draft of generalizing GWT to support new document types, plus an SVG implementation. It turned out to be pretty straightforward and without a negative impact on "existing stuff".

Change summary:

* Generalize SelectionScriptTemplate to handle multiple document types and their corresponding templates
  - Define an enum for document type, each having an associated template and filename suffix.
  - Let the template define how to inject external scripts and stylesheets instead of assuming document.write().
  - Define an SVG document type and template based on a simplification of the existing HTML template.

* Define an XML namespace for GWT so that XML documents can include the XML equivalent of <meta> tags, using <gwt:meta> tags. Demonstrate how to find these in the new SVG bootstrap template.

* Add a DocType module that defines a property provider for a new "doctype" property. Values detected so far: html, xhtml, xhtml2, svg, xul, unknown.

With these changes, GWT+SVG just works. I've included the obligatory demo (this works in FireFox 2.0, haven't tried any other browsers). Try this link to see it:

  http://www.awarix.com/archie/DOMTest.svg

Note how text on the page gets italicized by the stylesheet, which is injected by GWT.

Here's the Java source for the above demo... using my DOM "wrapper" implementation (not shown):

  http://www.awarix.com/archie/DOMTest.java.txt

FYI with these changes adding XHTML support to all of the existing GWT widgets would appear reasonably straightforward, requring only a new DOMImplXHTML.java class that would be keyed off the new "doctype" property.

Let me know what you think.

Thanks,
-Archie

[Ian Petersen]

I think this is _really_ cool. It would be neat if your demo was
compiled with -style PRETTY so we could peak at the output.

Ian

--
Tired of pop-ups, security holes, and spyware?
Try Firefox: http://www.getfirefox.com

[Peter Blazejewicz]

hi Archie,

On Nov 7, 10:52 pm, "Archie Cobbs" <archie.co...@gmail.com> wrote:
> Some issues:
> - How important is IE wrt. SVG? Basically Microsoft has chosen not to

> support SVG; so as long as "browser independence" is defined only over the
> domain of browsers that actually support the target document type, this
> shouldn't be a problem. Different browsers exist for different document
> types. Is accepting this as a fact of life reasonable?

IExplore does not suport SVG natively and Adobe after purchasing
(merging) Macromedia (Flash to be strict) announced - guess what -
that they SVG plugin support is ended (will be ended with end of that
year) - and yes,, IE is still predominat browser which does not
support SVG (did they talked about Silverlight?),
related fresh topic on regular group:
http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/83dba7de10d92adc/
regards,
Peter

[Archie Cobbs]

Sure... http://www.awarix.com/archie/pretty/DOMTest.svg

[Archie Cobbs]

Thanks... yes, I'm keenly aware of all the corporate maneuverings :-)

If IE doesn't support SVG that's fine... it then simply doesn't fall into the category of "SVG browsers".

The SVG document type support only attempts to target SVG browsers.

In other words, if you are speaking the language of HTML then I completely agree with you that it would be crazy to not support IE. However, in the case of SVG the picture is quite different.

[Peter Blazejewicz]

hi Archie,
I rather tend to agree that IE-thing is fact of live, I've only
outlined few things that stays behind decisions,

also I wonder how many libs already are written for SVG:
http://gwt-svg.googlecode.com/svn/
http://wiki.svg.org/SVG_and_GWT
and more,

considering incubator existance I wonder if you can join forces with
other people to merge efforts to have one, well maintained library,
regards,
Peter

On Nov 10, 12:28 am, "Archie Cobbs" <archie.co...@gmail.com> wrote:
> Thanks... yes, I'm keenly aware of all the corporate maneuverings :-)
>
> If IE doesn't support SVG that's fine... it then simply doesn't fall into
> the category of "SVG browsers".
>
> The SVG document type support only attempts to target SVG browsers.
>
> In other words, if you are speaking the language of HTML then I completely
> agree with you that it would be crazy to not support IE. However, in the
> case of SVG the picture is quite different.
>

> On 11/9/07, Peter Blazejewicz <peter.blazejew...@gmail.com> wrote:
>
>
>
>
>
> > hi Archie,
>
> > On Nov 7, 10:52 pm, "Archie Cobbs" <archie.co...@gmail.com> wrote:
> > > Some issues:
> > > - How important is IE wrt. SVG? Basically Microsoft has chosen not to
> > > support SVG; so as long as "browser independence" is defined only
> > over the
> > > domain of browsers that actually support the target document type,
> > this
> > > shouldn't be a problem. Different browsers exist for different
> > document
> > > types. Is accepting this as a fact of life reasonable?
>
> > IExplore does not suport SVG natively and Adobe after purchasing
> > (merging) Macromedia (Flash to be strict) announced - guess what -
> > that they SVG plugin support is ended (will be ended with end of that
> > year) - and yes,, IE is still predominat browser which does not
> > support SVG (did they talked about Silverlight?),
> > related fresh topic on regular group:
>

> >http://groups.google.com/group/Google-Web-Toolkit/browse_thread/threa...
> > regards,
> > Peter

[Archie Cobbs]

Hi Peter,

Thanks... I'm eager to contribute to the existing efforts to build working SVG libraries. However, all of these efforts suffer from the basic roadblock that a GWT application cannot currently be launched from a non-HTML document (not even XHTML works). So it seems to me like this is a pretty basic problem to solve first. Hopefully my solution or something similar will be considered for inclusion in GWT.

-Archie

On 11/9/07, Peter Blazejewicz <peter.bl...@gmail.com> wrote:

[Archie Cobbs]

I'm very interested to hear a strategic discussion about adding support for non-HTML document types. This is an effort I would like to contribute to (hopefully the patch sent earlier can serve as a starting point).

Is this a discussion people are willing to have at this point?

FYI, I've created a project for the "DOM wrapper" implementation part of this puzzle at:

  http://code.google.com/p/gwt-dom/

This project includes

  * W3C DOM APIs implemented in JSNI as "wrappers" of the browser DOM (partially complete)
  * Modified build of GWT supporting SVG documents (including the patchfile used)
  * The GWT+SVG demo module

So in short you can run "ant" and build the working GWT+SVG demo.

-Archie

On 11/7/07, Scott Blum < sco...@google.com> wrote:

You raise a lot of interesting issues.  I'll have to think about this a lot more, but I would encourage you to continue in the direction you're heading, and let us know what roadblocks you run into.

I will say that GWT's primary focus is on DHTML, but that doesn't rule out the possibility of other doc types.  One thing you might be interested in is that we've been talking recently about the idea of a backend "linker" that would be pluggable/configurable, so that the compiler output is a lot more customizable.  This sounds like a good use case for that architectural idea.