Well, this certainly isn't a very common use case. Invoking renderHead for not visible components would be very problematic and confusing, because if you had e.g. invisible ListView, then the children are not even created so those children's renderHead wouldn't be invoked at all. Also this wouldn't solve situation when the component would be ajax replaced.
So in this special case you'll have to add the script reference manually I'm afraid. You can add it to page using a Behavior to make sure it's always rendered. -Matej 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"; > 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] > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
