OK, so I need to subclass JSVGCanvas.CanvasUserAgent and pass that class in the constructor? Just override displayError()? I'm looking through the Javadocs...pretty confusing stuff.
BTW, yeah, I was updating the JTable's model in the listener for the DOM tree. Making that change in the Swing thread fixed the intermittent problem. Threading always seems to be an issue with me! Michael Bishop -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, November 17, 2005 8:04 AM To: [email protected] Subject: RE: Validation of SVG elements Hi Michael, "Bishop, Michael W. CONTR J9C880" <[EMAIL PROTECTED]> wrote on 11/16/2005 04:38:03 PM: > You kind of have me confused. Are you saying I should go ahead and > pretty much clone the tree? Hmm, I'm thinking about this more and there are more issues than I originally thought. One big issue is that the element must be part of the document to participate in the CSS cascade. Also while a 'g' may validate on it's own you might get problems for it's children (for example a 'g' doesn't really check it's fill/stroke). There are some work arounds for this like adding a 'dummy' child element, adding the element to be tested to an 'unviewable' section of the document (so you get CSS), but it wouldn't be very clean. > That seems like the safest approach to me; I don't want to > catch an error in mid-render. The error should occur before the render is attempted, it should happen as we try and update the GVT tree, which is currently 'during' the setAttributeNS call. > 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. Be careful, just as Batik requires all DOM modifications to take place in the UpdateManager Thread, Swing requires all modifications to take place in the Swing thread. > 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? The attributes are checked as it builds the graphics objects. There is no validation step per-say. > "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. There are a bunch of 'helper' functions that check the values as they build graphics objects, you could conceivably use them directly but it would not be trivial. I am actually starting to lean towards replacing the userAgent (on the BridgeContext) and reverting the attribute if the change results in the UA's 'displayError' method being called. It's a little ugly looking but only if you look at it too closely ;) > -----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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
