Thomas, > The easiest way to do this would be to have a private 'GVTBuilder' > clone the element (this is a little dicey as you don't really want to > clone the whole tree, but for some elements like, patterns/gradients > you need the whole tree, you might do a tree clone except for some > 'known' elements like 'g', 'defs', 'svg'), make the change to the clone, > and use the GVTBuilder with the clone to 'build' a graphics node. > If this does not throw an error then you should be ok to make the change > to the real element.
Given the absence of a schema SVG (least none that I've been able to find) that more precisely defines data types for values such as style properties, getting Batik to validate the edits in a cloned or 'ghost' tree fragment is a nice idea. In the case of patterns and gradients, where you're validation requires the presence of id referenced nodes, you could use DOM or XPath to locate the relevant fragments (and their ancestry - which in all likelihood would be one or two children in an svg:defs) and add them to your ghost tree. On the subject of an XML schema (or Relax NG for that matter) for SVG, does Anyone know if one has been completed. I recall reading that some brave soul had started work on one. Regards Philip Fennell -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 16 November 2005 13:28 To: [email protected] Subject: Re: Validation of SVG elements Hi Michael, "Bishop, Michael W. CONTR J9C880" <[EMAIL PROTECTED]> wrote on 11/15/2005 05:32:17 PM: > This question is related to the DOM Editor. What I've noticed is that if > I put an invalid value for a particular attribute, the JSVGCanvas returns an > error when I try to render it. Instead of implementing validation for each > and every possible attribute, is there a way I can: > > - Take the changed node and "check" it against Batik. (Like whatever > the JSVGCanvas does when it tries to render) > - Revert to the original value if the check fails, otherwise keep the new value. The easiest way to do this would be to have a private 'GVTBuilder' clone the element (this is a little dicey as you don't really want to clone the whole tree, but for some elements like, patterns/gradients you need the whole tree, you might do a tree clone except for some 'known' elements like 'g', 'defs', 'svg'), make the change to the clone, and use the GVTBuilder with the clone to 'build' a graphics node. If this does not throw an error then you should be Ok to make the change to the real element. This is all "in theory" so there may be blockers that I don't see just thinking about it. > I'd like to "trap" the error before I even attempt to render it and simply > revert the JTable data instead of a nasty pop-up (or a few) when I submit > invalid values to the element/node in question. The other option would be to replace the UserAgent (the class that puts up the dialogs) for the Canvas so you can check if you are in the middle of updating an element from the DOMViewer and if so don't show the error and roll back the element. This could be a little simpler but I'd be a little nervous that there would be some ugliness in the display. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
