You kind of have me confused. Are you saying I should go ahead and pretty much clone the tree? That seems like the safest approach to me; I don't want to catch an error in mid-render. I haven't gotten to looking at this yet, but I'm still gathering ideas on how to approach it. I got side-tracked by a weird problem with JTable; I get a layout-related stack trace infrequently when I call JTable.setModel(...), but that's a Swing issue. Is there a way to get to a lower level of validation? What if I take a Collection of attributes? Is there anywhere in Batik where it checks attributes? "stroke-width" should be an int, "color" should be in a range of valid colors or whatever...would be easier to do on a lower-level. Otherwise I guess it shouldn't be too intensive to clone the tree.
Michael Bishop -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 16, 2005 8:28 AM 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]
