Basically, this looks correct. -Matej
On 7/31/07, Carlos Pita <[EMAIL PROTECTED]> wrote: > > 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] > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
