Well I have the compression filter turned off now, so that shouldn't be the
problem. And I'm not trying to dynamically include a js file, but create
dynamic js which runs onload:
response.renderOnLoadJavascript("some js code");
However, your suggestion inspired me to take a second look at the API for
IHeaderResponse and I think I've figured out a workaround. If I use
renderJavascript() it doesn't include the js file from wicket, then I can
just manually write my own onload handler which utilizes the output from the
renderJavascript() call. I'm fairly confident that should cover me for
almost any situation that comes up. It may not always be the cleanest code,
but it's better than wasting hours getting oc4j (assuming it's oc4j's fault)
to behave.
Thanks for the suggestion, it may have indirectly solved my problem.
Joel
Alex Objelean wrote:
>
> I've got the same problem. A quick fix for you can be give-up using
> home-grown compression filter or instead of using IHeaderContributor to
> include dynamic Javascript:
>
> [code]
> public void renderHead(final IHeaderResponse response) {
> response.renderJavascriptReference(new JavascriptResourceReference(
> WicketApplication.class, "ref/javascriptFile.js"));
> }
> [/code]
>
> include the JS this way:
>
> [code]
> add(new JavaScriptReference("js.markupId",
> WicketApplication.class, "ref/javascriptFile.js"));
> [/code]
>
> I do not understand the difference between these two methods of adding
> JavascriptReference object (maybe this is related to gzip compression used
> by wicket), but I've noticed that this makes the difference.
>
> PS: I use for compression the
> http://sourceforge.net/project/showfiles.php?group_id=195642 Resource
> Accelerate project. I find it very useful.
>
>
> hillj2 wrote:
>>
>> I'm using IHeaderContributor to include dynamic Javascript; however,
>> wicket-event.js is returning to the browser as unreadable garbage. I
>> think it MAY have something to do with compression. Our app uses a
>> home-grown compression filter, and I also read today that wicket uses
>> default compression too. I tried disabling one or the other or both but
>> this didn't work UNLESS I was using NetTool, which basically acts as a
>> request intercept that spits out the request/response headers. I
>> wouldn't expect NetTool to modify the request/response at all, but for
>> some reason if I have at least one of the compression filters disabled
>> AND go through NetTool wicket-event.js returns fine.
>>
>> I also get this in my log output when the js file fails to return
>> properly:
>>
>> DEBUG 2007-07-27 10:54:19,156 locator.ResourceStreamLocator
>> (locateByResourceFinder:197) - Attempting to locate resource
>> 'org/apache/wicket/markup/html/wicket-event.js' on path [folders = [],
>> webapppaths: []]
>> DEBUG 2007-07-27 10:54:19,156 locator.ResourceStreamLocator
>> (locateByClassLoader:166) - Attempting to locate resource
>> 'org/apache/wicket/markup/html/wicket-event.js' using classloader
>> mcir.root:0.0.0
>> DEBUG 2007-07-27 10:54:19,156 resource.UrlResourceStream (<init>:92) -
>> cannot convert url:
>> code-source:/C:/oc4j10132/j2ee/home/applications/mcir/wicket-1.3.0-Beta-20070606.jar!/org/apache/wicket/markup/html/wicket-event.js
>> to file (URI scheme is not "file"), falling back to the inputstream for
>> polling
>>
>>
>> What makes it even more odd is I've used IHeaderContributor in another,
>> far simpler app before and it's worked fine.
>>
>> Thanks.
>>
>> Joel
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/wicket-event.js-returning-unreadable-tf4158501.html#a12018207
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
