RE: [svg-developers] Re: SVG ouside the browser...

Jim,

Thanks for the very interesting points in both your posts. I'm very keen to
debate these issues, so I really do appreciate the input. I've also
cross-posted to the XForms list, since this is of course a wider discussion
than just scripting and SVG.

My argument is far less black and white than my evangelical enthusiasm has
perhaps led you to think ;), but perhaps I can give you an illustration of
the type of architecture I'm talking about. I'll use XForms to illustrate,
if I may.

In XForms we have a submission element, which can specify:

 * what nodes will be submitted;

 * the manner in which they should be serialised for submission,
   e.g., converted to a GET with name/value pairs (url?a=1&b=2),
   or transferred as is, within a POST, and so on;

 * whether the nodes should be validated against a schema;

 * whether nodes that are currently 'not relevant' should be
   omitted or included;

and a few other bits and bobs. When the submission element is told to
perform the submission, it gathers up the information, and performs a series
of steps -- serialising, perhaps validating, and so on -- before shipping
out the data. The data that comes back is then checked and if there is no
error code, and the data is XML, it is placed in an instance (or could be
used as a new page).

At various points along the way here, events are fired to indicate various
types of failure, and with luck, a final event would be fired to indicate
that the whole process has finished, and the data returned successfully.

Now, a customer of ours wanted to be able to access an Oracle Lite database
on their users' laptops, so that they could work offline. Easy they thought,
we'll just use some script; we can get the instance data from out of XForms
-- the spec has a small number of DOM methods -- and then just write the
data into the database using some script and an ActiveX component. But the
problem with doing it that way, they had lost all of the advantages of using
XForms -- the data validation, the events firing on failure and success, and
so on.

So, all we did is change our architecture so that the point at which you
read and write the actual data can be replaced, but you still get all the
other steps that occur before and after that. But here's the bit that might
surprise ... the way that we did this was with XBL and script!

Now before you say, "gotcha", my point is not that there is anything wrong
with script per se; but this small amount of script is extremely easy for
the customer to maintain, and it does only one thing -- read and write XML
from a database. The event dispatching, schema validation, and so on, is
handled elsewhere. And what I think is really interesting is that within the
customer's organisation, form designers (not C++ programmers, and not even
JavaScript programmers) can get at this data and make use of it, with a line
of mark-up much like this:

  <submission action="db://customers/customer?id=7" method="put" ... />

I'm not at all saying that anyone who can write an HTML page can now write
an XForms form, but at the same time, you shouldn't need to have years of
programming experience and have created a full JavaScript library to be able
to read a customer from a database, modify their details and write the
customer back.

So to recap, this seems much easier to maintain and easier to debug than
dropping the equivalent script straight into the final document. And perhaps
more importantly, it lowers the bar for the kind of skills you need to build
internet applications, in the process freeing up more experienced
programmers to code up the SVG widgets, create the database interfaces, and
so on.

To conclude -- I'm not therefore saying that XForms will save the world, but
rather that XForms is part of a bigger architecture. (Which might save the
world ;) ).

Regards,

Mark


Mark Birbeck
CEO
x-port.net Ltd.

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

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

