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 Fri, 18 Nov 2005 11:02:36 GMT
Hi Michael,

"Bishop, Michael W. CONTR J9C880" <Michael.Bishop@je.jfcom.mil> wrote on 
11/17/2005 10:21:34 AM:

> Wow, I've had to read this three times to get my head around it.  This
> sounds horribly confusing!

   In reality I think it would be fairly simple.

> Why am I wrapping and unwrapping?  Shouldn't I just wrap the class once
> and leave it as-is?  Maybe add some logic to displayError()?

   If you create a UserAgent wrapper class (as opposed to subclassing), 
then you don't need to know what 'actual' UserAgent class the 
BridgeContext is using.   Your wrapper just acts as a kind of
filter, intercepting some of the messages to the UA, but letting
most calls proceed as normal.

> if (isDOMEditing) {
    // Inform editor, so it can inform user  & revert
    // After setAttribute completes.
    editor.setUpdateError(e); 
> } else {
    wrappedInstance.displayError(e);
> }
> 
> This'll most likely take awhile...be worth it when it's done; the
> functionality is pretty nice.  Just touchy if you mess up...:)




> 
> Michael Bishop
> 
> -----Original Message-----
> From: thomas.deweese@kodak.com [mailto:thomas.deweese@kodak.com] 
> Sent: Thursday, November 17, 2005 9:47 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/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
> 
> ---------------------------------------------------------------------
> 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