Hi Peter,

Here are a few comments on your posting.


> the web application we are building has really grown up and is
> beginning to tax the reach of JavaScript - by that I mean more then
> 12,000 lines of code . That is why we are looking to move to a more
> robust/rich programming environment.

Understandable! I have long felt that the path SVG is currently following is
dangerously close to the one that HTML+JS has gone down.

> Our consideration at this point is to move to Java/Batik or Windows
> application (.NET). Maybe even Flash.

I would have thought Flash was out of the frying-pan and into the fire --
surely it's just more script?

I can see the motivation for powerful languages like Java and C# though, but
might I suggest that you take a look at XForms to provide the data
management side, such as schema validation, talking to web services,
spreadsheet-style calculations, and so on. Then you could use SVG solely for
the user interface.

We have a simple demo on our home page that shows how you can use XForms to
talk to a weather web service, and then use the values returned from the
service to update the bars in an SVG bar chart. DOM 2 Events is used to
connect the two together, so that if the underlying data changes, the bars
also change. The 'wiring' that happens when the events fire is, in this
example, done with some script (although it's just cut and paste stuff). But
the imminent version 2.0 of formsPlayer uses XBL to 'hide the join' (so to
speak) between XForms and custom user interfaces.

This dramatically reduces the amount of code you need, and of course the
maintenance headache. For example, a thermometer defined using SVG could be
made to render simply by setting the data type of the underlying data (a
feature already used in XForms for dates and booleans):

<xf:model>
<xf:instance>
<data xmlns="">
<lo>6</lo>
<hi>10</hi>
</data>
</xf:instance>
<xf:bind nodeset="lo" type="temperature" />
<xf:bind nodeset="hi" type="temperature" />
</xf:model>

<!-- schema definition for 'temperature' needs to be present -->

<xf:output ref="lo" />
<xf:output ref="hi" />

Once the correct rule is established in the XBL code, both xf:output widgets
will be rendered as thermometers because they are 'bound' to data of type
'temperature'. This may happen 30 times in one form, or once in 30 forms,
but regardless of how many times this is used, it can always be driven by
the data type (so if it changes, the choice of widget will change, too).

As a consequence of all of this, we get a genuinely clean separation; the
SVG code deals only with how the thermometer looks and perhaps acts (the
user may be allowed to slide the indicator, for example). And XForms looks
after the data, submission, schema types, validation, calculations, and so
on. XForms tells the SVG widget when the data has changed, or has become
invalid, and the SVG widget tells XForms if the user has entered a new
value. But the SVG widget could now be used in numerous different places, on
many different forms, whilst equally, the underlying form could be used with
a range of different widgets, for different environments.

Although I've explained this in terms of our product formsPlayer, I'm really
talking about general principles concerning the separation of data and the
UI that manipulates that data. There are other ways that XForms and SVG
could be used together, but my main point is that the combination of XForms,
SVG and DOM 2 Events is incredibly powerful, and I think it is important to
start provoking a bit of discussion about how this combination might be
used.

Best regards,

Mark


Mark Birbeck
CEO
x-port.net Ltd.

e: Mark.Birbeck@...
t: +44 (0) 20 7689 9232
w: http://www.formsPlayer.com/

Download our XForms processor from
http://www.formsPlayer.com/