xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From thomas.dewe...@kodak.com
Subject RE: Validation of SVG elements
Date Thu, 17 Nov 2005 14:47:10 GMT
Hi Michael,

"Bishop, Michael W. CONTR J9C880" <Michael.Bishop@je.jfcom.mil> 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: thomas.deweese@kodak.com [mailto:thomas.deweese@kodak.com] 
> Sent: Thursday, November 17, 2005 8:04 AM
> To: batik-users@xmlgraphics.apache.org
> Subject: RE: Validation of SVG elements
> 
> Hi Michael,
> 
> "Bishop, Michael W. CONTR J9C880" <Michael.Bishop@je.jfcom.mil> 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: thomas.deweese@kodak.com [mailto:thomas.deweese@kodak.com] 
> > Sent: Wednesday, November 16, 2005 8:28 AM
> > To: batik-users@xmlgraphics.apache.org
> > Subject: Re: Validation of SVG elements
> > 
> > Hi Michael,
> > 
> > "Bishop, Michael W. CONTR J9C880" <Michael.Bishop@je.jfcom.mil> 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: batik-users-unsubscribe@xmlgraphics.apache.org
> > For additional commands, e-mail:
> batik-users-help@xmlgraphics.apache.org
> > 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org


Mime
View raw message