On Mon, 27 Oct 2008 10:39:40 +1100
Cameron McCormack <[EMAIL PROTECTED]> wrote:

> Hi G. Wade.
> 
> G. Wade Johnson:
> > I've done a little looking at the SVG 1.2 spec and the Batik code.
> > The spec defines a gotoLocation( uri ) method that on the Global
> > interface that Window is supposed to derive from.
> 
> Since the recent publication of the SVG Tiny 1.2 LCWD, the
> gotoLocation() method has been removed in favour of an HTML-like
> window.location thing:
> 
>   http://dev.w3.org/SVG/profiles/1.2T/publish/svgudom.html#dom__Location
>   
> http://dev.w3.org/SVG/profiles/1.2T/publish/svgudom.html#dom__Window_location

That figures. Part of why I decided to go with gotoLocation was that it
is an easy extension of the Window interface.

> > I've found the appropriate code and made mods to add the
> > gotoLocation() method and hit a roadblock.
> > 
> > I don't know how to reload the document without access to the
> > JSVGCanvas and I can't figure out how to get one.
> 
> Currently, the BridgeContext has a reference to a UserAgent object,
> which is implemented as an inner class in JSVGViewerFrame.  That
> UserAgent object is used to do things like popping up alert windows,
> navigating to a new location as a result of clicking on an <a>
> element, and some other things.  So that would be how you control the
> container of the document.

I looked at the UserAgent and didn't see anything I could use. I guess
the info below shows that I wasn't wrong.

> > I thought I had ways around that, but tracking throught the Window,
> > Document, and BridgeContext classes have not given me any insight.
> > 
> > Given enough time, I'd probably be able to figure out what I need,
> > but this is not the problem I'm actually trying to solve. If
> > someone has a hint to point me in the right direction, I'll keep
> > looking at it.
> 
> If I was going to add support for window.location, I’d do the
> following:
> 
>   * Extend the org.apache.batik.bridge.UserAgent interface with a
> method that can navigate to a new location.
> 
>   * Implement that method on
>     org.apache.batik.swing.svg.JSVGComponent.BridgeUserAgent.
> 
>   * Create new interfaces org.w3c.dom.Location and org.w3c.dom.Window.
> 
>   * Make org.apache.batik.script.Window extend org.w3c.dom.Window.
> 
>   * Modify org.apache.batik.script.rhino.WindowWrapper so that the
>     getLocation() method is exposed.
> 
>   * Implement getLocation() on
>     org.apache.batik.bridge.ScriptingEnvrionment.Window.  This could
>     lazily construct an object that implements Location.  I’m not sure
>     where the best place to get/store this object would be — maybe on
>     the BridgeContext?
> 
>   * The class that implements the Location object will need access to
>     the BridgeContext so that it can get the UserAgent and call the
> new location navigation method on it.
> 
> Ideally, I think the implementation of the Location object would go in
> org.apache.batik.dom.* somewhere.  But as a first step it doesn’t
> matter if it’s somewhere else, say in the bridge package.  At some
> point the Window stuff and how objects are reflected into script
> needs to be rewritten, but that might be a while away.
> 
> Hopefully the above gets you on the right track!

That's (a much more detailed view of) what I had first thought, before
I found gotoLocation(). Too bad that's been abandoned.

Unfortunately, this may take me a while. I don't have many tuits for
this project and I don't normally do Java.

I'll see what I can put together.

G. Wade
-- 
"If everything's under control, you're going too slow."
                                                   -- Mario Andretti

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to