Because of a security restriction at the browser (firefox) side. I can't dynamically include external scripts. For example, ajax response can't contribute <script src="http://www.google.com/uds/api?file=uds.js&v=1.0"; type="text/javascript"></script> (for the google search api). If it does I get the aforementioned "permission denied to call method XMLHttpRequest.open" error. Of course I can include the same script when the page is initially rendered, as usual.
Cheers, Carlos On 7/31/07, Matej Knopp <[EMAIL PROTECTED]> wrote: > > I don't really understand what your problem is. Wicket has AJAX header > contribution, which should load the javascript dynamically for you. > Doesn't this work for you? > > -Matej > > On 7/31/07, Carlos Pita <[EMAIL PROTECTED]> wrote: > > Yes Gwen, > > > > there are a couple of workarounds, of course, I could call renderHead > > explicitly from the page too. But the case seems not too uncommon imo (a > > component that includes some external javascript and isn't showed at > first). > > Maybe it should be supported directly by wicket, after all a component > > usually contributes support stuff to the header that it's not visible > but > > should be there in case it is finally showed. > > > > Current implementation resends the header stuff by ajax every time the > > component is updated and then checks for duplication at client side so > that > > js, css, links, etc are not included twice. But usually it's simpler and > > maybe a bit more robust to include the header support stuff upon page > > rendering and not to contribute anything more upon ajax rendering. Of > course > > contributed stuff could change from ajax request to ajax request but I > don't > > think this is the rule for the header but, for example, to javascript > > snippets appended to the ajax request target. > > > > More generally speaking, at least four header-contributing scenarios > come to > > my mind: > > > > 1) initial page rendering - per component class > > 2) ajax component rendering - per component class > > 3) initial page rendering - per component instance > > 4) ajax component rendering - per component instance > > > > The "per component instance" variants allow each instance of the > component > > to spit some code tailored to the specific instance (for example, > including > > its markupId). Currently component headers are rendered just once per > > component class on page rendering, and then once more each time an > instance > > of the component is ajax re-rendered. > > > > What do you think about this? Am I completely missing the point? > > > > Cheers, > > Carlos > > > > On 7/31/07, Gwyn Evans <[EMAIL PROTECTED]> wrote: > > > > > > On Tuesday, July 31, 2007, 7:30:34 AM, Carlos < > [EMAIL PROTECTED]> > > > wrote: > > > > > > > I have a component that contributes some javascript to the header. > > > Initially > > > > the component won't be shown but an ajax event could make it > visible. > > > The > > > > problem is that the javascript is contributed later, during the ajax > > > > response, and there is a security concern with firefox: "permission > > > denied > > > > to call method XMLHttpRequest.open". This is because I'm trying to > > > include > > > > an external script (simply <script src="http://....";>) that would > > > normally > > > > be included with no complaints when the page is initially loaded. I > > > don't > > > > know how to override this default behavior. I guess the code that > > > controls > > > > this head rendering logic for visible/hidden components is that of > > > > HtmlHeaderContainer. Any ideas? > > > > > > Would it work if you were to split your component into two > > > sub-components with the UI part being initially invisible, but the JS > > > not being so, and thus contributing? > > > > > > /Gwyn > > > > > > > > > --------------------------------------------------------------------- > > > 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] > >
