Thanks Guys, Whilst I will certainly investigate how I can completely rearchitecture my web app to fit into the XHTML/XForms/XBL approach as I can see that this is how it probably should have been done, I need a solution similar to the one that Dave suggests. I have combined my javascipt libraries with Kevin Linsey's and Carto.net's to create an interactive drawing tool entirely within an svg document (using the Javascript to handle the interaction with the svg elements). I began this project a few year ago when SVG first appearred and have therefore built and rebuilt it a number of times as technology has improved. It is now at a stage where it is complete (obviously I will continue to improve it, but version 1 is just about there)... My final problem to solve is input boxes. I have been using the Strayley (sp?) form library that he released a couple of years back, but as I said in my first post that lacks most of the complexities (I have added some but not all) needed for proper keyboard interaction. This a common problem with all the other textbox objects I have seen written in JS and SVG... so all I need now is a simple simple text box object that can allow my users to interact with the text properly to adjust coordinates of handles (see kevlindevs shape library), edit text for text elements, adjust circle radius etc... Other than that it is all there. The input boxes are just another way to adjust the drawn elements, the user can drag handles, but somtimes that is not accurate enough, they may need to type a coordinate from a GPS or some such.
Hence my frustration, I am trying to build it for IE and ASV as that is my clients default set up, so I was hoping to just plonk a text input box (from XForms) into the svg and use it... unfortunately for the sake of a simple text input is looks like I will have to rebuild my app... Thanks for feedback. I will begin the daunting process of rebuilding now. Steve ----- Original Message ----- From: "Richard D. Spencer" <[EMAIL PROTECTED]> To: <svg-developers@yahoogroups.com> Sent: Thursday, June 09, 2005 4:12 AM Subject: [svg-developers] Re: XForms in standalone SVG > > Isn't it just as effective to build JS objects to manage the SVG-DOM > nodes (their properties, any animation and any other needed > functionally)? This gives us the freedom of not being locked into > XHTML and still allows us to provide a dynamic UI - to truely become > a one-page web application within the browser. I assume that a JS > manager object could also interface with XFORMS; haven't attempted > this yet. Using JS allows us to use any browser that supports XML, > SVG, XFORMS, XBL, etc.... > > > If I'm missing something important in my approach, please let me know > as I'm already well into the project I'm working on concerning RAD > for SVG. > > Dave > > > --- In svg-developers@yahoogroups.com, "Mark Birbeck" > <[EMAIL PROTECTED]> wrote: >> 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 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/
