You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Carlos Pita <ca...@gmail.com> on 2007/07/31 17:14:26 UTC
Re: contributing to header (was: Must renderHead even if setVisible(false))
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 <gw...@gmail.com> wrote:
>
> On Tuesday, July 31, 2007, 7:30:34 AM, Carlos <ca...@gmail.com>
> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: contributing to header (was: Must renderHead even if setVisible(false))
Posted by Matej Knopp <ma...@gmail.com>.
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 <ca...@gmail.com> 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 <ma...@gmail.com> 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 <ca...@gmail.com> 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 <gw...@gmail.com> wrote:
> > > >
> > > > On Tuesday, July 31, 2007, 7:30:34 AM, Carlos <
> > carlosjosepita@gmail.com>
> > > > 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: users-unsubscribe@wicket.apache.org
> > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > >
> > > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: contributing to header (was: Must renderHead even if setVisible(false))
Posted by Matej Knopp <ma...@gmail.com>.
Basically, this looks correct.
-Matej
On 7/31/07, Carlos Pita <ca...@gmail.com> 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 <ca...@gmail.com> 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 <ca...@gmail.com> 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 <ma...@gmail.com> 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 < carlosjosepita@gmail.com> 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 < gwyn.evans@gmail.com> wrote:
> > > > > > >
> > > > > > > On Tuesday, July 31, 2007, 7:30:34 AM, Carlos <
> > > > > carlosjosepita@gmail.com>
> > > > > > > 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: users-unsubscribe@wicket.apache.org
> > > > > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > > >
> > > > >
> > > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: contributing to header (was: Must renderHead even if setVisible(false))
Posted by Carlos Pita <ca...@gmail.com>.
> 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 <ca...@gmail.com> 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 <ca...@gmail.com> 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 <ma...@gmail.com> 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 < carlosjosepita@gmail.com> 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 < gwyn.evans@gmail.com> wrote:
> > > > > >
> > > > > > On Tuesday, July 31, 2007, 7:30:34 AM, Carlos <
> > > > carlosjosepita@gmail.com>
> > > > > > 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: users-unsubscribe@wicket.apache.org
> > > > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > >
> > > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: contributing to header (was: Must renderHead even if setVisible(false))
Posted by Matej Knopp <ma...@gmail.com>.
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.
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 <ca...@gmail.com> 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 <ca...@gmail.com> 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 <ma...@gmail.com> 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 < carlosjosepita@gmail.com> 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 < gwyn.evans@gmail.com> wrote:
> > > > >
> > > > > On Tuesday, July 31, 2007, 7:30:34 AM, Carlos <
> > > carlosjosepita@gmail.com>
> > > > > 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: users-unsubscribe@wicket.apache.org
> > > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > > >
> > > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: contributing to header (was: Must renderHead even if setVisible(false))
Posted by Carlos Pita <ca...@gmail.com>.
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 <ca...@gmail.com> 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 <ma...@gmail.com> 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 < carlosjosepita@gmail.com> 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 < gwyn.evans@gmail.com> wrote:
> > > >
> > > > On Tuesday, July 31, 2007, 7:30:34 AM, Carlos <
> > carlosjosepita@gmail.com>
> > > > 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: users-unsubscribe@wicket.apache.org
> > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > >
> > > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
Re: contributing to header (was: Must renderHead even if setVisible(false))
Posted by Carlos Pita <ca...@gmail.com>.
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 <ma...@gmail.com> 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 <ca...@gmail.com> 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 <gw...@gmail.com> wrote:
> > >
> > > On Tuesday, July 31, 2007, 7:30:34 AM, Carlos <
> carlosjosepita@gmail.com>
> > > 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: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: contributing to header (was: Must renderHead even if setVisible(false))
Posted by Matej Knopp <ma...@gmail.com>.
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 <ca...@gmail.com> 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 <gw...@gmail.com> wrote:
> >
> > On Tuesday, July 31, 2007, 7:30:34 AM, Carlos <ca...@gmail.com>
> > 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: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org