Hi Steve, Although I've said this before, I believe that architecting *first and foremost* in SVG is not sustainable. I know that people will reply by saying that they have successfully created applications that have hundreds of thousands of lines of SVG, but it seems to me that the 'mountain bike demo' discussion a week or so ago made it plain that--despite the incredibly impressive results--for most developers and projects this approach is not an option.
I'll describe the architecture I am working towards, and then follow with an example that adds dynamic SVG buttons to an existing application by 'skinning' it, rather than changing the application. The SVG buttons will: * use filters to give a rounded effect; * obtain their captions from the XForms engine, and be updated if the data changes; * use the applications's CSS to obtain colours which will be used for the captions and the background; * use SMIL to 'fly' the button's label in, but use *CSS* properties to determine *when* to fly the text. This last point is I believe a very important development, in that we are not binding to specific events like mouse-over, but to CSS clasees. In other words, the functionality in the SVG button is *truly* independent, encapsulated and re-usable. ARCHITECTURE The archtitecture I would recommend to you is one in which the foundation of an application is an XHTML document. For now that's XHTML 1.1, but soon it will be XHTML 2. This foundation provides us with a simple framework into which we can put metadata about the document, links to stylesheets, and so on. Once we have a basic document, what goes inside it depends on what you are trying to do, but in general I would say that we want it to be as abstract as possible. We want to specify *what* we want to do, not how it will be done. If we want to collect an integer from a user, we just use the XForms input control, and bind it to a node of type xsd:integer. If we want to show an error message we should use the XForms message element. And so on. What we *don't* want to do--at this level at least--is start defining our application in terms of scripts that are non-portable, and don't capture the *intent* of our application. Although we have enabled our Sidewinder Viewer to cope with XForms, SVG, XHTML and MathML, I would suggest that of these, SVG is not an 'abstract' language but a rendering one. MathML is abstract, as is XForms, whilst XHTML has a foot in both camps! SKINNING So where does SVG come in? Well, once we have created our application at an abstract level--step 1 enter a number, step 2 request a customer, step 3 allocate the invoice, and so on--we are then ready to 'skin' it, and present it to our users. Ideal for this is XBL, and inside XBL modules is where we should put our SVG, VoiceXML, X3D or whatever rendering language we care to use. We can keep it hidden, and keep it manageable. We can share objects, replace them with others, or even let the user choose to 'skin' our application in a different way to the one that we intended. AN EXAMPLE If you have looked at our Sidewinder Viewer (available at <http://www.formsplayer.com/download/swviewer-install.html>) you might have seen that the latest version comes with a full-featured application that interacts with Google Desktop Search (GDS). The application is built using standard XForms techniques, with a few clever bits to make configuration easy. The UI is pretty 'traditional' but on the XForms Wiki we have an example that shows how to add an SVG widget to replace the normal buttons. See: <http://www.xforms-wiki.com/bin/view/Main/XformsAndSkinning> This topic has all the files needed to add animated buttons to the Google Search application, and takes you step-by-step through what is needed. There is also a small Flash video if you just want to see the results. CONCLUSION Note that the only changes needed to the actual application are a link in the header to indicate what binding rules should be used; the actual code to achieve the 'animated label widget' is kept in the XBL module. This makes testing and auto-generation of applications much easier, since the logic is separate. For your application you might want to look at taking the same approach, and use XBL+SVG to create whatever controls you need, with XHTML to hold the whole thing together. Regards, Mark Mark Birbeck CEO x-port.net Ltd. e: [EMAIL PROTECTED] t: +44 (0) 20 7689 9232 w: http://www.formsPlayer.com/ b: http://internet-apps.blogspot.com/ Download our XForms processor from http://www.formsPlayer.com/ > -----Original Message----- > From: svg-developers@yahoogroups.com > [mailto:[EMAIL PROTECTED] On Behalf Of Steve Harwin > Sent: 08 June 2005 03:32 > To: svg-developers@yahoogroups.com > Subject: [svg-developers] XForms in standalone SVG > > Hi, > > I have been silent on this list for a while now because the > pressures of work have not allowed me the time to > participate. I have, therefore, probably missed some > insightful dicussions on the topic I raise here, so feel free > to refer me if I am restating questions that have already > been answered. I also apologise in adance for my verbose posting... > > I have had a look at XForms in a standalone SVG 1.2 doc and > finally got a simple test to work, the problem I face is that > the rendering of the XForms components in a standalone SVG is > controlled via SVG elements, ie you have to build the SVG > equivalent of the "input box" and then use the new "editable" > attribute on the text element to allow a user to modify the > text and then in turn modify the XForms component via a > prototype binding and JS. This would all be great if the > editable Text functionality worked the same way as text in a > traditional input box, but the user must click on the text to > start editing, ie to focus the keyboard events on the text, > they can't just set the focus on the text via a javascript > event fired when the "box" is clicked or the user does > something fires a focus call (as far as I can tell) and then > start typing (if I could use js then I could use an event on > the input box rectangle that causes the text to be in > keyboard focus... or is this already possible?). In addition > once editing the text the user still has the problem that > highlighting a portion of the text and then pressing delete > or backspace does not delete the selected text, only a single > character at the location of the text cursor...perhaps it is > the ASV6 that has not implemented editable text to full > extent... These are similar problems to ones I faced in the > old Straley Forms input box (a difference is that the > capslock works for the SVG 1.2 editable text version in ASV6 > and many other similar problems that I set about trying to > solve and got daunted). > > I dunno, I just feel like I am fighting an uphill battle and > all my research indicates that for the past two years > everyone has been waiting for UI components in a standalone > SVG and they have not been delivered...frustrating. Some say > that SVG is not the domain for UI elements as standalone web > apps, but I disagree, I think it is perfect and except for > the UI component issues I have managed to do some great stuff > using just Javascript objects and SVG... I see a light at the > end of the tunnel but I need to reach the end now, I want all > the functionality of SVG, XForms, XBL (RCC) and CDF now and > for it to have full browser support, I feel like thowing a > tantrum ;-), if only that would speed things up, alas I know > I am just joining a queue of many more expeienced developers > that have probably put their SVG projects into ASP.NET or JSF > or XHTML or whatever... I like standalone SVG that makes use > of XForms, XBL etc when it needs it. > > So where to from here? well, I managed to get XForms to > render amongst SVG via the FormsPlayer in an XHTML doc, > should I take my standalone SVG app and write it as inline > SVG within the XHTML doc? and in so doing allow the XForms > renderer (FormsPlayer) to handle complexities of the keyboard > interaction. Alternatively I could quite easily use a > spawned window to hold the input boxes and these could then > interact with the parent SVG to allow the user to edit > attributes. This would then get my project back on track and > I could deal with SVG text input boxes once the technology > has matured. Either way I feel like there are all these > options and I dunno which path to follow. Should I just ditch > SVG and start from scratch building my app in Flash? tempting. > > Some guidance would be much appreciated, I have spent > precious time trying to battle the draft spec/pre > release/beta versions of things, I am ready to move back into > existing technology and leave the battle until I have better > tools/implementaions/standards for the job. Don't get me > wrong though, I appreciate all the efforts on the W3C and am > trying to support their standards (admittedly within the my > self defined scope of a using standalone SVG docs), I am just > beginning to loose faith. > > All advice or criticism will be gratefully received. > > Steve > (GIS Developer specialising in internet mapping systems) > > > > [Non-text portions of this message have been removed] > > > > ----- > To unsubscribe send a message to: > [EMAIL PROTECTED] > -or- > visit http://groups.yahoo.com/group/svg-developers and click > "edit my membership" > ---- > Yahoo! Groups Links > > > > > > > > > [Non-text portions of this message have been removed] ----- To unsubscribe send a message to: [EMAIL PROTECTED] -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: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
