The other remarks are not directly related to the problem but just some late night thoughts that were fired up by it. The ajax header contribution is fine but I think in most cases loading the component header stuff at initial page rendering will be better, because it avoids the problem that gave place to this thread, and because the contribution will no be resent to the client on each ajax request that rerenders the component, even if the header contribution is static and even if the component is in fact not visible (say, because it has been hidden by the ajax event; I've tried this and a component that is not visible is anyway dynamically contributing its header if added to the ajax target).
Cheers, Carlos On 7/31/07, Carlos Pita <[EMAIL PROTECTED]> wrote: > > 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<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] > > > > >
