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]