> -----Original Message-----
> From: news [mailto:news@sea.gmane.org] On Behalf Of Jim Ley
> Sent: 23 November 2004 21:42
> To: svg-developers@yahoogroups.com
> Subject: [svg-developers] Re: SVG ouside the browser...
> 
> 
> 
> 
> "Mark Birbeck" <Mark.Birbeck@x-port.net> wrote in message 
> news:000b01c4d100$67ccd9a0$0e01a8c0@W100...
> >> 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.
> 
> But the reason for this is that we can ship solutions without 
> relying on people installing applications, if  Peter's users 
> are willing to install app's, he's silly to be using 
> javascript+svg or html for everything  as he knows (there are 
> arguments for final rendering where you can have good low 
> cost templating/customisations solutions for the end user.)
> 
> It may be worthwhile to go down the ActiveX route, this is 
> certainly what 
> I've done in the past with IE HTML rendering systems - the 
> business logic 
> goes into C++ which is called from the browser, is it a good 
> solution, 
> maybe?  Things like Zeepe make it very easy to do this, 
> basically we're just 
> using the DOM as a rendering layer, and ActiveX still gives us that 
> web-delivery/upgrade path which was important.
> 
> > I would have thought Flash was out of the frying-pan and 
> into the fire 
> > -- surely it's just more script?
> 
> Yes, flash will offer nothing 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.
> 
> But this again assumes a high degree of webbiness in the 
> application, which IMO will never be a good choice if proper 
> applications are a 
> possibility,
> 
> XForms don't solve all  the problems, in fact like all 
> declaritive systems they only solve a portion of the problems 
> so you still end up with lots of script (especially as 
> talking to web-services is dog slow so you end up moving more 
> and more of  the intelligence to the client to make the user 
> experience acceptable.)
> 
> The other problem with declaritive systems that make us turn 
> to scripts for easier development, is the lack of structured 
> error handling, user agent developers have traditionally been 
> very bad at not releasing user agents before they're 100% 
> spec conformant, or pretty free from bugs.  This means we can 
> actually only use a subset of functionality, with script 
> though, we know much more reliably if it's failed, so can 
> then try a proprietary version, or a hack or a workaround oor 
> something to cover the other user agents - or at least manage 
> the UA failure.  Declaritive systems don't have this benefit 
> - we can't even rely on HTML elements being understood, let 
> alone more complicated combinations of elements.
> 
> > 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.
> 
> There are lots of simple demos, I've yet to see anything that 
> approaches the sort of thing I do in script, let alone the 
> sort of thing that's done in non-web applications, Francis's 
> original 12,000 lines is a reasonable size, but nothing 
> crazy, I've certainly worked on larger, and it's a difficult 
> management and QA problem, but I'm not sure another language 
> and layer in the mix actually simplifies things all that 
> much, the layers are easier to test sure, but they still need 
> as much testing, and the QA tools are just as much not there 
> with XForms as they are not there in the javascript world.
> 
> > But
> > the imminent version 2.0 of formsPlayer uses XBL to 'hide the join' 
> > (so to
> > speak) between XForms and custom user interfaces.
> 
> Yes the abstraction is very useful, and I think it's an 
> excellent argument for using XForms, I just don't think 
> there's much of an argument that
> XForms+XBL+SVG+Script is going to be much simpler to manage 
> and test as
> SVG+Script, especially if it uses sXBL to provide the same 
> abstraction 
> SVG+with
> more data-specific XML vocabularies that fit well in the 
> workflow (say GML for a map system, or FOAF RDF/XML for a 
> social networking system)  We just introduce a transformation 
> from source XML to XForms model, when that's not in itself 
> adding much simplification.
> 
> > 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, and I think it is 
> > important to start provoking a bit of discussion about how this 
> > combination might be used.
> 
> Definately there's a lot of useful stuff that can be done 
> with SVG/XForms, I'm just not so sure that it really adds a 
> lot of value to the complex system that started the thread, 
> or to that many data systems.
> 
> Cheers,
> 
> Jim.
> 
> 
> 
> 
> 
> 
> ------------------------ Yahoo! Groups Sponsor 
> --------------------~--> 
> Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
> Now with Pop-Up Blocker. Get it for free! 
> http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/1U_rlB/TM
> --------------------------------------------------------------
> ------~-> 
> 
> -----
> To unsubscribe send a message to: 
> svg-developers-unsubscribe@yahoogroups.com
> -or-
> visit http://groups.yahoo.com/group/svg-developers and click 
> "edit my membership"
> ---- 
> Yahoo! Groups Links
> 
> <*> To visit your group on the web, go to:
>     http://groups.yahoo.com/group/svg-developers/
> 
> <*> To unsubscribe from this group, send an email to:
>     svg-developers-unsubscribe@yahoogroups.com
> 
> <*> Your use of Yahoo! Groups is subject to:
>     http://docs.yahoo.com/info/terms/
>  
> 
> 
> 
> 
>

Received on Wednesday, 24 November 2004 01:20:05 UTC