That sounds absolutely marvellous! Thankyou so much. Where can I get the
updated code and/or jars from?
William.
From: "Thomas DeWeese" <[EMAIL PROTECTED]>
> Hi William,
>
> I just took a look at this and I made the evaluation of the
> contentScriptType attribute lazy.
> So unless you set one of the 'script' attributes ('onload',
> 'onmouseover', yadah, yadah, yadah)
> it doesn't matter what contentScriptType is set to. This also
> simplified the code somewhat, allowed
> me to only issue the 'unknown language' error once per language, and
> probably improved
> performance in several cases.
>
> This should mean that you can just remove the script/rhino package
> from your applet (along
> with js.jar) and not have any problems (as long as you don't load
> documents that want to use scripting of course). Does this seem like a
> suitable solution to your problems?
>
> William Billingsley wrote:
>
> >Thought I'd pitch back in since my message was linked...
> >
> >I haven't tried removing the Rhino classes (though it might work) because
> >there seems to be another issue that is really the crux of the problem
[this
> >is just a symptom]. Batik only tries to load the Rhino interpreter at
all
> >because of the contentScriptType="text/ecmascript" attribute on the SVG.
> >This is a default attribute in Batik, and cannot be removed, only changed
(I
> >understand in SVG 1.0 this is a required element; ironically it isn't
> >required in the drafts for SVG 1.1).
> >Consequently, shortly after Rhino fails to load, an "unknown language:
> >text/ecmascript" error occurs.
> >
> >There seem to be only two solutions:
> >1. Make the document Static to the canvas -- but this also prevents the
DOM
> >update listener from loading, which is rather useless if you actually
want
> >to make any alterations to the SVG document from within your applet (as I
> >do).
> >2. Change the contentScriptType.
> >
> >The seemingly obvious solution would be to change the contentScriptType
to
> >Java (I forget the tag), since you probably will be adding DOM listeners
> >from your applet. This has the snag that Batik then expects the Java
> >"script" attached to the document to be another set of classes that it
will
> >dynamically instansiate, and not the pre-existing and
already-instansiated
> >classes of your applet. [which holes that idea unless you want to
majorly
> >re-engineer your applet in a very maintenance-hard way].
> >
> >
> >The temporary solution I am looking at is changing the contentScriptType
to
> >a constant (something like ThrowawayThisException), and subclassing the
> >JSVGCanvas user agent to specifically suppress the "unknown language:
> >ThrowawayThisException" exception -- the exception will still happen but
the
> >user never will never see it and it won't stop anything from running.
> >
> I'm not sure this will work with the current architecture as I think
> you may get errors before the
> DOM events are generated (the new system should always send the event to
> the DOM even if the
> script can be fired).
>
> >More ideally, it would be nice if the "Dynamic Support" setting in the
> >JSVGCanvas could be split into two separate settings for DOM Update
> >Listening support and Scripting Support.
> >
> This could be done as scripting is implemented as simply attaching
> additional listeners to the DOM,
> but the lazy approach I think solves this problem and avoids introducing
> another 'dynamic' state.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
