> I think i replied why not in the other response. Couple of more > things. Even if the response is sent with ajax response, it's filtered > on client (and partially on server as well). So the dependencies are > not loaded more then once.
Ok Matej, I have been reading the sources to understand how this is being done at client side. Just to make sure I understand it, could you please confirm or correct the following points: 1) inline scripts are assigned a generated id and then filtered by this id when resent. 2) external script references are filtered by the src attribute. 3) styles are filtered by generated ids. 4) links are filtered by the href attribute. 5) dynamic stuff is not filtered out, for example a <script wicket:id="myscript"></script> whose contents are rendered by a custom WebComponent. At the server side: a) the header for a component is rendered just once (I mean, not once for each instance of the component in the page but just once for the component class). b) duplicate contributions are not filtered out except when added via a headerresponse or headercontributor. Thank you for your answers. Cheers, Carlos Wicket can't know which component's renderHead method should be > invoked, because if the components are not visible, they might not be > even built (like in the listView example). Also this doesn't solve the > problem when you add component later to the page (using ajax.) > > -Matej > > On 7/31/07, Carlos Pita <[EMAIL PROTECTED]> wrote: > > 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] > > > > > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
