Re: svn commit: r1033843 - in /wicket/trunk/wicket/src: main/java/org/apache/wicket/markup/html/ main/java/org/apache/wicket/resource/ main/java/org/apache/wicket/resource/aggregation/ main/java/org/apache/wicket/resource/dependencies/ main/java/org/

[Johan Compagner <jc...@gmail.com>]

ok this test was then correct that it failed..

Ajax does have to push it to the client because it doesnt know if  it
is there yet or not
that you only know because of the id <script id=xxx> that can be set i
believe then at the client side it is checked if that id is there
already

For example if you have a main page with tabs and those tabs are
switched through an ajax request
then everything that is inside that tab needs to be render and also
the js and css contributions..
It could be that those are the same as the previous tab.. But the
second tab doesn't know that.

I think that is all resolved at the client side in the browser, but i
guess matej or igor knows that a bit better them me.

But all the components that are added to the AjaxRequestTarget should
contribute.. Not only the first one
and Jeremy's commit broke that

johan


On Fri, Nov 12, 2010 at 00:57, Jeremy Thomerson <jr...@apache.org> wrote:
>
>
> On Thu, Nov 11, 2010 at 6:02 PM, Jeremy Thomerson <jr...@apache.org>
> wrote:
>>
>> On Thu, Nov 11, 2010 at 4:04 AM, Martin Grigorov <mg...@apache.org>
>> wrote:
>>>
>>> Notice that I touched AjaxHeaderContributionPage2_ajax_expected.html and
>>> removed expected javascript header contribution after Ajax request.
>>> I think this is the proper fix because this JS url is already contributed
>>> by normal (non-Ajax) page load and it should not be redelivered later by
>>> Ajax contributions.
>
> So, the strange thing is that what makes this fail is that close() is now
> called after the component hierarchy traversal.  The fact that it was not
> being called before really seems like a bug.  But, closing it stops this
> contribution from being rendered because it is rendered after the header
> response is closed (and is therefore skipped).
> So, I have a couple questions:
>
> First - is your statement above correct?  If I add a css file in the page,
> and then contribute the same URL via AJAX, should it be added to the page a
> second time?  You say no, but it appears that we've been testing to make
> sure that it is.  I think there could be cases where it should - what if
> that URL returns dynamic css (js, etc) that has changed since the page was
> originally loaded?  It could be JSON, for instance, that has changed.
> Second - there's some strange order of operations happening here that's
> causing this.  I am about to walk out the door and haven't had a chance to
> fully investigate why this is happening.  I wonder
> why AjaxHeaderContribution2 overrides renderHead(HtmlHeaderContainer
> container) rather than implementing the normal IHeaderContributor method.
>  Anybody know off the top of their head?
>
> Jeremy

Re: svn commit: r1033843 - in /wicket/trunk/wicket/src: main/java/org/apache/wicket/markup/html/ main/java/org/apache/wicket/resource/ main/java/org/apache/wicket/resource/aggregation/ main/java/org/apache/wicket/resource/dependencies/ main/java/org/

[Martin Grigorov <mg...@apache.org>]

Now I see where the [B] comes from: AjaxHeaderContribution2.java ...

Later today I will merge your fix to 1.5 and revert mine from th revision
discussed here.

On Wed, Dec 1, 2010 at 2:33 PM, Johan Compagner <jc...@gmail.com>wrote:

> ok this test was then correct that it failed..
>
> Ajax does have to push it to the client because it doesnt know if  it
> is there yet or not
> that you only know because of the id <script id=xxx> that can be set i
> believe then at the client side it is checked if that id is there
> already
>
> For example if you have a main page with tabs and those tabs are
> switched through an ajax request
> then everything that is inside that tab needs to be render and also
> the js and css contributions..
> It could be that those are the same as the previous tab.. But the
> second tab doesn't know that.
>
> I think that is all resolved at the client side in the browser, but i
> guess matej or igor knows that a bit better them me.
>
> But all the components that are added to the AjaxRequestTarget should
> contribute.. Not only the first one
> and Jeremy's commit broke that
>
> johan
>
>
> On Fri, Nov 12, 2010 at 00:57, Jeremy Thomerson <jr...@apache.org>
> wrote:
> >
> >
> > On Thu, Nov 11, 2010 at 6:02 PM, Jeremy Thomerson <
> jrthomerson@apache.org>
> > wrote:
> >>
> >> On Thu, Nov 11, 2010 at 4:04 AM, Martin Grigorov <mg...@apache.org>
> >> wrote:
> >>>
> >>> Notice that I touched AjaxHeaderContributionPage2_ajax_expected.html
> and
> >>> removed expected javascript header contribution after Ajax request.
> >>> I think this is the proper fix because this JS url is already
> contributed
> >>> by normal (non-Ajax) page load and it should not be redelivered later
> by
> >>> Ajax contributions.
> >
> > So, the strange thing is that what makes this fail is that close() is now
> > called after the component hierarchy traversal.  The fact that it was not
> > being called before really seems like a bug.  But, closing it stops this
> > contribution from being rendered because it is rendered after the header
> > response is closed (and is therefore skipped).
> > So, I have a couple questions:
> >
> > First - is your statement above correct?  If I add a css file in the
> page,
> > and then contribute the same URL via AJAX, should it be added to the page
> a
> > second time?  You say no, but it appears that we've been testing to make
> > sure that it is.  I think there could be cases where it should - what if
> > that URL returns dynamic css (js, etc) that has changed since the page
> was
> > originally loaded?  It could be JSON, for instance, that has changed.
> > Second - there's some strange order of operations happening here that's
> > causing this.  I am about to walk out the door and haven't had a chance
> to
> > fully investigate why this is happening.  I wonder
> > why AjaxHeaderContribution2 overrides renderHead(HtmlHeaderContainer
> > container) rather than implementing the normal IHeaderContributor method.
> >  Anybody know off the top of their head?
> >
> > Jeremy
>