You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by Martin Grigorov <mg...@apache.org> on 2010/11/11 10:04:13 UTC
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/
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.
The same test is currently failing in 1.4 so if you think I am not correct
then revert the change in 1.5 as well.
On Thu, Nov 11, 2010 at 9:57 AM, <mg...@apache.org> wrote:
> Author: mgrigorov
> Date: Thu Nov 11 08:57:44 2010
> New Revision: 1033843
>
> URL: http://svn.apache.org/viewvc?rev=1033843&view=rev
> Log:
> WICKET-3149 Merge DecoratingHeaderResponse to trunk
>
> Fix the build (by optimizing imports).
>
> Modified:
>
> wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/DecoratingHeaderResponse.java
>
> wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/ResourceUtil.java
>
> wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/aggregation/AbstractDependencyRespectingResourceAggregatingHeaderResponse.java
>
> wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/aggregation/AbstractResourceAggregatingHeaderResponse.java
>
> wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/aggregation/ResourceReferenceAndStringData.java
>
> wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/dependencies/AbstractResourceDependentResourceReference.java
>
> wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/dependencies/IResourceReferenceDependencyConfigurationService.java
>
> wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/dependencies/ResourceDependentResourceReference.java
>
> wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/dependencies/ResourceReferenceDependencyInjectingHeaderResponse.java
>
> wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/filtering/AbstractHeaderResponseFilter.java
>
> wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/filtering/CssAcceptingHeaderResponseFilter.java
>
> wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/filtering/HeaderResponseContainerFilteringHeaderResponse.java
>
> wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/filtering/OppositeHeaderResponseFilter.java
>
> wicket/trunk/wicket/src/test/java/org/apache/wicket/ajax/AjaxHeaderContributionPage2_ajax_expected.html
>
> Modified:
> wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/DecoratingHeaderResponse.java
> URL:
> http://svn.apache.org/viewvc/wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/DecoratingHeaderResponse.java?rev=1033843&r1=1033842&r2=1033843&view=diff
>
> ==============================================================================
> ---
> wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/DecoratingHeaderResponse.java
> (original)
> +++
> wicket/trunk/wicket/src/main/java/org/apache/wicket/markup/html/DecoratingHeaderResponse.java
> Thu Nov 11 08:57:44 2010
> @@ -16,8 +16,8 @@
> */
> package org.apache.wicket.markup.html;
>
> -import org.apache.wicket.ResourceReference;
> -import org.apache.wicket.Response;
> +import org.apache.wicket.request.Response;
> +import org.apache.wicket.request.resource.ResourceReference;
>
> /**
> * This is simply a helper implementation of IHeaderResponse that really
> delegates all of its method
>
> Modified:
> wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/ResourceUtil.java
> URL:
> http://svn.apache.org/viewvc/wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/ResourceUtil.java?rev=1033843&r1=1033842&r2=1033843&view=diff
>
> ==============================================================================
> ---
> wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/ResourceUtil.java
> (original)
> +++
> wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/ResourceUtil.java
> Thu Nov 11 08:57:44 2010
> @@ -16,8 +16,8 @@
> */
> package org.apache.wicket.resource;
>
> -import org.apache.wicket.ResourceReference;
> import org.apache.wicket.markup.html.IHeaderResponse;
> +import org.apache.wicket.request.resource.ResourceReference;
> import org.apache.wicket.util.string.Strings;
>
> /**
>
> Modified:
> wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/aggregation/AbstractDependencyRespectingResourceAggregatingHeaderResponse.java
> URL:
> http://svn.apache.org/viewvc/wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/aggregation/AbstractDependencyRespectingResourceAggregatingHeaderResponse.java?rev=1033843&r1=1033842&r2=1033843&view=diff
>
> ==============================================================================
> ---
> wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/aggregation/AbstractDependencyRespectingResourceAggregatingHeaderResponse.java
> (original)
> +++
> wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/aggregation/AbstractDependencyRespectingResourceAggregatingHeaderResponse.java
> Thu Nov 11 08:57:44 2010
> @@ -18,8 +18,8 @@ package org.apache.wicket.resource.aggre
>
> import java.util.Set;
>
> -import org.apache.wicket.ResourceReference;
> import org.apache.wicket.markup.html.IHeaderResponse;
> +import org.apache.wicket.request.resource.ResourceReference;
> import
> org.apache.wicket.resource.dependencies.AbstractResourceDependentResourceReference;
> import
> org.apache.wicket.resource.dependencies.AbstractResourceDependentResourceReference.ResourceType;
>
>
> Modified:
> wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/aggregation/AbstractResourceAggregatingHeaderResponse.java
> URL:
> http://svn.apache.org/viewvc/wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/aggregation/AbstractResourceAggregatingHeaderResponse.java?rev=1033843&r1=1033842&r2=1033843&view=diff
>
> ==============================================================================
> ---
> wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/aggregation/AbstractResourceAggregatingHeaderResponse.java
> (original)
> +++
> wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/aggregation/AbstractResourceAggregatingHeaderResponse.java
> Thu Nov 11 08:57:44 2010
> @@ -25,10 +25,9 @@ import java.util.Set;
> import java.util.SortedMap;
> import java.util.TreeMap;
>
> -import org.apache.wicket.Resource;
> -import org.apache.wicket.ResourceReference;
> import org.apache.wicket.markup.html.DecoratingHeaderResponse;
> import org.apache.wicket.markup.html.IHeaderResponse;
> +import org.apache.wicket.request.resource.ResourceReference;
> import org.apache.wicket.resource.ResourceUtil;
>
> /**
>
> Modified:
> wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/aggregation/ResourceReferenceAndStringData.java
> URL:
> http://svn.apache.org/viewvc/wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/aggregation/ResourceReferenceAndStringData.java?rev=1033843&r1=1033842&r2=1033843&view=diff
>
> ==============================================================================
> ---
> wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/aggregation/ResourceReferenceAndStringData.java
> (original)
> +++
> wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/aggregation/ResourceReferenceAndStringData.java
> Thu Nov 11 08:57:44 2010
> @@ -16,7 +16,7 @@
> */
> package org.apache.wicket.resource.aggregation;
>
> -import org.apache.wicket.ResourceReference;
> +import org.apache.wicket.request.resource.ResourceReference;
>
> /**
> * A data holder built for the {@link
> AbstractResourceAggregatingHeaderResponse} that groups the
>
> Modified:
> wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/dependencies/AbstractResourceDependentResourceReference.java
> URL:
> http://svn.apache.org/viewvc/wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/dependencies/AbstractResourceDependentResourceReference.java?rev=1033843&r1=1033842&r2=1033843&view=diff
>
> ==============================================================================
> ---
> wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/dependencies/AbstractResourceDependentResourceReference.java
> (original)
> +++
> wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/dependencies/AbstractResourceDependentResourceReference.java
> Thu Nov 11 08:57:44 2010
> @@ -18,8 +18,8 @@ package org.apache.wicket.resource.depen
>
> import java.util.Locale;
>
> -import org.apache.wicket.ResourceReference;
> import org.apache.wicket.markup.html.IHeaderResponse;
> +import org.apache.wicket.request.resource.ResourceReference;
> import org.apache.wicket.util.string.Strings;
>
> /**
> @@ -63,11 +63,12 @@ public abstract class AbstractResourceDe
> * @param name
> * @param locale
> * @param style
> + * @param variation
> */
> public AbstractResourceDependentResourceReference(Class<?> scope,
> String name, Locale locale,
> - String style)
> + String style, String variation)
> {
> - super(scope, name, locale, style);
> + super(scope, name, locale, style, variation);
> }
>
> /**
>
> Modified:
> wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/dependencies/IResourceReferenceDependencyConfigurationService.java
> URL:
> http://svn.apache.org/viewvc/wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/dependencies/IResourceReferenceDependencyConfigurationService.java?rev=1033843&r1=1033842&r2=1033843&view=diff
>
> ==============================================================================
> ---
> wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/dependencies/IResourceReferenceDependencyConfigurationService.java
> (original)
> +++
> wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/dependencies/IResourceReferenceDependencyConfigurationService.java
> Thu Nov 11 08:57:44 2010
> @@ -16,7 +16,7 @@
> */
> package org.apache.wicket.resource.dependencies;
>
> -import org.apache.wicket.ResourceReference;
> +import org.apache.wicket.request.resource.ResourceReference;
>
> /**
> * You must implement this in order to use
> ResourceReferenceDependencyInjectingHeaderResponse. It is
>
> Modified:
> wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/dependencies/ResourceDependentResourceReference.java
> URL:
> http://svn.apache.org/viewvc/wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/dependencies/ResourceDependentResourceReference.java?rev=1033843&r1=1033842&r2=1033843&view=diff
>
> ==============================================================================
> ---
> wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/dependencies/ResourceDependentResourceReference.java
> (original)
> +++
> wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/dependencies/ResourceDependentResourceReference.java
> Thu Nov 11 08:57:44 2010
> @@ -18,6 +18,8 @@ package org.apache.wicket.resource.depen
>
> import java.util.Locale;
>
> +import org.apache.wicket.request.resource.IResource;
> +
> /**
> * A basic implementation of {@link
> AbstractResourceDependentResourceReference} that contains an
> * array of {@link AbstractResourceDependentResourceReference} dependencies
> that must be passed in
> @@ -42,9 +44,9 @@ public class ResourceDependentResourceRe
> * @param dependencies
> */
> public ResourceDependentResourceReference(Class<?> scope, String
> name, Locale locale,
> - String style, AbstractResourceDependentResourceReference[]
> dependencies)
> + String style, String variation,
> AbstractResourceDependentResourceReference[] dependencies)
> {
> - super(scope, name, locale, style);
> + super(scope, name, locale, style, variation);
> this.dependencies = dependencies;
> }
>
> @@ -81,4 +83,10 @@ public class ResourceDependentResourceRe
> return dependencies;
> }
>
> + @Override
> + public IResource getResource()
> + {
> + return null;
> + }
> +
> }
>
> Modified:
> wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/dependencies/ResourceReferenceDependencyInjectingHeaderResponse.java
> URL:
> http://svn.apache.org/viewvc/wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/dependencies/ResourceReferenceDependencyInjectingHeaderResponse.java?rev=1033843&r1=1033842&r2=1033843&view=diff
>
> ==============================================================================
> ---
> wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/dependencies/ResourceReferenceDependencyInjectingHeaderResponse.java
> (original)
> +++
> wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/dependencies/ResourceReferenceDependencyInjectingHeaderResponse.java
> Thu Nov 11 08:57:44 2010
> @@ -16,10 +16,10 @@
> */
> package org.apache.wicket.resource.dependencies;
>
> -import org.apache.wicket.ResourceReference;
> import org.apache.wicket.markup.html.DecoratingHeaderResponse;
> import org.apache.wicket.markup.html.IHeaderResponse;
> import org.apache.wicket.markup.html.IHeaderResponseDecorator;
> +import org.apache.wicket.request.resource.ResourceReference;
> import org.apache.wicket.resource.ResourceUtil;
> import
> org.apache.wicket.resource.dependencies.AbstractResourceDependentResourceReference.ResourceType;
>
>
> Modified:
> wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/filtering/AbstractHeaderResponseFilter.java
> URL:
> http://svn.apache.org/viewvc/wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/filtering/AbstractHeaderResponseFilter.java?rev=1033843&r1=1033842&r2=1033843&view=diff
>
> ==============================================================================
> ---
> wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/filtering/AbstractHeaderResponseFilter.java
> (original)
> +++
> wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/filtering/AbstractHeaderResponseFilter.java
> Thu Nov 11 08:57:44 2010
> @@ -16,7 +16,7 @@
> */
> package org.apache.wicket.resource.filtering;
>
> -import org.apache.wicket.ResourceReference;
> +import org.apache.wicket.request.resource.ResourceReference;
> import
> org.apache.wicket.resource.filtering.HeaderResponseContainerFilteringHeaderResponse.IHeaderResponseFilter;
>
> /**
>
> Modified:
> wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/filtering/CssAcceptingHeaderResponseFilter.java
> URL:
> http://svn.apache.org/viewvc/wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/filtering/CssAcceptingHeaderResponseFilter.java?rev=1033843&r1=1033842&r2=1033843&view=diff
>
> ==============================================================================
> ---
> wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/filtering/CssAcceptingHeaderResponseFilter.java
> (original)
> +++
> wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/filtering/CssAcceptingHeaderResponseFilter.java
> Thu Nov 11 08:57:44 2010
> @@ -16,7 +16,7 @@
> */
> package org.apache.wicket.resource.filtering;
>
> -import org.apache.wicket.ResourceReference;
> +import org.apache.wicket.request.resource.ResourceReference;
> import
> org.apache.wicket.resource.dependencies.AbstractResourceDependentResourceReference;
> import
> org.apache.wicket.resource.dependencies.AbstractResourceDependentResourceReference.ResourceType;
> import org.apache.wicket.util.string.Strings;
>
> Modified:
> wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/filtering/HeaderResponseContainerFilteringHeaderResponse.java
> URL:
> http://svn.apache.org/viewvc/wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/filtering/HeaderResponseContainerFilteringHeaderResponse.java?rev=1033843&r1=1033842&r2=1033843&view=diff
>
> ==============================================================================
> ---
> wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/filtering/HeaderResponseContainerFilteringHeaderResponse.java
> (original)
> +++
> wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/filtering/HeaderResponseContainerFilteringHeaderResponse.java
> Thu Nov 11 08:57:44 2010
> @@ -21,12 +21,12 @@ import java.util.Map;
>
> import org.apache.wicket.Component;
> import org.apache.wicket.MetaDataKey;
> -import org.apache.wicket.RequestCycle;
> -import org.apache.wicket.ResourceReference;
> -import org.apache.wicket.Response;
> import org.apache.wicket.ajax.AjaxRequestTarget;
> import org.apache.wicket.markup.html.DecoratingHeaderResponse;
> import org.apache.wicket.markup.html.IHeaderResponse;
> +import org.apache.wicket.request.Response;
> +import org.apache.wicket.request.cycle.RequestCycle;
> +import org.apache.wicket.request.resource.ResourceReference;
> import org.apache.wicket.response.StringResponse;
> import org.slf4j.Logger;
> import org.slf4j.LoggerFactory;
>
> Modified:
> wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/filtering/OppositeHeaderResponseFilter.java
> URL:
> http://svn.apache.org/viewvc/wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/filtering/OppositeHeaderResponseFilter.java?rev=1033843&r1=1033842&r2=1033843&view=diff
>
> ==============================================================================
> ---
> wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/filtering/OppositeHeaderResponseFilter.java
> (original)
> +++
> wicket/trunk/wicket/src/main/java/org/apache/wicket/resource/filtering/OppositeHeaderResponseFilter.java
> Thu Nov 11 08:57:44 2010
> @@ -16,7 +16,7 @@
> */
> package org.apache.wicket.resource.filtering;
>
> -import org.apache.wicket.ResourceReference;
> +import org.apache.wicket.request.resource.ResourceReference;
> import
> org.apache.wicket.resource.filtering.HeaderResponseContainerFilteringHeaderResponse.IHeaderResponseFilter;
>
> /**
>
> Modified:
> wicket/trunk/wicket/src/test/java/org/apache/wicket/ajax/AjaxHeaderContributionPage2_ajax_expected.html
> URL:
> http://svn.apache.org/viewvc/wicket/trunk/wicket/src/test/java/org/apache/wicket/ajax/AjaxHeaderContributionPage2_ajax_expected.html?rev=1033843&r1=1033842&r2=1033843&view=diff
>
> ==============================================================================
> ---
> wicket/trunk/wicket/src/test/java/org/apache/wicket/ajax/AjaxHeaderContributionPage2_ajax_expected.html
> (original)
> +++
> wicket/trunk/wicket/src/test/java/org/apache/wicket/ajax/AjaxHeaderContributionPage2_ajax_expected.html
> Thu Nov 11 08:57:44 2010
> @@ -9,7 +9,6 @@ test
> test
> </span>]]></component><header-contribution><![CDATA[<head xmlns:wicket="
> http://wicket.apache.org">
> <link href="../test2"/>
> -<script type="text/javascript" src="../javascripturlB"></script>
> </head>]]></header-contribution><component id="btest14" ><![CDATA[<span
> id="btest14">
> test
> </span>]]></component><component id="btest25" ><![CDATA[<span
> id="btest25">
>
>
>
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/
Posted by 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
>
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/
Posted by 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/
Posted by Peter Ertl <pe...@gmx.org>.
Ooops, I could not read the whole thread since I already deleted some of the previous mails :-(
Am 12.11.2010 um 11:36 schrieb Martin Grigorov:
> Hi Peter,
>
> I agree for renderXYZResourceReference(), but in this test it uses
> renderJavascript(String url).
>
> On Fri, Nov 12, 2010 at 11:12 AM, Peter Ertl <pe...@gmx.org> wrote:
>
>> Now guess what?!
>>
>> You already got timestamps in the url for free (I did some work on caching
>> recently :-)
>>
>> You just have to override
>>
>> ResourceReference#getLastModified()
>>
>> and return a non-null time value which will automatically become part of
>> the url...
>>
>> The url will look something like this
>>
>> <link rel="stylesheet" type="text/css"
>> href="wicket/resource/my.sample.pages.HomePage/foo-ts1289556202970.css" />
>>
>> With response headers something like:
>>
>> Expires: Sat, 12 Nov 2011 10:02:45 GMT
>> Cache-Control: public, max-age=31536000000
>>
>> So it's cached very aggresively
>>
>> Having different urls for the same file (via changing timestamps) will
>> guarantee it's not already cached when the content changes
>>
>> This behavior can be enabled/disable globally by
>> Settings#setUseTimestampOnResources()
>>
>> Also see the javadoc for some explanation
>>
>> I also wrote a WIKI entry:
>>
>> https://cwiki.apache.org/WICKET/caching-in-wicket-15.html
>>
>>
>> Sample code:
>>
>> add(new AbstractBehavior()
>> {
>> @Override
>> public void renderHead(IHeaderResponse response)
>> {
>> final HashMap<String,Object> vars = new
>> HashMap<String, Object>();
>> vars.put("url", "http://wicket.apache.org
>> ");
>> response.renderCSSReference(new
>> TextTemplateResourceReference(ShopHomePage.class, "foo.css", new
>> Model(vars))
>> {
>> @Override
>> public Time getLastModified()
>> {
>> // never cached on re-render
>> (however this is quite stupid)
>> // you should only change
>> the timestamp when the content (-> variables) change
>> return Time.now();
>> }
>> });
>> }
>> });
>>
>>
>>> The problem with reusing the same url for different request/responses is
>>> that the browser (private cache) or public caches can decide to use the
>>> cached response from previous request and thus the new JSON will never be
>>> used. Unless there is 'random' parameter in the URL which will solve the
>>> problem with #wasRendered().
>>
>>
>>
>>
>>
>> Am 12.11.2010 um 09:10 schrieb Martin Grigorov:
>>
>>> Hi Jeremy,
>>>
>>> On Fri, Nov 12, 2010 at 12:57 AM, 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 <mgrigorov@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:
>>>>
>>>> 1. 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.
>>>>
>>>> org.apache.wicket.markup.html.IHeaderResponse.wasRendered(Object) checks
>>> whether something is already rendered.
>>> Maybe my understanding is wrong and this method checks only for the
>> current
>>> request/response.
>>> wicket-ajax.js also does some filtering in that area but I have to
>> re-check
>>> the code before saying something.
>>> The problem with reusing the same url for different request/responses is
>>> that the browser (private cache) or public caches can decide to use the
>>> cached response from previous request and thus the new JSON will never be
>>> used. Unless there is 'random' parameter in the URL which will solve the
>>> problem with #wasRendered().
>>>
>>> About the test itself: for the Ajax request it returns "javascriptB".
>> What
>>> exactly is "B"?! Reading the test I cannot explain this right now.
>>>
>>>>
>>>> 1. 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/
Posted by Martin Grigorov <mg...@apache.org>.
Hi Peter,
I agree for renderXYZResourceReference(), but in this test it uses
renderJavascript(String url).
On Fri, Nov 12, 2010 at 11:12 AM, Peter Ertl <pe...@gmx.org> wrote:
> Now guess what?!
>
> You already got timestamps in the url for free (I did some work on caching
> recently :-)
>
> You just have to override
>
> ResourceReference#getLastModified()
>
> and return a non-null time value which will automatically become part of
> the url...
>
> The url will look something like this
>
> <link rel="stylesheet" type="text/css"
> href="wicket/resource/my.sample.pages.HomePage/foo-ts1289556202970.css" />
>
> With response headers something like:
>
> Expires: Sat, 12 Nov 2011 10:02:45 GMT
> Cache-Control: public, max-age=31536000000
>
> So it's cached very aggresively
>
> Having different urls for the same file (via changing timestamps) will
> guarantee it's not already cached when the content changes
>
> This behavior can be enabled/disable globally by
> Settings#setUseTimestampOnResources()
>
> Also see the javadoc for some explanation
>
> I also wrote a WIKI entry:
>
> https://cwiki.apache.org/WICKET/caching-in-wicket-15.html
>
>
> Sample code:
>
> add(new AbstractBehavior()
> {
> @Override
> public void renderHead(IHeaderResponse response)
> {
> final HashMap<String,Object> vars = new
> HashMap<String, Object>();
> vars.put("url", "http://wicket.apache.org
> ");
> response.renderCSSReference(new
> TextTemplateResourceReference(ShopHomePage.class, "foo.css", new
> Model(vars))
> {
> @Override
> public Time getLastModified()
> {
> // never cached on re-render
> (however this is quite stupid)
> // you should only change
> the timestamp when the content (-> variables) change
> return Time.now();
> }
> });
> }
> });
>
>
> > The problem with reusing the same url for different request/responses is
> > that the browser (private cache) or public caches can decide to use the
> > cached response from previous request and thus the new JSON will never be
> > used. Unless there is 'random' parameter in the URL which will solve the
> > problem with #wasRendered().
>
>
>
>
>
> Am 12.11.2010 um 09:10 schrieb Martin Grigorov:
>
> > Hi Jeremy,
> >
> > On Fri, Nov 12, 2010 at 12:57 AM, 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 <mgrigorov@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:
> >>
> >> 1. 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.
> >>
> >> org.apache.wicket.markup.html.IHeaderResponse.wasRendered(Object) checks
> > whether something is already rendered.
> > Maybe my understanding is wrong and this method checks only for the
> current
> > request/response.
> > wicket-ajax.js also does some filtering in that area but I have to
> re-check
> > the code before saying something.
> > The problem with reusing the same url for different request/responses is
> > that the browser (private cache) or public caches can decide to use the
> > cached response from previous request and thus the new JSON will never be
> > used. Unless there is 'random' parameter in the URL which will solve the
> > problem with #wasRendered().
> >
> > About the test itself: for the Ajax request it returns "javascriptB".
> What
> > exactly is "B"?! Reading the test I cannot explain this right now.
> >
> >>
> >> 1. 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/
Posted by Peter Ertl <pe...@gmx.org>.
Now guess what?!
You already got timestamps in the url for free (I did some work on caching recently :-)
You just have to override
ResourceReference#getLastModified()
and return a non-null time value which will automatically become part of the url...
The url will look something like this
<link rel="stylesheet" type="text/css" href="wicket/resource/my.sample.pages.HomePage/foo-ts1289556202970.css" />
With response headers something like:
Expires: Sat, 12 Nov 2011 10:02:45 GMT
Cache-Control: public, max-age=31536000000
So it's cached very aggresively
Having different urls for the same file (via changing timestamps) will guarantee it's not already cached when the content changes
This behavior can be enabled/disable globally by Settings#setUseTimestampOnResources()
Also see the javadoc for some explanation
I also wrote a WIKI entry:
https://cwiki.apache.org/WICKET/caching-in-wicket-15.html
Sample code:
add(new AbstractBehavior()
{
@Override
public void renderHead(IHeaderResponse response)
{
final HashMap<String,Object> vars = new HashMap<String, Object>();
vars.put("url", "http://wicket.apache.org");
response.renderCSSReference(new TextTemplateResourceReference(ShopHomePage.class, "foo.css", new Model(vars))
{
@Override
public Time getLastModified()
{
// never cached on re-render (however this is quite stupid)
// you should only change the timestamp when the content (-> variables) change
return Time.now();
}
});
}
});
> The problem with reusing the same url for different request/responses is
> that the browser (private cache) or public caches can decide to use the
> cached response from previous request and thus the new JSON will never be
> used. Unless there is 'random' parameter in the URL which will solve the
> problem with #wasRendered().
Am 12.11.2010 um 09:10 schrieb Martin Grigorov:
> Hi Jeremy,
>
> On Fri, Nov 12, 2010 at 12:57 AM, 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:
>>
>> 1. 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.
>>
>> org.apache.wicket.markup.html.IHeaderResponse.wasRendered(Object) checks
> whether something is already rendered.
> Maybe my understanding is wrong and this method checks only for the current
> request/response.
> wicket-ajax.js also does some filtering in that area but I have to re-check
> the code before saying something.
> The problem with reusing the same url for different request/responses is
> that the browser (private cache) or public caches can decide to use the
> cached response from previous request and thus the new JSON will never be
> used. Unless there is 'random' parameter in the URL which will solve the
> problem with #wasRendered().
>
> About the test itself: for the Ajax request it returns "javascriptB". What
> exactly is "B"?! Reading the test I cannot explain this right now.
>
>>
>> 1. 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/
Posted by Martin Grigorov <mg...@apache.org>.
Hi Jeremy,
On Fri, Nov 12, 2010 at 12:57 AM, 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:
>
> 1. 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.
>
> org.apache.wicket.markup.html.IHeaderResponse.wasRendered(Object) checks
whether something is already rendered.
Maybe my understanding is wrong and this method checks only for the current
request/response.
wicket-ajax.js also does some filtering in that area but I have to re-check
the code before saying something.
The problem with reusing the same url for different request/responses is
that the browser (private cache) or public caches can decide to use the
cached response from previous request and thus the new JSON will never be
used. Unless there is 'random' parameter in the URL which will solve the
problem with #wasRendered().
About the test itself: for the Ajax request it returns "javascriptB". What
exactly is "B"?! Reading the test I cannot explain this right now.
>
> 1. 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/
Posted by Jeremy Thomerson <jr...@apache.org>.
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:
1. 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.
2. 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/
Posted by Jeremy Thomerson <jr...@apache.org>.
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.
>
> The same test is currently failing in 1.4 so if you think I am not correct
> then revert the change in 1.5 as well.
>
Thanks Martin,
I don't know how I missed those imports. I went to bed last night right
after the 1.5 commit. I must have blindly merged the commit into 1.5 and
committed without testing. I thought for sure I'd pulled it up in Eclipse
and made sure everything merged correctly. I had Eclipse opened twice -
once for 1.4.x and once for trunk. Maybe I looked at the wrong one.
I don't know why that test started failing. These commits should not have
changed anything functionally, although they did fix one small bug in the
ajax header response (not closing the response after IHeaderContributor
traversal). I'll look at the test in 1.4.x and trunk.