Hi Michael, "Bishop, Michael W. CONTR J9C880" <[EMAIL PROTECTED]> wrote on 11/17/2005 01:38:30 PM:
> OK, well I've been playing with it some. Correct me if I'm wrong. The > current UserAgent: > > - Displays an intelligent error message when an attribute is wrong. > - Renders the element without the attribute if the attribute is invalid. What concerns me is that some 'invalid' things might cause 'intelligent error messages' to happen a lot more frequently than might be desirable (like every mouse move). Take as an example an invalid 'stroke-width' and a script animating the 'stroke' color, in this case you would get an error message for every change of the stroke color. > This is starting to look like ideal behavior that I don't need to mess > with. I probably isn't horrible behavior but I liked your original idea better. > > Michael Bishop > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Thursday, November 17, 2005 9:47 AM > To: [email protected] > Subject: RE: Validation of SVG elements > > Hi Michael, > > "Bishop, Michael W. CONTR J9C880" <[EMAIL PROTECTED]> wrote on > > 11/17/2005 09:31:48 AM: > > > 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. > > The most confusing thing is that there are two user agents. > There is the Bridge User Agent and the Swing/Canvas UserAgent. > In this case we are interested in the Bridge UserAgent. The least > invasive thing to do would be to write a 'wrapper' Bridge UserAgent > that takes another bridge UserAgent in it's constructor (and likely a > reference to the DOM editor) and just forwards all calls to the > wrapped UserAgent, except for displayError (and perhaps some of the > other display things), for displayError it checks if you are in the > middle of a DOM Editor change if so it sets a flag indicating that > the change failed and returns silently. > > Then when initializing the DOM editor I would get the current > UserAgent from the BridgeContext and wrap that with your new class > and set your class as the UserAgent (the BridgeContext has > getter/setters > for the UserAgent). You should also replace the old UserAgent when > the DOMEditor is closed (so you don't end up wrapping the wrapped > UserAgent). > > > 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! > > Threading is _very_ powerful but also _very_ tricky. > > > > > 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] > > > > > --------------------------------------------------------------------- > 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]
