Hi Michael,
"Bishop, Michael W. CONTR J9C880" <[EMAIL PROTECTED]> 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: [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]
