RE: Setting attribute values in xf:repeat

Hi Robin,

[I assume that Jon is CC'd by you since your questions are SVG/sXBL related,
so I've also CC'd him.]


> was my question dumb to the point that no one even wanted to consider
> answering it? :)

I can't speak for others on whether the question was 'dumb' ;), but for me
it was very pertinent - it just happens that I don't recall seeing it first
time round!

Anyway, the first point to make is that the reason there is no reference to
attribute value templates is pretty straightforward - they are not supported
in XForms. That's disappointing for me too, and the main reason I like them
is for exactly the use cases you are describing - to allow the XForms model
to drive SVG charts and such like. There are also other pretty good uses for
them in VoiceXML and so on.


> I know that using sXBL makes the problem go away, but here we are
> considering an implementation in a mobile device, and sXBL is 
> currently 
> ruled out.

That's a shame - I think XBL is crucial to getting the most out of the
combination of XForms and other mark-up languages, in particular SVG. (sXBL
less so - but that's another story.) We've implemented a fuller version of
XBL than sXBL in formsPlayer, and we use it to define pretty much everything
now, from the widgets through to extension XPath functions ... even
customised submission serialisations.

It's particularly good for custom controls though, because it combines both
a templating mechanism with the ability to define properties, methods and
events on an object. In particular I like the way it allows you to define
the behaviour of an 'abstract' control, which can in turn be skinned as
something more specific. For example, you can define a range control that
contains nothing but 'add one', 'subtract one', etc., and then you can
inherit from that with specific stuff for, say, an SVG thermometer. The
thermometer doesn't need to know anything about 'rangeness' or how to talk
to the XForms model - that's all nicely compartmentalised in the base XBL
class.

Of course, I understand that this may not be completely appropriate for all
mobile platforms, but it does give very large productivity benefits if you
can squeeze it in.


> Without the ability to set attributes thusly, mixing XForms
> and SVG is 
> only marginally useful in the absence of yet another spec to 
> bridge the 
> two. We would certainly have to drop plans to support it, 
> which I would 
> be quite sorry to have to do.

Personally, I'm not convinced there's *any* use to mixing the two in the
same document (of course you'll notice that I wrote that on an XForms list
and not an SVG one ;)) since they operate at such different levels of
abstraction. An XForms document says "ask the user for a number between one
and ten. If they enter an invalid value, tell them to try again, and once
they have a correct value, send it to server 'X'". An SVG document says,
"draw a line from position 10, 10 to position 3,7 and colour it red with a
Gaussian filter applied to the first thingy".

Take a look at any 'application' built using SVG and it's just as convoluted
as traditional HTML+JavaScript, since to do anything useful requires loads
of script - whether retrieving data from a web service, validating a user's
input, whatever.

I feel a much better model is to generate 'clean' XForms documents, and
reserve SVG for the UI side (custom widgets). Just as XForms 1.0 defines
that a calendar control is rendered if the schema type of the bound data is
xsd:date, so we should be able to say that if the underlying type is of
myschema:temperature, then render an SVG thermometer widget. This is neatly
specified with XBL, and is in fact how we have implemented things in
formsPlayer 2.0. The example you give of circles being repeated is - as you
rightly say - *very* easy inside a custom control defined in XBL.

Obviously this is all pretty new, and probably quite controversial, but our
experience so far has shown that it makes for a very clean separation, and
so for more manageable development. It's not that surprising that it works
better though - after all, XForms is a data language with *abstract*
controls, whilst SVG is a very *specific* UI language (specific in the sense
that it is visual only, vector-based, and so on). The latter is ideal for
providing *concrete* implementations of the XForms widgets, but that doesn't
mean they should be in the same document! (For my two-penneth, the current
trend in the SVG-world to keep adding features to SVG to make it more like
an application language is not going to work. Of course I wrote that on a
non-SVG list, too.)

Anyway, enough future-speak - we'll be making a beta of fP 2.0 available any
time now, so that people can get first hand experience of this type of
architecture, and then hopefully we can get some discussion going between
the XForms world and the SVG one, based on real examples.

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/


> 
> Thanks for any input,
> 
> ===
> 
> Hi,
> 
> I seem to either be missing something, or have found some
> inconvenience, 
> with xf:repeat (I hope the former obviously).
> 
> In a nutshell, I need to produce some SVG from inside an
> xf:repeat in a 
> manner similar to how one might produce, say, an XHTML table, 
> but with 
> spacial rendering. To express it in a way that the XSLT user 
> should find 
> obvious:
> 
>    <xf:repeat nodeset='/foo:bar/foo:stuff'>
>      <svg:circle r='5' cx='{@x}' cy='{@y}'/>
>    </xf:repeat>
> 
> Now I know that XForms isn't XSLT, but the ability to do the
> above would 
> be dead useful for forms that don't have "conventional" presentations 
> and may be using, for instance drag an drop of little circles 
> as a way 
> to modify instance data. But I haven't found any mention of attribute 
> value templates as they are called in XSLT. I looked at 
> xf:output to see 
> if it could route its information to an attribute, and at 
> xf:setvalue to 
> see if it could somehow apply to repeat templates, but have 
> so far not 
> found anything.
> 
> Am I missing something obvious?
> 
> ===
> 
> --
> Robin Berjon
>