You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Stefan Fußenegger <st...@gmx.at> on 2008/08/28 11:59:27 UTC
Discussion on "Wicket Interface Speed-Up"
I just finished the 4th and last entry of my series "Wicket Interface
Speed-Up" on my blog. To give a short summary: I investigated one of my apps
with YSlow and started optimizing it's interface rendering speed [1].
Especially Wicket's way of handling resources, i.e. JS and CSS files, causes
interfaces to load rather slowly. In my articles, I explain how to modify
the cache interval [2], how to mount resources with a version (e.g.
/css/all-1234.css) in order to use aggressive client-side caching (e.g.
resources expire after a year) [3]. Finally, I show how to merge resources
at application startup (using a class classed MergedResourceStream) to
reduce the number of resources a client has to download [4], including
code). I was able to increase interface loading times considerably, so it's
surely worth a look.
I feel that it would also be worth to discuss, whether this work could be
part of upcoming Wicket versions. For the time being I'd like to make the
code attached to [4] a wicketstuff project - sfussenegger needs commit
access ;) - and wait for your feedback.
The links:
[1] http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html
Wicket Interface Speed-Up
[2]
http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html
Wicket Interface Speed-Up: Modifying Expires and Cache-Control Headers
[3]
http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-caching.html
Wicket Interface Speed-Up: Caching Resources Forever
[4]
http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-merging.html
Wicket Interface Speed-Up: Merging Resources for Fewer HTTP Requests
-----
-------
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
--
View this message in context: http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19197540.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Discussion on "Wicket Interface Speed-Up"
Posted by Stefan Fußenegger <st...@gmx.at>.
you're right with the encapsulation, but i feel that resource versioning (and
aggressive client side caching) could be a nice addition to wicket. but
maybe sombody can think of another way to reduce (merge) resources without
breaking encapsulation ...
btw, resource versioning also works with wicket-ajax.js and wicket-event.js:
protected void init() {
final String version = getFrameworkSettings().getVersion();
final String suffix = ("n/a".equals(version) ? "" : "-" + version) +
".js";
getSharedResources().add(WicketAjaxReference.INSTANCE.getName(),
getResourceReference(WicketAjaxReference.class,
"wicket-ajax.js").getResource());
mountSharedResourceWithCaching("/scripts/wicket-ajax" + suffix,
WicketAjaxReference.INSTANCE.getSharedResourceKey());
getSharedResources().add(WicketEventReference.INSTANCE.getName(),
getResourceReference(WicketEventReference.class,
"wicket-event.js").getResource());
mountSharedResourceWithCaching("/scripts/wicket-event" + suffix,
WicketEventReference.INSTANCE.getSharedResourceKey());
}
// it's getting dirty ...
protected void mountSharedResourceWithCaching(final String path, final
String resourceKey) {
mount(new SharedResourceRequestTargetUrlCodingStrategy(path, resourceKey)
{
public IRequestTarget decode(final RequestParameters requestParameters)
{
final SharedResourceRequestTarget t = (SharedResourceRequestTarget)
super.decode(requestParameters);
if (t != null) {
// wrap target
return new IRequestTarget() {
public void detach(final RequestCycle requestCycle)
{t.detach(requestCycle);}
public void respond(final RequestCycle requestCycle) {
t.respond(requestCycle);
final WebResponse response = (WebResponse)
requestCycle.getResponse();
response.setDateHeader("Expires", System.currentTimeMillis() +
CACHE_DURATION * 1000L);
response.setHeader("Cache-Control", "max-age=" +
CACHE_DURATION);
}
};
} else {
return null;
}
}
});
}
regards
igor.vaynberg wrote:
>
> sfussenegger now has access to wicketstuff...
>
> i dont know which parts should go into wicket itself, i can tell you
> that the part where you merge the files by listing them out upfront is
> probably not going to make it in because it breaks encapsulation...
>
> -igor
>
> On Thu, Aug 28, 2008 at 2:59 AM, Stefan Fußenegger
> <st...@gmx.at> wrote:
>>
>> I just finished the 4th and last entry of my series "Wicket Interface
>> Speed-Up" on my blog. To give a short summary: I investigated one of my
>> apps
>> with YSlow and started optimizing it's interface rendering speed [1].
>> Especially Wicket's way of handling resources, i.e. JS and CSS files,
>> causes
>> interfaces to load rather slowly. In my articles, I explain how to modify
>> the cache interval [2], how to mount resources with a version (e.g.
>> /css/all-1234.css) in order to use aggressive client-side caching (e.g.
>> resources expire after a year) [3]. Finally, I show how to merge
>> resources
>> at application startup (using a class classed MergedResourceStream) to
>> reduce the number of resources a client has to download [4], including
>> code). I was able to increase interface loading times considerably, so
>> it's
>> surely worth a look.
>>
>> I feel that it would also be worth to discuss, whether this work could be
>> part of upcoming Wicket versions. For the time being I'd like to make the
>> code attached to [4] a wicketstuff project - sfussenegger needs commit
>> access ;) - and wait for your feedback.
>>
>> The links:
>> [1]
>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html
>> Wicket Interface Speed-Up
>> [2]
>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html
>> Wicket Interface Speed-Up: Modifying Expires and Cache-Control Headers
>> [3]
>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-caching.html
>> Wicket Interface Speed-Up: Caching Resources Forever
>> [4]
>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-merging.html
>> Wicket Interface Speed-Up: Merging Resources for Fewer HTTP Requests
>>
>> -----
>> -------
>> Stefan Fußenegger
>> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
>> --
>> View this message in context:
>> http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19197540.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
>
-----
-------
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
--
View this message in context: http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19214462.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Discussion on "Wicket Interface Speed-Up"
Posted by Jörn Zaefferer <jo...@googlemail.com>.
Ignoring the iPhone - not everyone has that as a target platform - the
bruteforce method of packaging everything into one file isn't that
bad. The initial bandwidth hit is outweighed be reducing requests to
one (or two, one js, one css file). That means the first page loads a
bit longer, which is normal in most cases anyway, while all other
pages loaded afterwards need no additional css/js at all, therefore
being potentially lightning fast.
Putting all page specific scripts into one file isn't trivial. I've
found that its very easy to handle by starting each script to check if
a certain dom element, selected via ID, exists. In my case, using
jQuery, something like this:
Subpage.js
jQuery(function($) {
if ($("#somePageSpecificId").length) {
// Subpage is active, do something
}
});
ID selectors should have no performance impact at all, as long as
there aren't thousands of them, which is very unlikely in this
scenario.
The same applies to CSS, where page specific styles are "namespaces"
with parent ids - same concept, easier to write.
If you *are* targeting the iPhone, you proably shouldn't load a full
library and tinymce and what not anyway...
Jörn
On Wed, Sep 3, 2008 at 4:21 PM, Matej Knopp <ma...@gmail.com> wrote:
> There is yet another thing to consider. Iphone doesn't cache resources
> bigger than 25kb (after unzipping). So instead of grouping files
> together sometimes it even might be appropriate to split them...
>
> -Matej
>
> On Wed, Sep 3, 2008 at 4:11 PM, <ig...@gmail.com> wrote:
>> It's not the pages that have these files. Let's say I have a page that
>> uses jquery and a textfield with a button that toggles tinymce.
>>
>> If we do what you say then there are two possible files: jquery and
>> jquery+tinymce.
>>
>> Than let's say I add Ajax to the page, now there are 6 possibilities
>> depending on which components are currently on the page.
>>
>> IMHO much cheaper to just cache jquery, tinymce, wicket-Ajax individually.
>>
>> -Igor
>> On 9/3/08, richardwilko <ri...@gmail.com> wrote:
>>>
>>> im not sure we could help in the cases where you have dynamic header
>>> contributors, like you say you would either have to specify them up front
>>> (ie add them into the page not the panel, breaking encapsulation) or just
>>> serve via the normal header contributor.
>>>
>>> But i dont see how this would result in many many large files. you would
>>> have a single file for the static stuff, and then each dynamic one would
>>> have its own file (assuming not specified up front). This would still bring
>>> down the total number.
>>>
>>> eg a page has 6 static js and 2 dynamic js which would get turned into 1
>>> static js and the same 2 dynamic js.
>>>
>>> cases where a component and resulting header contributers are added via ajax
>>> wouldnt be important for the initial page load speed anyway, as they are
>>> added after the page has loaded.
>>>
>>> Richard
>>>
>>>
>>> igor.vaynberg wrote:
>>>>
>>>> problem with this is that pages can have dynamic components which
>>>> dynamic header contributions.
>>>>
>>>> so either you have to somehow collect all possible header
>>>> contributions from all possible component combinations - breaking
>>>> encapsulation in the process, or you have to do what you do - ending
>>>> up with many many possible and big javascript files to serve to the
>>>> user.
>>>>
>>>> -igor
>>>>
>>>> On Tue, Sep 2, 2008 at 2:57 PM, richardwilko
>>>> <ri...@gmail.com> wrote:
>>>>>
>>>>> The problem of breaking encapsulation:
>>>>>
>>>>> I did some work on this problem on my own a few months ago, my solution
>>>>> was
>>>>> to use a header contrib manager, and instead of adding files with a
>>>>> header
>>>>> contributer i add them to the manager, then get a single contributer per
>>>>> page from the manger.
>>>>>
>>>>> for example in a panel you would do
>>>>>
>>>>> @Override
>>>>> protected void onBeforeRender() {
>>>>> super.onBeforeRender();
>>>>> ResourceReference rr = new ResourceReference(getClass(),
>>>>> "test.js");
>>>>> WicketApplication.get().getHcm().add(rr,
>>>>> getPage().getClass());
>>>>> }
>>>>>
>>>>> See how it uses getPage().getClass(), so the manager knows which class
>>>>> the
>>>>> panel is being added into
>>>>>
>>>>> then in the main page class
>>>>>
>>>>> @Override
>>>>> protected void onBeforeRender() {
>>>>> super.onBeforeRender();
>>>>>
>>>>>
>>>>> add(WicketApplication.get().getHcm().getHeaderContributor(getClass()));
>>>>> }
>>>>>
>>>>> since the manager knows all of the resources added for the page at this
>>>>> point, it is easy to compress them all together and serve a single file,
>>>>> and
>>>>> you dont have to list the files up front.
>>>>>
>>>>> What do you think of this idea?
>>>>>
>>>>> My code is here:
>>>>> http://www.nabble.com/file/p19279269/HeaderContribManagerTest.zip
>>>>> HeaderContribManagerTest.zip
>>>>>
>>>>> It still has bugs etc in it, and doesnt really work cos ive messed up the
>>>>> registerResource method, but you should be able to get the idea from it
>>>>>
>>>>> Richard
>>>>>
>>>>>
>>>>>
>>>>> -----
>>>>> http://www.richard-wilkinson.co.uk My blog:
>>>>> http://www.richard-wilkinson.co.uk
>>>>> --
>>>>> View this message in context:
>>>>> http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19279269.html
>>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>>>
>>>>
>>>>
>>>
>>>
>>> -----
>>> http://www.richard-wilkinson.co.uk My blog:
>>> http://www.richard-wilkinson.co.uk
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19289766.html
>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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: Discussion on "Wicket Interface Speed-Up"
Posted by Matej Knopp <ma...@gmail.com>.
There is yet another thing to consider. Iphone doesn't cache resources
bigger than 25kb (after unzipping). So instead of grouping files
together sometimes it even might be appropriate to split them...
-Matej
On Wed, Sep 3, 2008 at 4:11 PM, <ig...@gmail.com> wrote:
> It's not the pages that have these files. Let's say I have a page that
> uses jquery and a textfield with a button that toggles tinymce.
>
> If we do what you say then there are two possible files: jquery and
> jquery+tinymce.
>
> Than let's say I add Ajax to the page, now there are 6 possibilities
> depending on which components are currently on the page.
>
> IMHO much cheaper to just cache jquery, tinymce, wicket-Ajax individually.
>
> -Igor
> On 9/3/08, richardwilko <ri...@gmail.com> wrote:
>>
>> im not sure we could help in the cases where you have dynamic header
>> contributors, like you say you would either have to specify them up front
>> (ie add them into the page not the panel, breaking encapsulation) or just
>> serve via the normal header contributor.
>>
>> But i dont see how this would result in many many large files. you would
>> have a single file for the static stuff, and then each dynamic one would
>> have its own file (assuming not specified up front). This would still bring
>> down the total number.
>>
>> eg a page has 6 static js and 2 dynamic js which would get turned into 1
>> static js and the same 2 dynamic js.
>>
>> cases where a component and resulting header contributers are added via ajax
>> wouldnt be important for the initial page load speed anyway, as they are
>> added after the page has loaded.
>>
>> Richard
>>
>>
>> igor.vaynberg wrote:
>>>
>>> problem with this is that pages can have dynamic components which
>>> dynamic header contributions.
>>>
>>> so either you have to somehow collect all possible header
>>> contributions from all possible component combinations - breaking
>>> encapsulation in the process, or you have to do what you do - ending
>>> up with many many possible and big javascript files to serve to the
>>> user.
>>>
>>> -igor
>>>
>>> On Tue, Sep 2, 2008 at 2:57 PM, richardwilko
>>> <ri...@gmail.com> wrote:
>>>>
>>>> The problem of breaking encapsulation:
>>>>
>>>> I did some work on this problem on my own a few months ago, my solution
>>>> was
>>>> to use a header contrib manager, and instead of adding files with a
>>>> header
>>>> contributer i add them to the manager, then get a single contributer per
>>>> page from the manger.
>>>>
>>>> for example in a panel you would do
>>>>
>>>> @Override
>>>> protected void onBeforeRender() {
>>>> super.onBeforeRender();
>>>> ResourceReference rr = new ResourceReference(getClass(),
>>>> "test.js");
>>>> WicketApplication.get().getHcm().add(rr,
>>>> getPage().getClass());
>>>> }
>>>>
>>>> See how it uses getPage().getClass(), so the manager knows which class
>>>> the
>>>> panel is being added into
>>>>
>>>> then in the main page class
>>>>
>>>> @Override
>>>> protected void onBeforeRender() {
>>>> super.onBeforeRender();
>>>>
>>>>
>>>> add(WicketApplication.get().getHcm().getHeaderContributor(getClass()));
>>>> }
>>>>
>>>> since the manager knows all of the resources added for the page at this
>>>> point, it is easy to compress them all together and serve a single file,
>>>> and
>>>> you dont have to list the files up front.
>>>>
>>>> What do you think of this idea?
>>>>
>>>> My code is here:
>>>> http://www.nabble.com/file/p19279269/HeaderContribManagerTest.zip
>>>> HeaderContribManagerTest.zip
>>>>
>>>> It still has bugs etc in it, and doesnt really work cos ive messed up the
>>>> registerResource method, but you should be able to get the idea from it
>>>>
>>>> Richard
>>>>
>>>>
>>>>
>>>> -----
>>>> http://www.richard-wilkinson.co.uk My blog:
>>>> http://www.richard-wilkinson.co.uk
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19279269.html
>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>>
>>>
>>
>>
>> -----
>> http://www.richard-wilkinson.co.uk My blog:
>> http://www.richard-wilkinson.co.uk
>> --
>> View this message in context:
>> http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19289766.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> 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: Discussion on "Wicket Interface Speed-Up"
Posted by Martijn Dashorst <ma...@gmail.com>.
in html:
<html>
<head>
<wicket:head>
<wicket:link>
<link href="MyComponent.css" rel="stylesheet" />
<script src="MyComponent.js" type="text/javascript">
</script>
</wicket:link>
</wicket:head>
</head>
<body>
<wicket:panel>
some foo....
</wicket:panel>
</body>
</html>
Which has the added bonus of being previewable.
Martijn
On Wed, Sep 3, 2008 at 5:34 PM, Al Maw <wi...@almaw.com> wrote:
> Hmmm. As you say, there's no easy one-size-fits-all.
> There is an obvious improvement you could make, though. All JS/CSS
> contributions initially rendered on the home page could be batched up. This
> will typically provide the biggest improvement anyway. You could then keep a
> reference to this batch, and use it instead of individually including any of
> these constituent contributions elsewhere.
>
> This would also give fairly intuitive behaviour - if you want to pre-load
> your JS/CSS in a single batch, just add the headercontributors to your home
> page, and Wicket will figure it out.
>
> I've long hated having to specify the component class in header
> contributors, as 99% of the time the resources live in the same package (or
> in a subpackage) as the component they belong to.
>
> I'd even go so far as to remove the need for HeaderContributor code entirely
> in 80% of the cases.
> Wicket could automatically pick up css and js files that are named the same
> as your component.
> MyComponent.java
> MyComponent.html
> MyComponent.properties
> So why not:
> MyComponent.css
> MyComponent.js
> ?
>
> Heck, you could even include i18n for dealing with language-specific layout
> issues:
> MyComponent_jp.css
>
> Regards,
>
> Al
>
> 2008/9/3 richardwilko <ri...@gmail.com>
>
>>
>> I see your point, essentially we have 1 (relativity large) bundle file per
>> page, and if you have 5 pages which use jquery, tinymce and ajax then you
>> are worse off, since the normal way you would have already cached the 3
>> individual files (this is what you meant right?)
>>
>> Maybe there is some way to automatically work out the best bundles to
>> create
>> depending on usage, so dont create bundles based on page, but based on
>> contents?
>>
>> I think the real answer is that everyones usage is different and what is
>> good for one system isn't good for another.
>>
>>
>> igor.vaynberg wrote:
>> >
>> > It's not the pages that have these files. Let's say I have a page that
>> > uses jquery and a textfield with a button that toggles tinymce.
>> >
>> > If we do what you say then there are two possible files: jquery and
>> > jquery+tinymce.
>> >
>> > Than let's say I add Ajax to the page, now there are 6 possibilities
>> > depending on which components are currently on the page.
>> >
>> > IMHO much cheaper to just cache jquery, tinymce, wicket-Ajax
>> individually.
>> >
>> > -Igor
>> > On 9/3/08, richardwilko <ri...@gmail.com> wrote:
>> >>
>> >> im not sure we could help in the cases where you have dynamic header
>> >> contributors, like you say you would either have to specify them up
>> front
>> >> (ie add them into the page not the panel, breaking encapsulation) or
>> just
>> >> serve via the normal header contributor.
>> >>
>> >> But i dont see how this would result in many many large files. you
>> would
>> >> have a single file for the static stuff, and then each dynamic one would
>> >> have its own file (assuming not specified up front). This would still
>> >> bring
>> >> down the total number.
>> >>
>> >> eg a page has 6 static js and 2 dynamic js which would get turned into 1
>> >> static js and the same 2 dynamic js.
>> >>
>> >> cases where a component and resulting header contributers are added via
>> >> ajax
>> >> wouldnt be important for the initial page load speed anyway, as they are
>> >> added after the page has loaded.
>> >>
>> >> Richard
>> >>
>> >>
>> >> igor.vaynberg wrote:
>> >>>
>> >>> problem with this is that pages can have dynamic components which
>> >>> dynamic header contributions.
>> >>>
>> >>> so either you have to somehow collect all possible header
>> >>> contributions from all possible component combinations - breaking
>> >>> encapsulation in the process, or you have to do what you do - ending
>> >>> up with many many possible and big javascript files to serve to the
>> >>> user.
>> >>>
>> >>> -igor
>> >>>
>> >>> On Tue, Sep 2, 2008 at 2:57 PM, richardwilko
>> >>> <ri...@gmail.com> wrote:
>> >>>>
>> >>>> The problem of breaking encapsulation:
>> >>>>
>> >>>> I did some work on this problem on my own a few months ago, my
>> solution
>> >>>> was
>> >>>> to use a header contrib manager, and instead of adding files with a
>> >>>> header
>> >>>> contributer i add them to the manager, then get a single contributer
>> >>>> per
>> >>>> page from the manger.
>> >>>>
>> >>>> for example in a panel you would do
>> >>>>
>> >>>> @Override
>> >>>> protected void onBeforeRender() {
>> >>>> super.onBeforeRender();
>> >>>> ResourceReference rr = new
>> ResourceReference(getClass(),
>> >>>> "test.js");
>> >>>> WicketApplication.get().getHcm().add(rr,
>> >>>> getPage().getClass());
>> >>>> }
>> >>>>
>> >>>> See how it uses getPage().getClass(), so the manager knows which class
>> >>>> the
>> >>>> panel is being added into
>> >>>>
>> >>>> then in the main page class
>> >>>>
>> >>>> @Override
>> >>>> protected void onBeforeRender() {
>> >>>> super.onBeforeRender();
>> >>>>
>> >>>>
>> >>>>
>> add(WicketApplication.get().getHcm().getHeaderContributor(getClass()));
>> >>>> }
>> >>>>
>> >>>> since the manager knows all of the resources added for the page at
>> this
>> >>>> point, it is easy to compress them all together and serve a single
>> >>>> file,
>> >>>> and
>> >>>> you dont have to list the files up front.
>> >>>>
>> >>>> What do you think of this idea?
>> >>>>
>> >>>> My code is here:
>> >>>> http://www.nabble.com/file/p19279269/HeaderContribManagerTest.zip
>> >>>> HeaderContribManagerTest.zip
>> >>>>
>> >>>> It still has bugs etc in it, and doesnt really work cos ive messed up
>> >>>> the
>> >>>> registerResource method, but you should be able to get the idea from
>> it
>> >>>>
>> >>>> Richard
>> >>>>
>> >>>>
>> >>>>
>> >>>> -----
>> >>>> http://www.richard-wilkinson.co.uk My blog:
>> >>>> http://www.richard-wilkinson.co.uk
>> >>>> --
>> >>>> View this message in context:
>> >>>>
>> http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19279269.html
>> >>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>> >>>>
>> >>>>
>> >>>> ---------------------------------------------------------------------
>> >>>> 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
>> >>>
>> >>>
>> >>>
>> >>
>> >>
>> >> -----
>> >> http://www.richard-wilkinson.co.uk My blog:
>> >> http://www.richard-wilkinson.co.uk
>> >> --
>> >> View this message in context:
>> >>
>> http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19289766.html
>> >> Sent from the Wicket - User mailing list archive at Nabble.com.
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> 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
>> >
>> >
>> >
>>
>>
>> -----
>> http://www.richard-wilkinson.co.uk My blog:
>> http://www.richard-wilkinson.co.uk
>> --
>> View this message in context:
>> http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19290662.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.4 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Discussion on "Wicket Interface Speed-Up"
Posted by John Krasnay <jo...@krasnay.ca>.
On Wed, Sep 03, 2008 at 04:34:34PM +0100, Al Maw wrote:
>
> I'd even go so far as to remove the need for HeaderContributor code entirely
> in 80% of the cases.
> Wicket could automatically pick up css and js files that are named the same
> as your component.
> MyComponent.java
> MyComponent.html
> MyComponent.properties
> So why not:
> MyComponent.css
> MyComponent.js
> ?
>
> Heck, you could even include i18n for dealing with language-specific layout
> issues:
> MyComponent_jp.css
>
> Regards,
>
> Al
+1. I even tried this once since it seemed like such an intuitive thing.
jk
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Discussion on "Wicket Interface Speed-Up"
Posted by Al Maw <wi...@almaw.com>.
Hmmm. As you say, there's no easy one-size-fits-all.
There is an obvious improvement you could make, though. All JS/CSS
contributions initially rendered on the home page could be batched up. This
will typically provide the biggest improvement anyway. You could then keep a
reference to this batch, and use it instead of individually including any of
these constituent contributions elsewhere.
This would also give fairly intuitive behaviour - if you want to pre-load
your JS/CSS in a single batch, just add the headercontributors to your home
page, and Wicket will figure it out.
I've long hated having to specify the component class in header
contributors, as 99% of the time the resources live in the same package (or
in a subpackage) as the component they belong to.
I'd even go so far as to remove the need for HeaderContributor code entirely
in 80% of the cases.
Wicket could automatically pick up css and js files that are named the same
as your component.
MyComponent.java
MyComponent.html
MyComponent.properties
So why not:
MyComponent.css
MyComponent.js
?
Heck, you could even include i18n for dealing with language-specific layout
issues:
MyComponent_jp.css
Regards,
Al
2008/9/3 richardwilko <ri...@gmail.com>
>
> I see your point, essentially we have 1 (relativity large) bundle file per
> page, and if you have 5 pages which use jquery, tinymce and ajax then you
> are worse off, since the normal way you would have already cached the 3
> individual files (this is what you meant right?)
>
> Maybe there is some way to automatically work out the best bundles to
> create
> depending on usage, so dont create bundles based on page, but based on
> contents?
>
> I think the real answer is that everyones usage is different and what is
> good for one system isn't good for another.
>
>
> igor.vaynberg wrote:
> >
> > It's not the pages that have these files. Let's say I have a page that
> > uses jquery and a textfield with a button that toggles tinymce.
> >
> > If we do what you say then there are two possible files: jquery and
> > jquery+tinymce.
> >
> > Than let's say I add Ajax to the page, now there are 6 possibilities
> > depending on which components are currently on the page.
> >
> > IMHO much cheaper to just cache jquery, tinymce, wicket-Ajax
> individually.
> >
> > -Igor
> > On 9/3/08, richardwilko <ri...@gmail.com> wrote:
> >>
> >> im not sure we could help in the cases where you have dynamic header
> >> contributors, like you say you would either have to specify them up
> front
> >> (ie add them into the page not the panel, breaking encapsulation) or
> just
> >> serve via the normal header contributor.
> >>
> >> But i dont see how this would result in many many large files. you
> would
> >> have a single file for the static stuff, and then each dynamic one would
> >> have its own file (assuming not specified up front). This would still
> >> bring
> >> down the total number.
> >>
> >> eg a page has 6 static js and 2 dynamic js which would get turned into 1
> >> static js and the same 2 dynamic js.
> >>
> >> cases where a component and resulting header contributers are added via
> >> ajax
> >> wouldnt be important for the initial page load speed anyway, as they are
> >> added after the page has loaded.
> >>
> >> Richard
> >>
> >>
> >> igor.vaynberg wrote:
> >>>
> >>> problem with this is that pages can have dynamic components which
> >>> dynamic header contributions.
> >>>
> >>> so either you have to somehow collect all possible header
> >>> contributions from all possible component combinations - breaking
> >>> encapsulation in the process, or you have to do what you do - ending
> >>> up with many many possible and big javascript files to serve to the
> >>> user.
> >>>
> >>> -igor
> >>>
> >>> On Tue, Sep 2, 2008 at 2:57 PM, richardwilko
> >>> <ri...@gmail.com> wrote:
> >>>>
> >>>> The problem of breaking encapsulation:
> >>>>
> >>>> I did some work on this problem on my own a few months ago, my
> solution
> >>>> was
> >>>> to use a header contrib manager, and instead of adding files with a
> >>>> header
> >>>> contributer i add them to the manager, then get a single contributer
> >>>> per
> >>>> page from the manger.
> >>>>
> >>>> for example in a panel you would do
> >>>>
> >>>> @Override
> >>>> protected void onBeforeRender() {
> >>>> super.onBeforeRender();
> >>>> ResourceReference rr = new
> ResourceReference(getClass(),
> >>>> "test.js");
> >>>> WicketApplication.get().getHcm().add(rr,
> >>>> getPage().getClass());
> >>>> }
> >>>>
> >>>> See how it uses getPage().getClass(), so the manager knows which class
> >>>> the
> >>>> panel is being added into
> >>>>
> >>>> then in the main page class
> >>>>
> >>>> @Override
> >>>> protected void onBeforeRender() {
> >>>> super.onBeforeRender();
> >>>>
> >>>>
> >>>>
> add(WicketApplication.get().getHcm().getHeaderContributor(getClass()));
> >>>> }
> >>>>
> >>>> since the manager knows all of the resources added for the page at
> this
> >>>> point, it is easy to compress them all together and serve a single
> >>>> file,
> >>>> and
> >>>> you dont have to list the files up front.
> >>>>
> >>>> What do you think of this idea?
> >>>>
> >>>> My code is here:
> >>>> http://www.nabble.com/file/p19279269/HeaderContribManagerTest.zip
> >>>> HeaderContribManagerTest.zip
> >>>>
> >>>> It still has bugs etc in it, and doesnt really work cos ive messed up
> >>>> the
> >>>> registerResource method, but you should be able to get the idea from
> it
> >>>>
> >>>> Richard
> >>>>
> >>>>
> >>>>
> >>>> -----
> >>>> http://www.richard-wilkinson.co.uk My blog:
> >>>> http://www.richard-wilkinson.co.uk
> >>>> --
> >>>> View this message in context:
> >>>>
> http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19279269.html
> >>>> Sent from the Wicket - User mailing list archive at Nabble.com.
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> 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
> >>>
> >>>
> >>>
> >>
> >>
> >> -----
> >> http://www.richard-wilkinson.co.uk My blog:
> >> http://www.richard-wilkinson.co.uk
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19289766.html
> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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
> >
> >
> >
>
>
> -----
> http://www.richard-wilkinson.co.uk My blog:
> http://www.richard-wilkinson.co.uk
> --
> View this message in context:
> http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19290662.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Discussion on "Wicket Interface Speed-Up"
Posted by richardwilko <ri...@gmail.com>.
I see your point, essentially we have 1 (relativity large) bundle file per
page, and if you have 5 pages which use jquery, tinymce and ajax then you
are worse off, since the normal way you would have already cached the 3
individual files (this is what you meant right?)
Maybe there is some way to automatically work out the best bundles to create
depending on usage, so dont create bundles based on page, but based on
contents?
I think the real answer is that everyones usage is different and what is
good for one system isn't good for another.
igor.vaynberg wrote:
>
> It's not the pages that have these files. Let's say I have a page that
> uses jquery and a textfield with a button that toggles tinymce.
>
> If we do what you say then there are two possible files: jquery and
> jquery+tinymce.
>
> Than let's say I add Ajax to the page, now there are 6 possibilities
> depending on which components are currently on the page.
>
> IMHO much cheaper to just cache jquery, tinymce, wicket-Ajax individually.
>
> -Igor
> On 9/3/08, richardwilko <ri...@gmail.com> wrote:
>>
>> im not sure we could help in the cases where you have dynamic header
>> contributors, like you say you would either have to specify them up front
>> (ie add them into the page not the panel, breaking encapsulation) or just
>> serve via the normal header contributor.
>>
>> But i dont see how this would result in many many large files. you would
>> have a single file for the static stuff, and then each dynamic one would
>> have its own file (assuming not specified up front). This would still
>> bring
>> down the total number.
>>
>> eg a page has 6 static js and 2 dynamic js which would get turned into 1
>> static js and the same 2 dynamic js.
>>
>> cases where a component and resulting header contributers are added via
>> ajax
>> wouldnt be important for the initial page load speed anyway, as they are
>> added after the page has loaded.
>>
>> Richard
>>
>>
>> igor.vaynberg wrote:
>>>
>>> problem with this is that pages can have dynamic components which
>>> dynamic header contributions.
>>>
>>> so either you have to somehow collect all possible header
>>> contributions from all possible component combinations - breaking
>>> encapsulation in the process, or you have to do what you do - ending
>>> up with many many possible and big javascript files to serve to the
>>> user.
>>>
>>> -igor
>>>
>>> On Tue, Sep 2, 2008 at 2:57 PM, richardwilko
>>> <ri...@gmail.com> wrote:
>>>>
>>>> The problem of breaking encapsulation:
>>>>
>>>> I did some work on this problem on my own a few months ago, my solution
>>>> was
>>>> to use a header contrib manager, and instead of adding files with a
>>>> header
>>>> contributer i add them to the manager, then get a single contributer
>>>> per
>>>> page from the manger.
>>>>
>>>> for example in a panel you would do
>>>>
>>>> @Override
>>>> protected void onBeforeRender() {
>>>> super.onBeforeRender();
>>>> ResourceReference rr = new ResourceReference(getClass(),
>>>> "test.js");
>>>> WicketApplication.get().getHcm().add(rr,
>>>> getPage().getClass());
>>>> }
>>>>
>>>> See how it uses getPage().getClass(), so the manager knows which class
>>>> the
>>>> panel is being added into
>>>>
>>>> then in the main page class
>>>>
>>>> @Override
>>>> protected void onBeforeRender() {
>>>> super.onBeforeRender();
>>>>
>>>>
>>>> add(WicketApplication.get().getHcm().getHeaderContributor(getClass()));
>>>> }
>>>>
>>>> since the manager knows all of the resources added for the page at this
>>>> point, it is easy to compress them all together and serve a single
>>>> file,
>>>> and
>>>> you dont have to list the files up front.
>>>>
>>>> What do you think of this idea?
>>>>
>>>> My code is here:
>>>> http://www.nabble.com/file/p19279269/HeaderContribManagerTest.zip
>>>> HeaderContribManagerTest.zip
>>>>
>>>> It still has bugs etc in it, and doesnt really work cos ive messed up
>>>> the
>>>> registerResource method, but you should be able to get the idea from it
>>>>
>>>> Richard
>>>>
>>>>
>>>>
>>>> -----
>>>> http://www.richard-wilkinson.co.uk My blog:
>>>> http://www.richard-wilkinson.co.uk
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19279269.html
>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>>
>>>
>>
>>
>> -----
>> http://www.richard-wilkinson.co.uk My blog:
>> http://www.richard-wilkinson.co.uk
>> --
>> View this message in context:
>> http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19289766.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
>
-----
http://www.richard-wilkinson.co.uk My blog:
http://www.richard-wilkinson.co.uk
--
View this message in context: http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19290662.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Discussion on "Wicket Interface Speed-Up"
Posted by ig...@gmail.com.
It's not the pages that have these files. Let's say I have a page that
uses jquery and a textfield with a button that toggles tinymce.
If we do what you say then there are two possible files: jquery and
jquery+tinymce.
Than let's say I add Ajax to the page, now there are 6 possibilities
depending on which components are currently on the page.
IMHO much cheaper to just cache jquery, tinymce, wicket-Ajax individually.
-Igor
On 9/3/08, richardwilko <ri...@gmail.com> wrote:
>
> im not sure we could help in the cases where you have dynamic header
> contributors, like you say you would either have to specify them up front
> (ie add them into the page not the panel, breaking encapsulation) or just
> serve via the normal header contributor.
>
> But i dont see how this would result in many many large files. you would
> have a single file for the static stuff, and then each dynamic one would
> have its own file (assuming not specified up front). This would still bring
> down the total number.
>
> eg a page has 6 static js and 2 dynamic js which would get turned into 1
> static js and the same 2 dynamic js.
>
> cases where a component and resulting header contributers are added via ajax
> wouldnt be important for the initial page load speed anyway, as they are
> added after the page has loaded.
>
> Richard
>
>
> igor.vaynberg wrote:
>>
>> problem with this is that pages can have dynamic components which
>> dynamic header contributions.
>>
>> so either you have to somehow collect all possible header
>> contributions from all possible component combinations - breaking
>> encapsulation in the process, or you have to do what you do - ending
>> up with many many possible and big javascript files to serve to the
>> user.
>>
>> -igor
>>
>> On Tue, Sep 2, 2008 at 2:57 PM, richardwilko
>> <ri...@gmail.com> wrote:
>>>
>>> The problem of breaking encapsulation:
>>>
>>> I did some work on this problem on my own a few months ago, my solution
>>> was
>>> to use a header contrib manager, and instead of adding files with a
>>> header
>>> contributer i add them to the manager, then get a single contributer per
>>> page from the manger.
>>>
>>> for example in a panel you would do
>>>
>>> @Override
>>> protected void onBeforeRender() {
>>> super.onBeforeRender();
>>> ResourceReference rr = new ResourceReference(getClass(),
>>> "test.js");
>>> WicketApplication.get().getHcm().add(rr,
>>> getPage().getClass());
>>> }
>>>
>>> See how it uses getPage().getClass(), so the manager knows which class
>>> the
>>> panel is being added into
>>>
>>> then in the main page class
>>>
>>> @Override
>>> protected void onBeforeRender() {
>>> super.onBeforeRender();
>>>
>>>
>>> add(WicketApplication.get().getHcm().getHeaderContributor(getClass()));
>>> }
>>>
>>> since the manager knows all of the resources added for the page at this
>>> point, it is easy to compress them all together and serve a single file,
>>> and
>>> you dont have to list the files up front.
>>>
>>> What do you think of this idea?
>>>
>>> My code is here:
>>> http://www.nabble.com/file/p19279269/HeaderContribManagerTest.zip
>>> HeaderContribManagerTest.zip
>>>
>>> It still has bugs etc in it, and doesnt really work cos ive messed up the
>>> registerResource method, but you should be able to get the idea from it
>>>
>>> Richard
>>>
>>>
>>>
>>> -----
>>> http://www.richard-wilkinson.co.uk My blog:
>>> http://www.richard-wilkinson.co.uk
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19279269.html
>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>>
>
>
> -----
> http://www.richard-wilkinson.co.uk My blog:
> http://www.richard-wilkinson.co.uk
> --
> View this message in context:
> http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19289766.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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: Discussion on "Wicket Interface Speed-Up"
Posted by richardwilko <ri...@gmail.com>.
im not sure we could help in the cases where you have dynamic header
contributors, like you say you would either have to specify them up front
(ie add them into the page not the panel, breaking encapsulation) or just
serve via the normal header contributor.
But i dont see how this would result in many many large files. you would
have a single file for the static stuff, and then each dynamic one would
have its own file (assuming not specified up front). This would still bring
down the total number.
eg a page has 6 static js and 2 dynamic js which would get turned into 1
static js and the same 2 dynamic js.
cases where a component and resulting header contributers are added via ajax
wouldnt be important for the initial page load speed anyway, as they are
added after the page has loaded.
Richard
igor.vaynberg wrote:
>
> problem with this is that pages can have dynamic components which
> dynamic header contributions.
>
> so either you have to somehow collect all possible header
> contributions from all possible component combinations - breaking
> encapsulation in the process, or you have to do what you do - ending
> up with many many possible and big javascript files to serve to the
> user.
>
> -igor
>
> On Tue, Sep 2, 2008 at 2:57 PM, richardwilko
> <ri...@gmail.com> wrote:
>>
>> The problem of breaking encapsulation:
>>
>> I did some work on this problem on my own a few months ago, my solution
>> was
>> to use a header contrib manager, and instead of adding files with a
>> header
>> contributer i add them to the manager, then get a single contributer per
>> page from the manger.
>>
>> for example in a panel you would do
>>
>> @Override
>> protected void onBeforeRender() {
>> super.onBeforeRender();
>> ResourceReference rr = new ResourceReference(getClass(),
>> "test.js");
>> WicketApplication.get().getHcm().add(rr,
>> getPage().getClass());
>> }
>>
>> See how it uses getPage().getClass(), so the manager knows which class
>> the
>> panel is being added into
>>
>> then in the main page class
>>
>> @Override
>> protected void onBeforeRender() {
>> super.onBeforeRender();
>>
>>
>> add(WicketApplication.get().getHcm().getHeaderContributor(getClass()));
>> }
>>
>> since the manager knows all of the resources added for the page at this
>> point, it is easy to compress them all together and serve a single file,
>> and
>> you dont have to list the files up front.
>>
>> What do you think of this idea?
>>
>> My code is here:
>> http://www.nabble.com/file/p19279269/HeaderContribManagerTest.zip
>> HeaderContribManagerTest.zip
>>
>> It still has bugs etc in it, and doesnt really work cos ive messed up the
>> registerResource method, but you should be able to get the idea from it
>>
>> Richard
>>
>>
>>
>> -----
>> http://www.richard-wilkinson.co.uk My blog:
>> http://www.richard-wilkinson.co.uk
>> --
>> View this message in context:
>> http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19279269.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
>
-----
http://www.richard-wilkinson.co.uk My blog:
http://www.richard-wilkinson.co.uk
--
View this message in context: http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19289766.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Discussion on "Wicket Interface Speed-Up"
Posted by Igor Vaynberg <ig...@gmail.com>.
problem with this is that pages can have dynamic components which
dynamic header contributions.
so either you have to somehow collect all possible header
contributions from all possible component combinations - breaking
encapsulation in the process, or you have to do what you do - ending
up with many many possible and big javascript files to serve to the
user.
-igor
On Tue, Sep 2, 2008 at 2:57 PM, richardwilko
<ri...@gmail.com> wrote:
>
> The problem of breaking encapsulation:
>
> I did some work on this problem on my own a few months ago, my solution was
> to use a header contrib manager, and instead of adding files with a header
> contributer i add them to the manager, then get a single contributer per
> page from the manger.
>
> for example in a panel you would do
>
> @Override
> protected void onBeforeRender() {
> super.onBeforeRender();
> ResourceReference rr = new ResourceReference(getClass(), "test.js");
> WicketApplication.get().getHcm().add(rr, getPage().getClass());
> }
>
> See how it uses getPage().getClass(), so the manager knows which class the
> panel is being added into
>
> then in the main page class
>
> @Override
> protected void onBeforeRender() {
> super.onBeforeRender();
>
> add(WicketApplication.get().getHcm().getHeaderContributor(getClass()));
> }
>
> since the manager knows all of the resources added for the page at this
> point, it is easy to compress them all together and serve a single file, and
> you dont have to list the files up front.
>
> What do you think of this idea?
>
> My code is here:
> http://www.nabble.com/file/p19279269/HeaderContribManagerTest.zip
> HeaderContribManagerTest.zip
>
> It still has bugs etc in it, and doesnt really work cos ive messed up the
> registerResource method, but you should be able to get the idea from it
>
> Richard
>
>
>
> -----
> http://www.richard-wilkinson.co.uk My blog:
> http://www.richard-wilkinson.co.uk
> --
> View this message in context: http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19279269.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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: Discussion on "Wicket Interface Speed-Up"
Posted by richardwilko <ri...@gmail.com>.
The problem of breaking encapsulation:
I did some work on this problem on my own a few months ago, my solution was
to use a header contrib manager, and instead of adding files with a header
contributer i add them to the manager, then get a single contributer per
page from the manger.
for example in a panel you would do
@Override
protected void onBeforeRender() {
super.onBeforeRender();
ResourceReference rr = new ResourceReference(getClass(), "test.js");
WicketApplication.get().getHcm().add(rr, getPage().getClass());
}
See how it uses getPage().getClass(), so the manager knows which class the
panel is being added into
then in the main page class
@Override
protected void onBeforeRender() {
super.onBeforeRender();
add(WicketApplication.get().getHcm().getHeaderContributor(getClass()));
}
since the manager knows all of the resources added for the page at this
point, it is easy to compress them all together and serve a single file, and
you dont have to list the files up front.
What do you think of this idea?
My code is here:
http://www.nabble.com/file/p19279269/HeaderContribManagerTest.zip
HeaderContribManagerTest.zip
It still has bugs etc in it, and doesnt really work cos ive messed up the
registerResource method, but you should be able to get the idea from it
Richard
-----
http://www.richard-wilkinson.co.uk My blog:
http://www.richard-wilkinson.co.uk
--
View this message in context: http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19279269.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Discussion on "Wicket Interface Speed-Up"
Posted by Stefan Fußenegger <st...@gmx.at>.
Sounds promising ... and little mysterious ;) Any concrete plans/ideas so
far?
Matej Knopp-2 wrote:
>
> On Fri, Aug 29, 2008 at 9:41 AM, Peter Ertl <pe...@gmx.net> wrote:
>> I totally agree that having the version in the filename and not in the
>> query
>> string will be a-lot-better.
>>
>> Just wanted to point you to that option so you can include it in your
>> excellent analysis on caching *thanks* :-)
>>
>> People can use that option right now and get a more decent version later
>> (e.g. your versioned resource filenames, which is the *correct* way)
>>
>> Resources need some more love in wicket 1.5 - full ack!
>>
> And they are going to get it :) Resources are going to be much simpler
> in 1.5 - current code is too tangled and ambiguous.
>
> -Matej
>> Cheers
>> Peter
>>
>>
>> Am 29.08.2008 um 09:24 schrieb Stefan Fußenegger:
>>
>>>
>>> Okay, sorry, you're right. Too bad, I didn't ever stumble upon this
>>> option.
>>> However, changing filename instead of using query string has certain
>>> advantages, see
>>>
>>> http://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/
>>>
>>> Furthermore, setting this option does not effect expires or
>>> cache-control
>>> headers. still only one hour, which is far from being aggressive. If you
>>> want to change that, you'll still have to explicitly mount all resources
>>> with your desired cache duration.
>>>
>>> Johan suggested (comment on
>>>
>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html
>>> my second article ) "what i can do is make it a setting:
>>> IResourceSettings.getResourceCacheDuration()". If such a setting is
>>> available, using
>>> IResourceSettings.setAddLastModifiedTimeToResourceReferenceUrl(true)
>>> would
>>> make more sense.
>>>
>>> I still think though that this isn't enough and resources should get a
>>> focus
>>> in upcoming wicket versions. Some might argue, that resources shouldn't
>>> be
>>> served by Wicket at all, but I really don't like to use proxies, CDNs or
>>> whatever voodoo for low traffic web sites: server-side performance isn't
>>> an
>>> issue there while client-side performance is.
>>>
>>> regards
>>>
>>>
>>> Peter Ertl wrote:
>>>>
>>>> That's not true.
>>>>
>>>> this settings will generate urls like:
>>>>
>>>> /resources/[package+class]/javascript.js?lm=[lastmodified]
>>>>
>>>> read it again : "add Last Modified Time To Resource Reference Url"
>>>>
>>>>>> getApplication
>>>>>> ().getResourceSettings
>>>>>> ().setAddLastModifiedTimeToResourceReferenceUrl(true) ??
>>>>
>>>> It will not sent the "LastModified" header as you think.
>>>>
>>>> So whenever the resource changes the url changes, too.
>>>>
>>>> Try it out and see :-)
>>>>
>>>> I did test it in Firefox. There will be no "IfModified" requests from
>>>> the browser.
>>>>
>>>> Everything will be completely cached in the browser until the resource
>>>> has changed.
>>>>
>>>> Cheers
>>>> Peter
>>>>
>>>>
>>>> Am 29.08.2008 um 08:17 schrieb Stefan Fußenegger:
>>>>
>>>>>
>>>>> honestly, no, I didn't. however, using last modified times still
>>>>> results in
>>>>> an HTTP request and a "304 Not Modified" reply. better than nothing,
>>>>> but
>>>>> client-side caching is still preferable.
>>>>>
>>>>> regards
>>>>>
>>>>>
>>>>> Peter Ertl wrote:
>>>>>>
>>>>>> @stefan: did you take into account
>>>>>>
>>>>>>
>>>>>> getApplication
>>>>>> ().getResourceSettings
>>>>>> ().setAddLastModifiedTimeToResourceReferenceUrl(true) ??
>>>>>>
>>>>>> Cheers
>>>>>> Peter
>>>>>>
>>>>>>
>>>>>> Am 28.08.2008 um 18:20 schrieb Igor Vaynberg:
>>>>>>
>>>>>>> sfussenegger now has access to wicketstuff...
>>>>>>>
>>>>>>> i dont know which parts should go into wicket itself, i can tell you
>>>>>>> that the part where you merge the files by listing them out
>>>>>>> upfront is
>>>>>>> probably not going to make it in because it breaks encapsulation...
>>>>>>>
>>>>>>> -igor
>>>>>>>
>>>>>>> On Thu, Aug 28, 2008 at 2:59 AM, Stefan Fußenegger
>>>>>>> <st...@gmx.at> wrote:
>>>>>>>>
>>>>>>>> I just finished the 4th and last entry of my series "Wicket
>>>>>>>> Interface
>>>>>>>> Speed-Up" on my blog. To give a short summary: I investigated one
>>>>>>>> of my apps
>>>>>>>> with YSlow and started optimizing it's interface rendering speed
>>>>>>>> [1].
>>>>>>>> Especially Wicket's way of handling resources, i.e. JS and CSS
>>>>>>>> files, causes
>>>>>>>> interfaces to load rather slowly. In my articles, I explain how to
>>>>>>>> modify
>>>>>>>> the cache interval [2], how to mount resources with a version (e.g.
>>>>>>>> /css/all-1234.css) in order to use aggressive client-side caching
>>>>>>>> (e.g.
>>>>>>>> resources expire after a year) [3]. Finally, I show how to merge
>>>>>>>> resources
>>>>>>>> at application startup (using a class classed MergedResourceStream)
>>>>>>>> to
>>>>>>>> reduce the number of resources a client has to download [4],
>>>>>>>> including
>>>>>>>> code). I was able to increase interface loading times considerably,
>>>>>>>> so it's
>>>>>>>> surely worth a look.
>>>>>>>>
>>>>>>>> I feel that it would also be worth to discuss, whether this work
>>>>>>>> could be
>>>>>>>> part of upcoming Wicket versions. For the time being I'd like to
>>>>>>>> make the
>>>>>>>> code attached to [4] a wicketstuff project - sfussenegger needs
>>>>>>>> commit
>>>>>>>> access ;) - and wait for your feedback.
>>>>>>>>
>>>>>>>> The links:
>>>>>>>> [1]
>>>>>>>>
>>>>>>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html
>>>>>>>> Wicket Interface Speed-Up
>>>>>>>> [2]
>>>>>>>>
>>>>>>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html
>>>>>>>> Wicket Interface Speed-Up: Modifying Expires and Cache-Control
>>>>>>>> Headers
>>>>>>>> [3]
>>>>>>>>
>>>>>>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-caching.html
>>>>>>>> Wicket Interface Speed-Up: Caching Resources Forever
>>>>>>>> [4]
>>>>>>>>
>>>>>>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-merging.html
>>>>>>>> Wicket Interface Speed-Up: Merging Resources for Fewer HTTP
>>>>>>>> Requests
>>>>>>>>
>>>>>>>> -----
>>>>>>>> -------
>>>>>>>> Stefan Fußenegger
>>>>>>>> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
>>>>>>>> --
>>>>>>>> View this message in context:
>>>>>>>>
>>>>>>>> http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19197540.html
>>>>>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> -----
>>>>> -------
>>>>> Stefan Fußenegger
>>>>> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
>>>>> --
>>>>> View this message in context:
>>>>>
>>>>> http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19214276.html
>>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>>>
>>>>
>>>>
>>>
>>>
>>> -----
>>> -------
>>> Stefan Fußenegger
>>> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19215003.html
>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
>
>
-----
-------
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
--
View this message in context: http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19216352.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Discussion on "Wicket Interface Speed-Up"
Posted by Matej Knopp <ma...@gmail.com>.
On Fri, Aug 29, 2008 at 9:41 AM, Peter Ertl <pe...@gmx.net> wrote:
> I totally agree that having the version in the filename and not in the query
> string will be a-lot-better.
>
> Just wanted to point you to that option so you can include it in your
> excellent analysis on caching *thanks* :-)
>
> People can use that option right now and get a more decent version later
> (e.g. your versioned resource filenames, which is the *correct* way)
>
> Resources need some more love in wicket 1.5 - full ack!
>
And they are going to get it :) Resources are going to be much simpler
in 1.5 - current code is too tangled and ambiguous.
-Matej
> Cheers
> Peter
>
>
> Am 29.08.2008 um 09:24 schrieb Stefan Fußenegger:
>
>>
>> Okay, sorry, you're right. Too bad, I didn't ever stumble upon this
>> option.
>> However, changing filename instead of using query string has certain
>> advantages, see
>>
>> http://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/
>>
>> Furthermore, setting this option does not effect expires or cache-control
>> headers. still only one hour, which is far from being aggressive. If you
>> want to change that, you'll still have to explicitly mount all resources
>> with your desired cache duration.
>>
>> Johan suggested (comment on
>>
>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html
>> my second article ) "what i can do is make it a setting:
>> IResourceSettings.getResourceCacheDuration()". If such a setting is
>> available, using
>> IResourceSettings.setAddLastModifiedTimeToResourceReferenceUrl(true) would
>> make more sense.
>>
>> I still think though that this isn't enough and resources should get a
>> focus
>> in upcoming wicket versions. Some might argue, that resources shouldn't be
>> served by Wicket at all, but I really don't like to use proxies, CDNs or
>> whatever voodoo for low traffic web sites: server-side performance isn't
>> an
>> issue there while client-side performance is.
>>
>> regards
>>
>>
>> Peter Ertl wrote:
>>>
>>> That's not true.
>>>
>>> this settings will generate urls like:
>>>
>>> /resources/[package+class]/javascript.js?lm=[lastmodified]
>>>
>>> read it again : "add Last Modified Time To Resource Reference Url"
>>>
>>>>> getApplication
>>>>> ().getResourceSettings
>>>>> ().setAddLastModifiedTimeToResourceReferenceUrl(true) ??
>>>
>>> It will not sent the "LastModified" header as you think.
>>>
>>> So whenever the resource changes the url changes, too.
>>>
>>> Try it out and see :-)
>>>
>>> I did test it in Firefox. There will be no "IfModified" requests from
>>> the browser.
>>>
>>> Everything will be completely cached in the browser until the resource
>>> has changed.
>>>
>>> Cheers
>>> Peter
>>>
>>>
>>> Am 29.08.2008 um 08:17 schrieb Stefan Fußenegger:
>>>
>>>>
>>>> honestly, no, I didn't. however, using last modified times still
>>>> results in
>>>> an HTTP request and a "304 Not Modified" reply. better than nothing,
>>>> but
>>>> client-side caching is still preferable.
>>>>
>>>> regards
>>>>
>>>>
>>>> Peter Ertl wrote:
>>>>>
>>>>> @stefan: did you take into account
>>>>>
>>>>>
>>>>> getApplication
>>>>> ().getResourceSettings
>>>>> ().setAddLastModifiedTimeToResourceReferenceUrl(true) ??
>>>>>
>>>>> Cheers
>>>>> Peter
>>>>>
>>>>>
>>>>> Am 28.08.2008 um 18:20 schrieb Igor Vaynberg:
>>>>>
>>>>>> sfussenegger now has access to wicketstuff...
>>>>>>
>>>>>> i dont know which parts should go into wicket itself, i can tell you
>>>>>> that the part where you merge the files by listing them out
>>>>>> upfront is
>>>>>> probably not going to make it in because it breaks encapsulation...
>>>>>>
>>>>>> -igor
>>>>>>
>>>>>> On Thu, Aug 28, 2008 at 2:59 AM, Stefan Fußenegger
>>>>>> <st...@gmx.at> wrote:
>>>>>>>
>>>>>>> I just finished the 4th and last entry of my series "Wicket
>>>>>>> Interface
>>>>>>> Speed-Up" on my blog. To give a short summary: I investigated one
>>>>>>> of my apps
>>>>>>> with YSlow and started optimizing it's interface rendering speed
>>>>>>> [1].
>>>>>>> Especially Wicket's way of handling resources, i.e. JS and CSS
>>>>>>> files, causes
>>>>>>> interfaces to load rather slowly. In my articles, I explain how to
>>>>>>> modify
>>>>>>> the cache interval [2], how to mount resources with a version (e.g.
>>>>>>> /css/all-1234.css) in order to use aggressive client-side caching
>>>>>>> (e.g.
>>>>>>> resources expire after a year) [3]. Finally, I show how to merge
>>>>>>> resources
>>>>>>> at application startup (using a class classed MergedResourceStream)
>>>>>>> to
>>>>>>> reduce the number of resources a client has to download [4],
>>>>>>> including
>>>>>>> code). I was able to increase interface loading times considerably,
>>>>>>> so it's
>>>>>>> surely worth a look.
>>>>>>>
>>>>>>> I feel that it would also be worth to discuss, whether this work
>>>>>>> could be
>>>>>>> part of upcoming Wicket versions. For the time being I'd like to
>>>>>>> make the
>>>>>>> code attached to [4] a wicketstuff project - sfussenegger needs
>>>>>>> commit
>>>>>>> access ;) - and wait for your feedback.
>>>>>>>
>>>>>>> The links:
>>>>>>> [1]
>>>>>>>
>>>>>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html
>>>>>>> Wicket Interface Speed-Up
>>>>>>> [2]
>>>>>>>
>>>>>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html
>>>>>>> Wicket Interface Speed-Up: Modifying Expires and Cache-Control
>>>>>>> Headers
>>>>>>> [3]
>>>>>>>
>>>>>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-caching.html
>>>>>>> Wicket Interface Speed-Up: Caching Resources Forever
>>>>>>> [4]
>>>>>>>
>>>>>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-merging.html
>>>>>>> Wicket Interface Speed-Up: Merging Resources for Fewer HTTP
>>>>>>> Requests
>>>>>>>
>>>>>>> -----
>>>>>>> -------
>>>>>>> Stefan Fußenegger
>>>>>>> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
>>>>>>> --
>>>>>>> View this message in context:
>>>>>>>
>>>>>>> http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19197540.html
>>>>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> -----
>>>> -------
>>>> Stefan Fußenegger
>>>> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
>>>> --
>>>> View this message in context:
>>>>
>>>> http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19214276.html
>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>>
>>>
>>
>>
>> -----
>> -------
>> Stefan Fußenegger
>> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
>> --
>> View this message in context:
>> http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19215003.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> 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: Discussion on "Wicket Interface Speed-Up"
Posted by Peter Ertl <pe...@gmx.net>.
I totally agree that having the version in the filename and not in the
query string will be a-lot-better.
Just wanted to point you to that option so you can include it in your
excellent analysis on caching *thanks* :-)
People can use that option right now and get a more decent version later
(e.g. your versioned resource filenames, which is the *correct* way)
Resources need some more love in wicket 1.5 - full ack!
Cheers
Peter
Am 29.08.2008 um 09:24 schrieb Stefan Fußenegger:
>
> Okay, sorry, you're right. Too bad, I didn't ever stumble upon this
> option.
> However, changing filename instead of using query string has certain
> advantages, see
> http://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/
>
> Furthermore, setting this option does not effect expires or cache-
> control
> headers. still only one hour, which is far from being aggressive. If
> you
> want to change that, you'll still have to explicitly mount all
> resources
> with your desired cache duration.
>
> Johan suggested (comment on
> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html
> my second article ) "what i can do is make it a setting:
> IResourceSettings.getResourceCacheDuration()". If such a setting is
> available, using
> IResourceSettings.setAddLastModifiedTimeToResourceReferenceUrl(true)
> would
> make more sense.
>
> I still think though that this isn't enough and resources should get
> a focus
> in upcoming wicket versions. Some might argue, that resources
> shouldn't be
> served by Wicket at all, but I really don't like to use proxies,
> CDNs or
> whatever voodoo for low traffic web sites: server-side performance
> isn't an
> issue there while client-side performance is.
>
> regards
>
>
> Peter Ertl wrote:
>>
>> That's not true.
>>
>> this settings will generate urls like:
>>
>> /resources/[package+class]/javascript.js?lm=[lastmodified]
>>
>> read it again : "add Last Modified Time To Resource Reference Url"
>>
>>>> getApplication
>>>> ().getResourceSettings
>>>> ().setAddLastModifiedTimeToResourceReferenceUrl(true) ??
>>
>> It will not sent the "LastModified" header as you think.
>>
>> So whenever the resource changes the url changes, too.
>>
>> Try it out and see :-)
>>
>> I did test it in Firefox. There will be no "IfModified" requests from
>> the browser.
>>
>> Everything will be completely cached in the browser until the
>> resource
>> has changed.
>>
>> Cheers
>> Peter
>>
>>
>> Am 29.08.2008 um 08:17 schrieb Stefan Fußenegger:
>>
>>>
>>> honestly, no, I didn't. however, using last modified times still
>>> results in
>>> an HTTP request and a "304 Not Modified" reply. better than nothing,
>>> but
>>> client-side caching is still preferable.
>>>
>>> regards
>>>
>>>
>>> Peter Ertl wrote:
>>>>
>>>> @stefan: did you take into account
>>>>
>>>>
>>>> getApplication
>>>> ().getResourceSettings
>>>> ().setAddLastModifiedTimeToResourceReferenceUrl(true) ??
>>>>
>>>> Cheers
>>>> Peter
>>>>
>>>>
>>>> Am 28.08.2008 um 18:20 schrieb Igor Vaynberg:
>>>>
>>>>> sfussenegger now has access to wicketstuff...
>>>>>
>>>>> i dont know which parts should go into wicket itself, i can tell
>>>>> you
>>>>> that the part where you merge the files by listing them out
>>>>> upfront is
>>>>> probably not going to make it in because it breaks
>>>>> encapsulation...
>>>>>
>>>>> -igor
>>>>>
>>>>> On Thu, Aug 28, 2008 at 2:59 AM, Stefan Fußenegger
>>>>> <st...@gmx.at> wrote:
>>>>>>
>>>>>> I just finished the 4th and last entry of my series "Wicket
>>>>>> Interface
>>>>>> Speed-Up" on my blog. To give a short summary: I investigated one
>>>>>> of my apps
>>>>>> with YSlow and started optimizing it's interface rendering speed
>>>>>> [1].
>>>>>> Especially Wicket's way of handling resources, i.e. JS and CSS
>>>>>> files, causes
>>>>>> interfaces to load rather slowly. In my articles, I explain how
>>>>>> to
>>>>>> modify
>>>>>> the cache interval [2], how to mount resources with a version
>>>>>> (e.g.
>>>>>> /css/all-1234.css) in order to use aggressive client-side caching
>>>>>> (e.g.
>>>>>> resources expire after a year) [3]. Finally, I show how to merge
>>>>>> resources
>>>>>> at application startup (using a class classed
>>>>>> MergedResourceStream)
>>>>>> to
>>>>>> reduce the number of resources a client has to download [4],
>>>>>> including
>>>>>> code). I was able to increase interface loading times
>>>>>> considerably,
>>>>>> so it's
>>>>>> surely worth a look.
>>>>>>
>>>>>> I feel that it would also be worth to discuss, whether this work
>>>>>> could be
>>>>>> part of upcoming Wicket versions. For the time being I'd like to
>>>>>> make the
>>>>>> code attached to [4] a wicketstuff project - sfussenegger needs
>>>>>> commit
>>>>>> access ;) - and wait for your feedback.
>>>>>>
>>>>>> The links:
>>>>>> [1]
>>>>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html
>>>>>> Wicket Interface Speed-Up
>>>>>> [2]
>>>>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html
>>>>>> Wicket Interface Speed-Up: Modifying Expires and Cache-Control
>>>>>> Headers
>>>>>> [3]
>>>>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-caching.html
>>>>>> Wicket Interface Speed-Up: Caching Resources Forever
>>>>>> [4]
>>>>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-merging.html
>>>>>> Wicket Interface Speed-Up: Merging Resources for Fewer HTTP
>>>>>> Requests
>>>>>>
>>>>>> -----
>>>>>> -------
>>>>>> Stefan Fußenegger
>>>>>> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
>>>>>> --
>>>>>> View this message in context:
>>>>>> http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19197540.html
>>>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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
>>>>
>>>>
>>>>
>>>
>>>
>>> -----
>>> -------
>>> Stefan Fußenegger
>>> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19214276.html
>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>>
>
>
> -----
> -------
> Stefan Fußenegger
> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
> --
> View this message in context: http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19215003.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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: Discussion on "Wicket Interface Speed-Up"
Posted by Stefan Fußenegger <st...@gmx.at>.
I would love to see an approach where Wicket itself tries to determine a
version. If a version is available, wicket would than add it to the filename
and use an aggressive caching duration, e.g. 1 year. (no version, no
caching)
Additionally, what I currently don't like is that resource creation isn't
flexible at all. The current approach (ResourceReference.newResource()
called in ResourceReference.bind(Application) if resource isn't already
bound) doesn't allow to change default resources, as one can't change the
used ResourceReference type.
I'd suggest - just thinking aloud right now - to change the current
implementation to either
Application.get().getResourceFactory().newResource(ResourceReference)
instead of ResourceReference.newResource() or to make the ResourceReference
type used within HeaderContributor.for...(..) changeable:
response.renderJavascriptReference(new JavascriptResourceReference(scope,
path)); // current
response.renderJavascriptReference(Application.get().getResourceFactory().newJavascriptResourceReference(scope,
path));
both approaches would allow to customize resource creation.
regards
Johan Compagner wrote:
>
> I thing we should look at what that append to url does, because i dont
> like the query string either, i also rather have it in the url path
> itself.
>
> Also such a resource cache duration can be added. But i also rather
> have it configured by resoure(reference) like
>
> HeaderContributor.getCSSResourceReference('my.css',cachetime,urlmod)
>
> Johan
>
> On 8/29/08, Stefan Fußenegger <st...@gmx.at> wrote:
>>
>> Okay, sorry, you're right. Too bad, I didn't ever stumble upon this
>> option.
>> However, changing filename instead of using query string has certain
>> advantages, see
>> http://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/
>>
>> Furthermore, setting this option does not effect expires or cache-control
>> headers. still only one hour, which is far from being aggressive. If you
>> want to change that, you'll still have to explicitly mount all resources
>> with your desired cache duration.
>>
>> Johan suggested (comment on
>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html
>> my second article ) "what i can do is make it a setting:
>> IResourceSettings.getResourceCacheDuration()". If such a setting is
>> available, using
>> IResourceSettings.setAddLastModifiedTimeToResourceReferenceUrl(true)
>> would
>> make more sense.
>>
>> I still think though that this isn't enough and resources should get a
>> focus
>> in upcoming wicket versions. Some might argue, that resources shouldn't
>> be
>> served by Wicket at all, but I really don't like to use proxies, CDNs or
>> whatever voodoo for low traffic web sites: server-side performance isn't
>> an
>> issue there while client-side performance is.
>>
>> regards
>>
>>
>> Peter Ertl wrote:
>>>
>>> That's not true.
>>>
>>> this settings will generate urls like:
>>>
>>> /resources/[package+class]/javascript.js?lm=[lastmodified]
>>>
>>> read it again : "add Last Modified Time To Resource Reference Url"
>>>
>>>>> getApplication
>>>>> ().getResourceSettings
>>>>> ().setAddLastModifiedTimeToResourceReferenceUrl(true) ??
>>>
>>> It will not sent the "LastModified" header as you think.
>>>
>>> So whenever the resource changes the url changes, too.
>>>
>>> Try it out and see :-)
>>>
>>> I did test it in Firefox. There will be no "IfModified" requests from
>>> the browser.
>>>
>>> Everything will be completely cached in the browser until the resource
>>> has changed.
>>>
>>> Cheers
>>> Peter
>>>
>>>
>>> Am 29.08.2008 um 08:17 schrieb Stefan Fußenegger:
>>>
>>>>
>>>> honestly, no, I didn't. however, using last modified times still
>>>> results in
>>>> an HTTP request and a "304 Not Modified" reply. better than nothing,
>>>> but
>>>> client-side caching is still preferable.
>>>>
>>>> regards
>>>>
>>>>
>>>> Peter Ertl wrote:
>>>>>
>>>>> @stefan: did you take into account
>>>>>
>>>>>
>>>>> getApplication
>>>>> ().getResourceSettings
>>>>> ().setAddLastModifiedTimeToResourceReferenceUrl(true) ??
>>>>>
>>>>> Cheers
>>>>> Peter
>>>>>
>>>>>
>>>>> Am 28.08.2008 um 18:20 schrieb Igor Vaynberg:
>>>>>
>>>>>> sfussenegger now has access to wicketstuff...
>>>>>>
>>>>>> i dont know which parts should go into wicket itself, i can tell you
>>>>>> that the part where you merge the files by listing them out
>>>>>> upfront is
>>>>>> probably not going to make it in because it breaks encapsulation...
>>>>>>
>>>>>> -igor
>>>>>>
>>>>>> On Thu, Aug 28, 2008 at 2:59 AM, Stefan Fußenegger
>>>>>> <st...@gmx.at> wrote:
>>>>>>>
>>>>>>> I just finished the 4th and last entry of my series "Wicket
>>>>>>> Interface
>>>>>>> Speed-Up" on my blog. To give a short summary: I investigated one
>>>>>>> of my apps
>>>>>>> with YSlow and started optimizing it's interface rendering speed
>>>>>>> [1].
>>>>>>> Especially Wicket's way of handling resources, i.e. JS and CSS
>>>>>>> files, causes
>>>>>>> interfaces to load rather slowly. In my articles, I explain how to
>>>>>>> modify
>>>>>>> the cache interval [2], how to mount resources with a version (e.g.
>>>>>>> /css/all-1234.css) in order to use aggressive client-side caching
>>>>>>> (e.g.
>>>>>>> resources expire after a year) [3]. Finally, I show how to merge
>>>>>>> resources
>>>>>>> at application startup (using a class classed MergedResourceStream)
>>>>>>> to
>>>>>>> reduce the number of resources a client has to download [4],
>>>>>>> including
>>>>>>> code). I was able to increase interface loading times considerably,
>>>>>>> so it's
>>>>>>> surely worth a look.
>>>>>>>
>>>>>>> I feel that it would also be worth to discuss, whether this work
>>>>>>> could be
>>>>>>> part of upcoming Wicket versions. For the time being I'd like to
>>>>>>> make the
>>>>>>> code attached to [4] a wicketstuff project - sfussenegger needs
>>>>>>> commit
>>>>>>> access ;) - and wait for your feedback.
>>>>>>>
>>>>>>> The links:
>>>>>>> [1]
>>>>>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html
>>>>>>> Wicket Interface Speed-Up
>>>>>>> [2]
>>>>>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html
>>>>>>> Wicket Interface Speed-Up: Modifying Expires and Cache-Control
>>>>>>> Headers
>>>>>>> [3]
>>>>>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-caching.html
>>>>>>> Wicket Interface Speed-Up: Caching Resources Forever
>>>>>>> [4]
>>>>>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-merging.html
>>>>>>> Wicket Interface Speed-Up: Merging Resources for Fewer HTTP
>>>>>>> Requests
>>>>>>>
>>>>>>> -----
>>>>>>> -------
>>>>>>> Stefan Fußenegger
>>>>>>> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
>>>>>>> --
>>>>>>> View this message in context:
>>>>>>> http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19197540.html
>>>>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> -----
>>>> -------
>>>> Stefan Fußenegger
>>>> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19214276.html
>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>>
>>>
>>
>>
>> -----
>> -------
>> Stefan Fußenegger
>> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
>> --
>> View this message in context:
>> http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19215003.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
>
-----
-------
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
--
View this message in context: http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19216320.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Discussion on "Wicket Interface Speed-Up"
Posted by Johan Compagner <jc...@gmail.com>.
I thing we should look at what that append to url does, because i dont
like the query string either, i also rather have it in the url path
itself.
Also such a resource cache duration can be added. But i also rather
have it configured by resoure(reference) like
HeaderContributor.getCSSResourceReference('my.css',cachetime,urlmod)
Johan
On 8/29/08, Stefan Fußenegger <st...@gmx.at> wrote:
>
> Okay, sorry, you're right. Too bad, I didn't ever stumble upon this option.
> However, changing filename instead of using query string has certain
> advantages, see
> http://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/
>
> Furthermore, setting this option does not effect expires or cache-control
> headers. still only one hour, which is far from being aggressive. If you
> want to change that, you'll still have to explicitly mount all resources
> with your desired cache duration.
>
> Johan suggested (comment on
> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html
> my second article ) "what i can do is make it a setting:
> IResourceSettings.getResourceCacheDuration()". If such a setting is
> available, using
> IResourceSettings.setAddLastModifiedTimeToResourceReferenceUrl(true) would
> make more sense.
>
> I still think though that this isn't enough and resources should get a focus
> in upcoming wicket versions. Some might argue, that resources shouldn't be
> served by Wicket at all, but I really don't like to use proxies, CDNs or
> whatever voodoo for low traffic web sites: server-side performance isn't an
> issue there while client-side performance is.
>
> regards
>
>
> Peter Ertl wrote:
>>
>> That's not true.
>>
>> this settings will generate urls like:
>>
>> /resources/[package+class]/javascript.js?lm=[lastmodified]
>>
>> read it again : "add Last Modified Time To Resource Reference Url"
>>
>>>> getApplication
>>>> ().getResourceSettings
>>>> ().setAddLastModifiedTimeToResourceReferenceUrl(true) ??
>>
>> It will not sent the "LastModified" header as you think.
>>
>> So whenever the resource changes the url changes, too.
>>
>> Try it out and see :-)
>>
>> I did test it in Firefox. There will be no "IfModified" requests from
>> the browser.
>>
>> Everything will be completely cached in the browser until the resource
>> has changed.
>>
>> Cheers
>> Peter
>>
>>
>> Am 29.08.2008 um 08:17 schrieb Stefan Fußenegger:
>>
>>>
>>> honestly, no, I didn't. however, using last modified times still
>>> results in
>>> an HTTP request and a "304 Not Modified" reply. better than nothing,
>>> but
>>> client-side caching is still preferable.
>>>
>>> regards
>>>
>>>
>>> Peter Ertl wrote:
>>>>
>>>> @stefan: did you take into account
>>>>
>>>>
>>>> getApplication
>>>> ().getResourceSettings
>>>> ().setAddLastModifiedTimeToResourceReferenceUrl(true) ??
>>>>
>>>> Cheers
>>>> Peter
>>>>
>>>>
>>>> Am 28.08.2008 um 18:20 schrieb Igor Vaynberg:
>>>>
>>>>> sfussenegger now has access to wicketstuff...
>>>>>
>>>>> i dont know which parts should go into wicket itself, i can tell you
>>>>> that the part where you merge the files by listing them out
>>>>> upfront is
>>>>> probably not going to make it in because it breaks encapsulation...
>>>>>
>>>>> -igor
>>>>>
>>>>> On Thu, Aug 28, 2008 at 2:59 AM, Stefan Fußenegger
>>>>> <st...@gmx.at> wrote:
>>>>>>
>>>>>> I just finished the 4th and last entry of my series "Wicket
>>>>>> Interface
>>>>>> Speed-Up" on my blog. To give a short summary: I investigated one
>>>>>> of my apps
>>>>>> with YSlow and started optimizing it's interface rendering speed
>>>>>> [1].
>>>>>> Especially Wicket's way of handling resources, i.e. JS and CSS
>>>>>> files, causes
>>>>>> interfaces to load rather slowly. In my articles, I explain how to
>>>>>> modify
>>>>>> the cache interval [2], how to mount resources with a version (e.g.
>>>>>> /css/all-1234.css) in order to use aggressive client-side caching
>>>>>> (e.g.
>>>>>> resources expire after a year) [3]. Finally, I show how to merge
>>>>>> resources
>>>>>> at application startup (using a class classed MergedResourceStream)
>>>>>> to
>>>>>> reduce the number of resources a client has to download [4],
>>>>>> including
>>>>>> code). I was able to increase interface loading times considerably,
>>>>>> so it's
>>>>>> surely worth a look.
>>>>>>
>>>>>> I feel that it would also be worth to discuss, whether this work
>>>>>> could be
>>>>>> part of upcoming Wicket versions. For the time being I'd like to
>>>>>> make the
>>>>>> code attached to [4] a wicketstuff project - sfussenegger needs
>>>>>> commit
>>>>>> access ;) - and wait for your feedback.
>>>>>>
>>>>>> The links:
>>>>>> [1]
>>>>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html
>>>>>> Wicket Interface Speed-Up
>>>>>> [2]
>>>>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html
>>>>>> Wicket Interface Speed-Up: Modifying Expires and Cache-Control
>>>>>> Headers
>>>>>> [3]
>>>>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-caching.html
>>>>>> Wicket Interface Speed-Up: Caching Resources Forever
>>>>>> [4]
>>>>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-merging.html
>>>>>> Wicket Interface Speed-Up: Merging Resources for Fewer HTTP
>>>>>> Requests
>>>>>>
>>>>>> -----
>>>>>> -------
>>>>>> Stefan Fußenegger
>>>>>> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
>>>>>> --
>>>>>> View this message in context:
>>>>>> http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19197540.html
>>>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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
>>>>
>>>>
>>>>
>>>
>>>
>>> -----
>>> -------
>>> Stefan Fußenegger
>>> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19214276.html
>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>>
>
>
> -----
> -------
> Stefan Fußenegger
> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
> --
> View this message in context:
> http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19215003.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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: Discussion on "Wicket Interface Speed-Up"
Posted by Stefan Fußenegger <st...@gmx.at>.
Okay, sorry, you're right. Too bad, I didn't ever stumble upon this option.
However, changing filename instead of using query string has certain
advantages, see
http://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/
Furthermore, setting this option does not effect expires or cache-control
headers. still only one hour, which is far from being aggressive. If you
want to change that, you'll still have to explicitly mount all resources
with your desired cache duration.
Johan suggested (comment on
http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html
my second article ) "what i can do is make it a setting:
IResourceSettings.getResourceCacheDuration()". If such a setting is
available, using
IResourceSettings.setAddLastModifiedTimeToResourceReferenceUrl(true) would
make more sense.
I still think though that this isn't enough and resources should get a focus
in upcoming wicket versions. Some might argue, that resources shouldn't be
served by Wicket at all, but I really don't like to use proxies, CDNs or
whatever voodoo for low traffic web sites: server-side performance isn't an
issue there while client-side performance is.
regards
Peter Ertl wrote:
>
> That's not true.
>
> this settings will generate urls like:
>
> /resources/[package+class]/javascript.js?lm=[lastmodified]
>
> read it again : "add Last Modified Time To Resource Reference Url"
>
>>> getApplication
>>> ().getResourceSettings
>>> ().setAddLastModifiedTimeToResourceReferenceUrl(true) ??
>
> It will not sent the "LastModified" header as you think.
>
> So whenever the resource changes the url changes, too.
>
> Try it out and see :-)
>
> I did test it in Firefox. There will be no "IfModified" requests from
> the browser.
>
> Everything will be completely cached in the browser until the resource
> has changed.
>
> Cheers
> Peter
>
>
> Am 29.08.2008 um 08:17 schrieb Stefan Fußenegger:
>
>>
>> honestly, no, I didn't. however, using last modified times still
>> results in
>> an HTTP request and a "304 Not Modified" reply. better than nothing,
>> but
>> client-side caching is still preferable.
>>
>> regards
>>
>>
>> Peter Ertl wrote:
>>>
>>> @stefan: did you take into account
>>>
>>>
>>> getApplication
>>> ().getResourceSettings
>>> ().setAddLastModifiedTimeToResourceReferenceUrl(true) ??
>>>
>>> Cheers
>>> Peter
>>>
>>>
>>> Am 28.08.2008 um 18:20 schrieb Igor Vaynberg:
>>>
>>>> sfussenegger now has access to wicketstuff...
>>>>
>>>> i dont know which parts should go into wicket itself, i can tell you
>>>> that the part where you merge the files by listing them out
>>>> upfront is
>>>> probably not going to make it in because it breaks encapsulation...
>>>>
>>>> -igor
>>>>
>>>> On Thu, Aug 28, 2008 at 2:59 AM, Stefan Fußenegger
>>>> <st...@gmx.at> wrote:
>>>>>
>>>>> I just finished the 4th and last entry of my series "Wicket
>>>>> Interface
>>>>> Speed-Up" on my blog. To give a short summary: I investigated one
>>>>> of my apps
>>>>> with YSlow and started optimizing it's interface rendering speed
>>>>> [1].
>>>>> Especially Wicket's way of handling resources, i.e. JS and CSS
>>>>> files, causes
>>>>> interfaces to load rather slowly. In my articles, I explain how to
>>>>> modify
>>>>> the cache interval [2], how to mount resources with a version (e.g.
>>>>> /css/all-1234.css) in order to use aggressive client-side caching
>>>>> (e.g.
>>>>> resources expire after a year) [3]. Finally, I show how to merge
>>>>> resources
>>>>> at application startup (using a class classed MergedResourceStream)
>>>>> to
>>>>> reduce the number of resources a client has to download [4],
>>>>> including
>>>>> code). I was able to increase interface loading times considerably,
>>>>> so it's
>>>>> surely worth a look.
>>>>>
>>>>> I feel that it would also be worth to discuss, whether this work
>>>>> could be
>>>>> part of upcoming Wicket versions. For the time being I'd like to
>>>>> make the
>>>>> code attached to [4] a wicketstuff project - sfussenegger needs
>>>>> commit
>>>>> access ;) - and wait for your feedback.
>>>>>
>>>>> The links:
>>>>> [1]
>>>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html
>>>>> Wicket Interface Speed-Up
>>>>> [2]
>>>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html
>>>>> Wicket Interface Speed-Up: Modifying Expires and Cache-Control
>>>>> Headers
>>>>> [3]
>>>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-caching.html
>>>>> Wicket Interface Speed-Up: Caching Resources Forever
>>>>> [4]
>>>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-merging.html
>>>>> Wicket Interface Speed-Up: Merging Resources for Fewer HTTP
>>>>> Requests
>>>>>
>>>>> -----
>>>>> -------
>>>>> Stefan Fußenegger
>>>>> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
>>>>> --
>>>>> View this message in context:
>>>>> http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19197540.html
>>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>>
>>>
>>>
>>
>>
>> -----
>> -------
>> Stefan Fußenegger
>> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
>> --
>> View this message in context:
>> http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19214276.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
>
-----
-------
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
--
View this message in context: http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19215003.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Discussion on "Wicket Interface Speed-Up"
Posted by Peter Ertl <pe...@gmx.net>.
That's not true.
this settings will generate urls like:
/resources/[package+class]/javascript.js?lm=[lastmodified]
read it again : "add Last Modified Time To Resource Reference Url"
>> getApplication
>> ().getResourceSettings
>> ().setAddLastModifiedTimeToResourceReferenceUrl(true) ??
It will not sent the "LastModified" header as you think.
So whenever the resource changes the url changes, too.
Try it out and see :-)
I did test it in Firefox. There will be no "IfModified" requests from
the browser.
Everything will be completely cached in the browser until the resource
has changed.
Cheers
Peter
Am 29.08.2008 um 08:17 schrieb Stefan Fußenegger:
>
> honestly, no, I didn't. however, using last modified times still
> results in
> an HTTP request and a "304 Not Modified" reply. better than nothing,
> but
> client-side caching is still preferable.
>
> regards
>
>
> Peter Ertl wrote:
>>
>> @stefan: did you take into account
>>
>>
>> getApplication
>> ().getResourceSettings
>> ().setAddLastModifiedTimeToResourceReferenceUrl(true) ??
>>
>> Cheers
>> Peter
>>
>>
>> Am 28.08.2008 um 18:20 schrieb Igor Vaynberg:
>>
>>> sfussenegger now has access to wicketstuff...
>>>
>>> i dont know which parts should go into wicket itself, i can tell you
>>> that the part where you merge the files by listing them out
>>> upfront is
>>> probably not going to make it in because it breaks encapsulation...
>>>
>>> -igor
>>>
>>> On Thu, Aug 28, 2008 at 2:59 AM, Stefan Fußenegger
>>> <st...@gmx.at> wrote:
>>>>
>>>> I just finished the 4th and last entry of my series "Wicket
>>>> Interface
>>>> Speed-Up" on my blog. To give a short summary: I investigated one
>>>> of my apps
>>>> with YSlow and started optimizing it's interface rendering speed
>>>> [1].
>>>> Especially Wicket's way of handling resources, i.e. JS and CSS
>>>> files, causes
>>>> interfaces to load rather slowly. In my articles, I explain how to
>>>> modify
>>>> the cache interval [2], how to mount resources with a version (e.g.
>>>> /css/all-1234.css) in order to use aggressive client-side caching
>>>> (e.g.
>>>> resources expire after a year) [3]. Finally, I show how to merge
>>>> resources
>>>> at application startup (using a class classed MergedResourceStream)
>>>> to
>>>> reduce the number of resources a client has to download [4],
>>>> including
>>>> code). I was able to increase interface loading times considerably,
>>>> so it's
>>>> surely worth a look.
>>>>
>>>> I feel that it would also be worth to discuss, whether this work
>>>> could be
>>>> part of upcoming Wicket versions. For the time being I'd like to
>>>> make the
>>>> code attached to [4] a wicketstuff project - sfussenegger needs
>>>> commit
>>>> access ;) - and wait for your feedback.
>>>>
>>>> The links:
>>>> [1]
>>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html
>>>> Wicket Interface Speed-Up
>>>> [2]
>>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html
>>>> Wicket Interface Speed-Up: Modifying Expires and Cache-Control
>>>> Headers
>>>> [3]
>>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-caching.html
>>>> Wicket Interface Speed-Up: Caching Resources Forever
>>>> [4]
>>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-merging.html
>>>> Wicket Interface Speed-Up: Merging Resources for Fewer HTTP
>>>> Requests
>>>>
>>>> -----
>>>> -------
>>>> Stefan Fußenegger
>>>> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19197540.html
>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>
>>
>>
>
>
> -----
> -------
> Stefan Fußenegger
> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
> --
> View this message in context: http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19214276.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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: Discussion on "Wicket Interface Speed-Up"
Posted by Stefan Fußenegger <st...@gmx.at>.
honestly, no, I didn't. however, using last modified times still results in
an HTTP request and a "304 Not Modified" reply. better than nothing, but
client-side caching is still preferable.
regards
Peter Ertl wrote:
>
> @stefan: did you take into account
>
>
> getApplication
> ().getResourceSettings
> ().setAddLastModifiedTimeToResourceReferenceUrl(true) ??
>
> Cheers
> Peter
>
>
> Am 28.08.2008 um 18:20 schrieb Igor Vaynberg:
>
>> sfussenegger now has access to wicketstuff...
>>
>> i dont know which parts should go into wicket itself, i can tell you
>> that the part where you merge the files by listing them out upfront is
>> probably not going to make it in because it breaks encapsulation...
>>
>> -igor
>>
>> On Thu, Aug 28, 2008 at 2:59 AM, Stefan Fußenegger
>> <st...@gmx.at> wrote:
>>>
>>> I just finished the 4th and last entry of my series "Wicket Interface
>>> Speed-Up" on my blog. To give a short summary: I investigated one
>>> of my apps
>>> with YSlow and started optimizing it's interface rendering speed [1].
>>> Especially Wicket's way of handling resources, i.e. JS and CSS
>>> files, causes
>>> interfaces to load rather slowly. In my articles, I explain how to
>>> modify
>>> the cache interval [2], how to mount resources with a version (e.g.
>>> /css/all-1234.css) in order to use aggressive client-side caching
>>> (e.g.
>>> resources expire after a year) [3]. Finally, I show how to merge
>>> resources
>>> at application startup (using a class classed MergedResourceStream)
>>> to
>>> reduce the number of resources a client has to download [4],
>>> including
>>> code). I was able to increase interface loading times considerably,
>>> so it's
>>> surely worth a look.
>>>
>>> I feel that it would also be worth to discuss, whether this work
>>> could be
>>> part of upcoming Wicket versions. For the time being I'd like to
>>> make the
>>> code attached to [4] a wicketstuff project - sfussenegger needs
>>> commit
>>> access ;) - and wait for your feedback.
>>>
>>> The links:
>>> [1]
>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html
>>> Wicket Interface Speed-Up
>>> [2]
>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html
>>> Wicket Interface Speed-Up: Modifying Expires and Cache-Control
>>> Headers
>>> [3]
>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-caching.html
>>> Wicket Interface Speed-Up: Caching Resources Forever
>>> [4]
>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-merging.html
>>> Wicket Interface Speed-Up: Merging Resources for Fewer HTTP Requests
>>>
>>> -----
>>> -------
>>> Stefan Fußenegger
>>> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19197540.html
>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
>
>
-----
-------
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
--
View this message in context: http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19214276.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Discussion on "Wicket Interface Speed-Up"
Posted by Peter Ertl <pe...@gmx.net>.
@stefan: did you take into account
getApplication
().getResourceSettings
().setAddLastModifiedTimeToResourceReferenceUrl(true) ??
Cheers
Peter
Am 28.08.2008 um 18:20 schrieb Igor Vaynberg:
> sfussenegger now has access to wicketstuff...
>
> i dont know which parts should go into wicket itself, i can tell you
> that the part where you merge the files by listing them out upfront is
> probably not going to make it in because it breaks encapsulation...
>
> -igor
>
> On Thu, Aug 28, 2008 at 2:59 AM, Stefan Fußenegger
> <st...@gmx.at> wrote:
>>
>> I just finished the 4th and last entry of my series "Wicket Interface
>> Speed-Up" on my blog. To give a short summary: I investigated one
>> of my apps
>> with YSlow and started optimizing it's interface rendering speed [1].
>> Especially Wicket's way of handling resources, i.e. JS and CSS
>> files, causes
>> interfaces to load rather slowly. In my articles, I explain how to
>> modify
>> the cache interval [2], how to mount resources with a version (e.g.
>> /css/all-1234.css) in order to use aggressive client-side caching
>> (e.g.
>> resources expire after a year) [3]. Finally, I show how to merge
>> resources
>> at application startup (using a class classed MergedResourceStream)
>> to
>> reduce the number of resources a client has to download [4],
>> including
>> code). I was able to increase interface loading times considerably,
>> so it's
>> surely worth a look.
>>
>> I feel that it would also be worth to discuss, whether this work
>> could be
>> part of upcoming Wicket versions. For the time being I'd like to
>> make the
>> code attached to [4] a wicketstuff project - sfussenegger needs
>> commit
>> access ;) - and wait for your feedback.
>>
>> The links:
>> [1] http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html
>> Wicket Interface Speed-Up
>> [2]
>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html
>> Wicket Interface Speed-Up: Modifying Expires and Cache-Control
>> Headers
>> [3]
>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-caching.html
>> Wicket Interface Speed-Up: Caching Resources Forever
>> [4]
>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-merging.html
>> Wicket Interface Speed-Up: Merging Resources for Fewer HTTP Requests
>>
>> -----
>> -------
>> Stefan Fußenegger
>> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
>> --
>> View this message in context: http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19197540.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> 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: Discussion on "Wicket Interface Speed-Up"
Posted by Igor Vaynberg <ig...@gmail.com>.
sfussenegger now has access to wicketstuff...
i dont know which parts should go into wicket itself, i can tell you
that the part where you merge the files by listing them out upfront is
probably not going to make it in because it breaks encapsulation...
-igor
On Thu, Aug 28, 2008 at 2:59 AM, Stefan Fußenegger
<st...@gmx.at> wrote:
>
> I just finished the 4th and last entry of my series "Wicket Interface
> Speed-Up" on my blog. To give a short summary: I investigated one of my apps
> with YSlow and started optimizing it's interface rendering speed [1].
> Especially Wicket's way of handling resources, i.e. JS and CSS files, causes
> interfaces to load rather slowly. In my articles, I explain how to modify
> the cache interval [2], how to mount resources with a version (e.g.
> /css/all-1234.css) in order to use aggressive client-side caching (e.g.
> resources expire after a year) [3]. Finally, I show how to merge resources
> at application startup (using a class classed MergedResourceStream) to
> reduce the number of resources a client has to download [4], including
> code). I was able to increase interface loading times considerably, so it's
> surely worth a look.
>
> I feel that it would also be worth to discuss, whether this work could be
> part of upcoming Wicket versions. For the time being I'd like to make the
> code attached to [4] a wicketstuff project - sfussenegger needs commit
> access ;) - and wait for your feedback.
>
> The links:
> [1] http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html
> Wicket Interface Speed-Up
> [2]
> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html
> Wicket Interface Speed-Up: Modifying Expires and Cache-Control Headers
> [3]
> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-caching.html
> Wicket Interface Speed-Up: Caching Resources Forever
> [4]
> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-merging.html
> Wicket Interface Speed-Up: Merging Resources for Fewer HTTP Requests
>
> -----
> -------
> Stefan Fußenegger
> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
> --
> View this message in context: http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19197540.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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: Discussion on "Wicket Interface Speed-Up"
Posted by Jörn Zaefferer <jo...@googlemail.com>.
Thanks Stefan! Just removed my local checkout and it works fine.
Jörn
On Tue, Sep 2, 2008 at 8:46 AM, Stefan Fußenegger
<st...@gmx.at> wrote:
>
> wicketstuff-merged-resources is now available in JIRA:
>
> http://wicketstuff.org/jira/browse/WMR
>
> and from wicketstuff maven repo:
> <repositories>
> <repository>
> <id>wicket-snaps</id>
> <url>http://wicketstuff.org/maven/repository</url>
> <snapshots>
> <enabled>true</enabled>
> </snapshots>
> <releases>
> <enabled>true</enabled>
> </releases>
> </repository>
> </repositories>
>
> <dependency>
> <groupId>org.wicketstuff</groupId>
> <artifactId>wicketstuff-merged-resources</artifactId>
> <version>1.3.4-SNAPSHOT</version>
> </dependency>
>
> i am also going to add a short wiki page at wicketstuff.org
>
> regards, Stefan
>
>
>
> Jörn Zaefferer-2 wrote:
>>
>> Good point, I forgot that wicketstuff has its own JIRA installation.
>> Though the entry for the project is missing. Let me know once its
>> there, and I'll create the report.
>>
>> Jörn
>>
>> On Fri, Aug 29, 2008 at 12:26 PM, Peter Ertl <pe...@gmx.net> wrote:
>>> why don't you open up an issue in JIRA?
>>>
>>>
>>> Am 29.08.2008 um 12:22 schrieb Jörn Zaefferer:
>>>
>>>> Here is a first patch for the RevisionVersionProvider:
>>>>
>>>> Index:
>>>> src/main/java/org/wicketstuff/mergedresources/versioning/RevisionVersionProvider.java
>>>> ===================================================================
>>>> ---
>>>> src/main/java/org/wicketstuff/mergedresources/versioning/RevisionVersionProvider.java
>>>> (revision
>>>> 4147)
>>>> +++
>>>> src/main/java/org/wicketstuff/mergedresources/versioning/RevisionVersionProvider.java
>>>> (working
>>>> copy)
>>>> @@ -15,7 +15,7 @@
>>>>
>>>> public int getVersion(final Class<?> scope, final String
>>>> fileName)
>>>> throws VersionException {
>>>> final String file = getResourcePath(scope, fileName);
>>>> - final InputStream in =
>>>> ClassLoader.getSystemResourceAsStream(file);
>>>> + final InputStream in =
>>>> RevisionVersionProvider.class.getClassLoader().getResourceAsStream(file);
>>>> if (in == null) {
>>>> throw new VersionException(scope, fileName,
>>>> "can't
>>>> find " + file);
>>>> }
>>>>
>>>>
>>>> ClassLoader.getSystemResourceAsStream in my deployment enviroment, it
>>>> always returned null for classpath resources. Using the
>>>> RevisionVersionProvider classloader works fine.
>>>>
>>>> Let me know where I should post further patches etc.
>>>>
>>>> Jörn
>>>>
>>>> On Fri, Aug 29, 2008 at 11:29 AM, Stefan Fußenegger
>>>> <st...@gmx.at> wrote:
>>>>>
>>>>> Code is now available through wicketsuff:
>>>>>
>>>>> https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-merged-resources/
>>>>> wicketstuff-merged-resources and
>>>>>
>>>>> https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-merged-resources-examples/
>>>>> wicketstuff-merged-resources-examples
>>>>>
>>>>> Now I want to make it available through
>>>>> http://wicketstuff.org/maven/repository/. I therefore registered at
>>>>> wicketstuff.org/teamcity (sfussenegger). What's next?
>>>>>
>>>>>
>>>>> Stefan Fußenegger wrote:
>>>>>>
>>>>>> I just finished the 4th and last entry of my series "Wicket Interface
>>>>>> Speed-Up" on my blog. To give a short summary: I investigated one of
>>>>>> my
>>>>>> apps with YSlow and started optimizing it's interface rendering speed
>>>>>> [1].
>>>>>> Especially Wicket's way of handling resources, i.e. JS and CSS files,
>>>>>> causes interfaces to load rather slowly. In my articles, I explain how
>>>>>> to
>>>>>> modify the cache interval [2], how to mount resources with a version
>>>>>> (e.g.
>>>>>> /css/all-1234.css) in order to use aggressive client-side caching
>>>>>> (e.g.
>>>>>> resources expire after a year) [3]. Finally, I show how to merge
>>>>>> resources
>>>>>> at application startup (using a class classed MergedResourceStream) to
>>>>>> reduce the number of resources a client has to download [4], including
>>>>>> code). I was able to increase interface loading times considerably, so
>>>>>> it's surely worth a look.
>>>>>>
>>>>>> I feel that it would also be worth to discuss, whether this work could
>>>>>> be
>>>>>> part of upcoming Wicket versions. For the time being I'd like to make
>>>>>> the
>>>>>> code attached to [4] a wicketstuff project - sfussenegger needs commit
>>>>>> access ;) - and wait for your feedback.
>>>>>>
>>>>>> The links:
>>>>>> [1]
>>>>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html
>>>>>> Wicket Interface Speed-Up
>>>>>> [2]
>>>>>>
>>>>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html
>>>>>> Wicket Interface Speed-Up: Modifying Expires and Cache-Control Headers
>>>>>> [3]
>>>>>>
>>>>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-caching.html
>>>>>> Wicket Interface Speed-Up: Caching Resources Forever
>>>>>> [4]
>>>>>>
>>>>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-merging.html
>>>>>> Wicket Interface Speed-Up: Merging Resources for Fewer HTTP Requests
>>>>>>
>>>>>
>>>>>
>>>>> -----
>>>>> -------
>>>>> Stefan Fußenegger
>>>>> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
>>>>> --
>>>>> View this message in context:
>>>>> http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19216657.html
>>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>>
>>>
>>
>>
>
>
> -----
> -------
> Stefan Fußenegger
> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
> --
> View this message in context: http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19264974.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Discussion on "Wicket Interface Speed-Up"
Posted by Stefan Fußenegger <st...@gmx.at>.
wicketstuff-merged-resources is now available in JIRA:
http://wicketstuff.org/jira/browse/WMR
and from wicketstuff maven repo:
<repositories>
<repository>
<id>wicket-snaps</id>
<url>http://wicketstuff.org/maven/repository</url>
<snapshots>
<enabled>true</enabled>
</snapshots>
<releases>
<enabled>true</enabled>
</releases>
</repository>
</repositories>
<dependency>
<groupId>org.wicketstuff</groupId>
<artifactId>wicketstuff-merged-resources</artifactId>
<version>1.3.4-SNAPSHOT</version>
</dependency>
i am also going to add a short wiki page at wicketstuff.org
regards, Stefan
Jörn Zaefferer-2 wrote:
>
> Good point, I forgot that wicketstuff has its own JIRA installation.
> Though the entry for the project is missing. Let me know once its
> there, and I'll create the report.
>
> Jörn
>
> On Fri, Aug 29, 2008 at 12:26 PM, Peter Ertl <pe...@gmx.net> wrote:
>> why don't you open up an issue in JIRA?
>>
>>
>> Am 29.08.2008 um 12:22 schrieb Jörn Zaefferer:
>>
>>> Here is a first patch for the RevisionVersionProvider:
>>>
>>> Index:
>>> src/main/java/org/wicketstuff/mergedresources/versioning/RevisionVersionProvider.java
>>> ===================================================================
>>> ---
>>> src/main/java/org/wicketstuff/mergedresources/versioning/RevisionVersionProvider.java
>>> (revision
>>> 4147)
>>> +++
>>> src/main/java/org/wicketstuff/mergedresources/versioning/RevisionVersionProvider.java
>>> (working
>>> copy)
>>> @@ -15,7 +15,7 @@
>>>
>>> public int getVersion(final Class<?> scope, final String
>>> fileName)
>>> throws VersionException {
>>> final String file = getResourcePath(scope, fileName);
>>> - final InputStream in =
>>> ClassLoader.getSystemResourceAsStream(file);
>>> + final InputStream in =
>>> RevisionVersionProvider.class.getClassLoader().getResourceAsStream(file);
>>> if (in == null) {
>>> throw new VersionException(scope, fileName,
>>> "can't
>>> find " + file);
>>> }
>>>
>>>
>>> ClassLoader.getSystemResourceAsStream in my deployment enviroment, it
>>> always returned null for classpath resources. Using the
>>> RevisionVersionProvider classloader works fine.
>>>
>>> Let me know where I should post further patches etc.
>>>
>>> Jörn
>>>
>>> On Fri, Aug 29, 2008 at 11:29 AM, Stefan Fußenegger
>>> <st...@gmx.at> wrote:
>>>>
>>>> Code is now available through wicketsuff:
>>>>
>>>> https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-merged-resources/
>>>> wicketstuff-merged-resources and
>>>>
>>>> https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-merged-resources-examples/
>>>> wicketstuff-merged-resources-examples
>>>>
>>>> Now I want to make it available through
>>>> http://wicketstuff.org/maven/repository/. I therefore registered at
>>>> wicketstuff.org/teamcity (sfussenegger). What's next?
>>>>
>>>>
>>>> Stefan Fußenegger wrote:
>>>>>
>>>>> I just finished the 4th and last entry of my series "Wicket Interface
>>>>> Speed-Up" on my blog. To give a short summary: I investigated one of
>>>>> my
>>>>> apps with YSlow and started optimizing it's interface rendering speed
>>>>> [1].
>>>>> Especially Wicket's way of handling resources, i.e. JS and CSS files,
>>>>> causes interfaces to load rather slowly. In my articles, I explain how
>>>>> to
>>>>> modify the cache interval [2], how to mount resources with a version
>>>>> (e.g.
>>>>> /css/all-1234.css) in order to use aggressive client-side caching
>>>>> (e.g.
>>>>> resources expire after a year) [3]. Finally, I show how to merge
>>>>> resources
>>>>> at application startup (using a class classed MergedResourceStream) to
>>>>> reduce the number of resources a client has to download [4], including
>>>>> code). I was able to increase interface loading times considerably, so
>>>>> it's surely worth a look.
>>>>>
>>>>> I feel that it would also be worth to discuss, whether this work could
>>>>> be
>>>>> part of upcoming Wicket versions. For the time being I'd like to make
>>>>> the
>>>>> code attached to [4] a wicketstuff project - sfussenegger needs commit
>>>>> access ;) - and wait for your feedback.
>>>>>
>>>>> The links:
>>>>> [1]
>>>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html
>>>>> Wicket Interface Speed-Up
>>>>> [2]
>>>>>
>>>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html
>>>>> Wicket Interface Speed-Up: Modifying Expires and Cache-Control Headers
>>>>> [3]
>>>>>
>>>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-caching.html
>>>>> Wicket Interface Speed-Up: Caching Resources Forever
>>>>> [4]
>>>>>
>>>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-merging.html
>>>>> Wicket Interface Speed-Up: Merging Resources for Fewer HTTP Requests
>>>>>
>>>>
>>>>
>>>> -----
>>>> -------
>>>> Stefan Fußenegger
>>>> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19216657.html
>>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>
>>
>
>
-----
-------
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
--
View this message in context: http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19264974.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Discussion on "Wicket Interface Speed-Up"
Posted by Jörn Zaefferer <jo...@googlemail.com>.
Good point, I forgot that wicketstuff has its own JIRA installation.
Though the entry for the project is missing. Let me know once its
there, and I'll create the report.
Jörn
On Fri, Aug 29, 2008 at 12:26 PM, Peter Ertl <pe...@gmx.net> wrote:
> why don't you open up an issue in JIRA?
>
>
> Am 29.08.2008 um 12:22 schrieb Jörn Zaefferer:
>
>> Here is a first patch for the RevisionVersionProvider:
>>
>> Index:
>> src/main/java/org/wicketstuff/mergedresources/versioning/RevisionVersionProvider.java
>> ===================================================================
>> ---
>> src/main/java/org/wicketstuff/mergedresources/versioning/RevisionVersionProvider.java
>> (revision
>> 4147)
>> +++
>> src/main/java/org/wicketstuff/mergedresources/versioning/RevisionVersionProvider.java
>> (working
>> copy)
>> @@ -15,7 +15,7 @@
>>
>> public int getVersion(final Class<?> scope, final String fileName)
>> throws VersionException {
>> final String file = getResourcePath(scope, fileName);
>> - final InputStream in =
>> ClassLoader.getSystemResourceAsStream(file);
>> + final InputStream in =
>> RevisionVersionProvider.class.getClassLoader().getResourceAsStream(file);
>> if (in == null) {
>> throw new VersionException(scope, fileName, "can't
>> find " + file);
>> }
>>
>>
>> ClassLoader.getSystemResourceAsStream in my deployment enviroment, it
>> always returned null for classpath resources. Using the
>> RevisionVersionProvider classloader works fine.
>>
>> Let me know where I should post further patches etc.
>>
>> Jörn
>>
>> On Fri, Aug 29, 2008 at 11:29 AM, Stefan Fußenegger
>> <st...@gmx.at> wrote:
>>>
>>> Code is now available through wicketsuff:
>>>
>>> https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-merged-resources/
>>> wicketstuff-merged-resources and
>>>
>>> https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-merged-resources-examples/
>>> wicketstuff-merged-resources-examples
>>>
>>> Now I want to make it available through
>>> http://wicketstuff.org/maven/repository/. I therefore registered at
>>> wicketstuff.org/teamcity (sfussenegger). What's next?
>>>
>>>
>>> Stefan Fußenegger wrote:
>>>>
>>>> I just finished the 4th and last entry of my series "Wicket Interface
>>>> Speed-Up" on my blog. To give a short summary: I investigated one of my
>>>> apps with YSlow and started optimizing it's interface rendering speed
>>>> [1].
>>>> Especially Wicket's way of handling resources, i.e. JS and CSS files,
>>>> causes interfaces to load rather slowly. In my articles, I explain how
>>>> to
>>>> modify the cache interval [2], how to mount resources with a version
>>>> (e.g.
>>>> /css/all-1234.css) in order to use aggressive client-side caching (e.g.
>>>> resources expire after a year) [3]. Finally, I show how to merge
>>>> resources
>>>> at application startup (using a class classed MergedResourceStream) to
>>>> reduce the number of resources a client has to download [4], including
>>>> code). I was able to increase interface loading times considerably, so
>>>> it's surely worth a look.
>>>>
>>>> I feel that it would also be worth to discuss, whether this work could
>>>> be
>>>> part of upcoming Wicket versions. For the time being I'd like to make
>>>> the
>>>> code attached to [4] a wicketstuff project - sfussenegger needs commit
>>>> access ;) - and wait for your feedback.
>>>>
>>>> The links:
>>>> [1]
>>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html
>>>> Wicket Interface Speed-Up
>>>> [2]
>>>>
>>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html
>>>> Wicket Interface Speed-Up: Modifying Expires and Cache-Control Headers
>>>> [3]
>>>>
>>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-caching.html
>>>> Wicket Interface Speed-Up: Caching Resources Forever
>>>> [4]
>>>>
>>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-merging.html
>>>> Wicket Interface Speed-Up: Merging Resources for Fewer HTTP Requests
>>>>
>>>
>>>
>>> -----
>>> -------
>>> Stefan Fußenegger
>>> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19216657.html
>>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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: Discussion on "Wicket Interface Speed-Up"
Posted by Peter Ertl <pe...@gmx.net>.
why don't you open up an issue in JIRA?
Am 29.08.2008 um 12:22 schrieb Jörn Zaefferer:
> Here is a first patch for the RevisionVersionProvider:
>
> Index: src/main/java/org/wicketstuff/mergedresources/versioning/
> RevisionVersionProvider.java
> ===================================================================
> --- src/main/java/org/wicketstuff/mergedresources/versioning/
> RevisionVersionProvider.java (revision
> 4147)
> +++ src/main/java/org/wicketstuff/mergedresources/versioning/
> RevisionVersionProvider.java (working
> copy)
> @@ -15,7 +15,7 @@
>
> public int getVersion(final Class<?> scope, final String fileName)
> throws VersionException {
> final String file = getResourcePath(scope, fileName);
> - final InputStream in = ClassLoader.getSystemResourceAsStream(file);
> + final InputStream in =
> RevisionVersionProvider
> .class.getClassLoader().getResourceAsStream(file);
> if (in == null) {
> throw new VersionException(scope, fileName, "can't find " + file);
> }
>
>
> ClassLoader.getSystemResourceAsStream in my deployment enviroment, it
> always returned null for classpath resources. Using the
> RevisionVersionProvider classloader works fine.
>
> Let me know where I should post further patches etc.
>
> Jörn
>
> On Fri, Aug 29, 2008 at 11:29 AM, Stefan Fußenegger
> <st...@gmx.at> wrote:
>>
>> Code is now available through wicketsuff:
>> https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-merged-resources/
>> wicketstuff-merged-resources and
>> https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-merged-resources-examples/
>> wicketstuff-merged-resources-examples
>>
>> Now I want to make it available through
>> http://wicketstuff.org/maven/repository/. I therefore registered at
>> wicketstuff.org/teamcity (sfussenegger). What's next?
>>
>>
>> Stefan Fußenegger wrote:
>>>
>>> I just finished the 4th and last entry of my series "Wicket
>>> Interface
>>> Speed-Up" on my blog. To give a short summary: I investigated one
>>> of my
>>> apps with YSlow and started optimizing it's interface rendering
>>> speed [1].
>>> Especially Wicket's way of handling resources, i.e. JS and CSS
>>> files,
>>> causes interfaces to load rather slowly. In my articles, I explain
>>> how to
>>> modify the cache interval [2], how to mount resources with a
>>> version (e.g.
>>> /css/all-1234.css) in order to use aggressive client-side caching
>>> (e.g.
>>> resources expire after a year) [3]. Finally, I show how to merge
>>> resources
>>> at application startup (using a class classed
>>> MergedResourceStream) to
>>> reduce the number of resources a client has to download [4],
>>> including
>>> code). I was able to increase interface loading times
>>> considerably, so
>>> it's surely worth a look.
>>>
>>> I feel that it would also be worth to discuss, whether this work
>>> could be
>>> part of upcoming Wicket versions. For the time being I'd like to
>>> make the
>>> code attached to [4] a wicketstuff project - sfussenegger needs
>>> commit
>>> access ;) - and wait for your feedback.
>>>
>>> The links:
>>> [1]
>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html
>>> Wicket Interface Speed-Up
>>> [2]
>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html
>>> Wicket Interface Speed-Up: Modifying Expires and Cache-Control
>>> Headers
>>> [3]
>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-caching.html
>>> Wicket Interface Speed-Up: Caching Resources Forever
>>> [4]
>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-merging.html
>>> Wicket Interface Speed-Up: Merging Resources for Fewer HTTP Requests
>>>
>>
>>
>> -----
>> -------
>> Stefan Fußenegger
>> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
>> --
>> View this message in context: http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19216657.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> 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: Discussion on "Wicket Interface Speed-Up"
Posted by Stefan Fußenegger <st...@gmx.at>.
just applied your patch
could somebody please create wicketstuff-merged-resources in JIRA and
teamcity?
Jörn Zaefferer-2 wrote:
>
> Here is a first patch for the RevisionVersionProvider:
>
> Index:
> src/main/java/org/wicketstuff/mergedresources/versioning/RevisionVersionProvider.java
> ===================================================================
> ---
> src/main/java/org/wicketstuff/mergedresources/versioning/RevisionVersionProvider.java
> (revision
> 4147)
> +++
> src/main/java/org/wicketstuff/mergedresources/versioning/RevisionVersionProvider.java
> (working
> copy)
> @@ -15,7 +15,7 @@
>
> public int getVersion(final Class<?> scope, final String fileName)
> throws VersionException {
> final String file = getResourcePath(scope, fileName);
> - final InputStream in = ClassLoader.getSystemResourceAsStream(file);
> + final InputStream in =
> RevisionVersionProvider.class.getClassLoader().getResourceAsStream(file);
> if (in == null) {
> throw new VersionException(scope, fileName, "can't find " + file);
> }
>
>
> ClassLoader.getSystemResourceAsStream in my deployment enviroment, it
> always returned null for classpath resources. Using the
> RevisionVersionProvider classloader works fine.
>
> Let me know where I should post further patches etc.
>
> Jörn
>
> On Fri, Aug 29, 2008 at 11:29 AM, Stefan Fußenegger
> <st...@gmx.at> wrote:
>>
>> Code is now available through wicketsuff:
>> https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-merged-resources/
>> wicketstuff-merged-resources and
>> https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-merged-resources-examples/
>> wicketstuff-merged-resources-examples
>>
>> Now I want to make it available through
>> http://wicketstuff.org/maven/repository/. I therefore registered at
>> wicketstuff.org/teamcity (sfussenegger). What's next?
>>
>>
>> Stefan Fußenegger wrote:
>>>
>>> I just finished the 4th and last entry of my series "Wicket Interface
>>> Speed-Up" on my blog. To give a short summary: I investigated one of my
>>> apps with YSlow and started optimizing it's interface rendering speed
>>> [1].
>>> Especially Wicket's way of handling resources, i.e. JS and CSS files,
>>> causes interfaces to load rather slowly. In my articles, I explain how
>>> to
>>> modify the cache interval [2], how to mount resources with a version
>>> (e.g.
>>> /css/all-1234.css) in order to use aggressive client-side caching (e.g.
>>> resources expire after a year) [3]. Finally, I show how to merge
>>> resources
>>> at application startup (using a class classed MergedResourceStream) to
>>> reduce the number of resources a client has to download [4], including
>>> code). I was able to increase interface loading times considerably, so
>>> it's surely worth a look.
>>>
>>> I feel that it would also be worth to discuss, whether this work could
>>> be
>>> part of upcoming Wicket versions. For the time being I'd like to make
>>> the
>>> code attached to [4] a wicketstuff project - sfussenegger needs commit
>>> access ;) - and wait for your feedback.
>>>
>>> The links:
>>> [1]
>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html
>>> Wicket Interface Speed-Up
>>> [2]
>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html
>>> Wicket Interface Speed-Up: Modifying Expires and Cache-Control Headers
>>> [3]
>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-caching.html
>>> Wicket Interface Speed-Up: Caching Resources Forever
>>> [4]
>>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-merging.html
>>> Wicket Interface Speed-Up: Merging Resources for Fewer HTTP Requests
>>>
>>
>>
>> -----
>> -------
>> Stefan Fußenegger
>> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
>> --
>> View this message in context:
>> http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19216657.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
>
-----
-------
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
--
View this message in context: http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19218353.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Discussion on "Wicket Interface Speed-Up"
Posted by Jörn Zaefferer <jo...@googlemail.com>.
Here is a first patch for the RevisionVersionProvider:
Index: src/main/java/org/wicketstuff/mergedresources/versioning/RevisionVersionProvider.java
===================================================================
--- src/main/java/org/wicketstuff/mergedresources/versioning/RevisionVersionProvider.java (revision
4147)
+++ src/main/java/org/wicketstuff/mergedresources/versioning/RevisionVersionProvider.java (working
copy)
@@ -15,7 +15,7 @@
public int getVersion(final Class<?> scope, final String fileName)
throws VersionException {
final String file = getResourcePath(scope, fileName);
- final InputStream in = ClassLoader.getSystemResourceAsStream(file);
+ final InputStream in =
RevisionVersionProvider.class.getClassLoader().getResourceAsStream(file);
if (in == null) {
throw new VersionException(scope, fileName, "can't find " + file);
}
ClassLoader.getSystemResourceAsStream in my deployment enviroment, it
always returned null for classpath resources. Using the
RevisionVersionProvider classloader works fine.
Let me know where I should post further patches etc.
Jörn
On Fri, Aug 29, 2008 at 11:29 AM, Stefan Fußenegger
<st...@gmx.at> wrote:
>
> Code is now available through wicketsuff:
> https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-merged-resources/
> wicketstuff-merged-resources and
> https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-merged-resources-examples/
> wicketstuff-merged-resources-examples
>
> Now I want to make it available through
> http://wicketstuff.org/maven/repository/. I therefore registered at
> wicketstuff.org/teamcity (sfussenegger). What's next?
>
>
> Stefan Fußenegger wrote:
>>
>> I just finished the 4th and last entry of my series "Wicket Interface
>> Speed-Up" on my blog. To give a short summary: I investigated one of my
>> apps with YSlow and started optimizing it's interface rendering speed [1].
>> Especially Wicket's way of handling resources, i.e. JS and CSS files,
>> causes interfaces to load rather slowly. In my articles, I explain how to
>> modify the cache interval [2], how to mount resources with a version (e.g.
>> /css/all-1234.css) in order to use aggressive client-side caching (e.g.
>> resources expire after a year) [3]. Finally, I show how to merge resources
>> at application startup (using a class classed MergedResourceStream) to
>> reduce the number of resources a client has to download [4], including
>> code). I was able to increase interface loading times considerably, so
>> it's surely worth a look.
>>
>> I feel that it would also be worth to discuss, whether this work could be
>> part of upcoming Wicket versions. For the time being I'd like to make the
>> code attached to [4] a wicketstuff project - sfussenegger needs commit
>> access ;) - and wait for your feedback.
>>
>> The links:
>> [1]
>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html
>> Wicket Interface Speed-Up
>> [2]
>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html
>> Wicket Interface Speed-Up: Modifying Expires and Cache-Control Headers
>> [3]
>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-caching.html
>> Wicket Interface Speed-Up: Caching Resources Forever
>> [4]
>> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-merging.html
>> Wicket Interface Speed-Up: Merging Resources for Fewer HTTP Requests
>>
>
>
> -----
> -------
> Stefan Fußenegger
> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
> --
> View this message in context: http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19216657.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Discussion on "Wicket Interface Speed-Up"
Posted by Stefan Fußenegger <st...@gmx.at>.
Code is now available through wicketsuff:
https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-merged-resources/
wicketstuff-merged-resources and
https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-merged-resources-examples/
wicketstuff-merged-resources-examples
Now I want to make it available through
http://wicketstuff.org/maven/repository/. I therefore registered at
wicketstuff.org/teamcity (sfussenegger). What's next?
Stefan Fußenegger wrote:
>
> I just finished the 4th and last entry of my series "Wicket Interface
> Speed-Up" on my blog. To give a short summary: I investigated one of my
> apps with YSlow and started optimizing it's interface rendering speed [1].
> Especially Wicket's way of handling resources, i.e. JS and CSS files,
> causes interfaces to load rather slowly. In my articles, I explain how to
> modify the cache interval [2], how to mount resources with a version (e.g.
> /css/all-1234.css) in order to use aggressive client-side caching (e.g.
> resources expire after a year) [3]. Finally, I show how to merge resources
> at application startup (using a class classed MergedResourceStream) to
> reduce the number of resources a client has to download [4], including
> code). I was able to increase interface loading times considerably, so
> it's surely worth a look.
>
> I feel that it would also be worth to discuss, whether this work could be
> part of upcoming Wicket versions. For the time being I'd like to make the
> code attached to [4] a wicketstuff project - sfussenegger needs commit
> access ;) - and wait for your feedback.
>
> The links:
> [1]
> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html
> Wicket Interface Speed-Up
> [2]
> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html
> Wicket Interface Speed-Up: Modifying Expires and Cache-Control Headers
> [3]
> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-caching.html
> Wicket Interface Speed-Up: Caching Resources Forever
> [4]
> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-merging.html
> Wicket Interface Speed-Up: Merging Resources for Fewer HTTP Requests
>
-----
-------
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
--
View this message in context: http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19216657.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Discussion on "Wicket Interface Speed-Up"
Posted by Jörn Zaefferer <jo...@googlemail.com>.
Again, great work Stefan!
The basics already work fine, allowing me to keep a maintenance
friendly style of development while heavily optimizing frontend
performance.
The biggest isse now is the public API: I have to duplicate a lot of
information in the application and the page/component classes.
Eventually something like this could remove the duplication while
making it very easy to add new components and resources:
@HeaderContribution(
scripts={"jquery.js", "Example.js"},
stylesheets={"theme.js", "Example.css"}
)
public class Example {
public Example() {
HeaderContribution.addResources(this);
}
}
With something similar to wicketstuff-annotation in the Application#init method:
new AnnotatedResourcesMountScanner().scanPackage("my.package").mount(this);
A small issue, but still important: Please consider setting JDK 5 as
the goal for the project. JDK 6 is still unavailable on most OSX
installations and the one or two new methods aren't worth the trouble.
If you don't have plans to support JDK 1.4, it would be nice to
replace the various array-arguments with (generic)
varargs/collections.
Jörn
On Thu, Aug 28, 2008 at 11:59 AM, Stefan Fußenegger
<st...@gmx.at> wrote:
>
> I just finished the 4th and last entry of my series "Wicket Interface
> Speed-Up" on my blog. To give a short summary: I investigated one of my apps
> with YSlow and started optimizing it's interface rendering speed [1].
> Especially Wicket's way of handling resources, i.e. JS and CSS files, causes
> interfaces to load rather slowly. In my articles, I explain how to modify
> the cache interval [2], how to mount resources with a version (e.g.
> /css/all-1234.css) in order to use aggressive client-side caching (e.g.
> resources expire after a year) [3]. Finally, I show how to merge resources
> at application startup (using a class classed MergedResourceStream) to
> reduce the number of resources a client has to download [4], including
> code). I was able to increase interface loading times considerably, so it's
> surely worth a look.
>
> I feel that it would also be worth to discuss, whether this work could be
> part of upcoming Wicket versions. For the time being I'd like to make the
> code attached to [4] a wicketstuff project - sfussenegger needs commit
> access ;) - and wait for your feedback.
>
> The links:
> [1] http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html
> Wicket Interface Speed-Up
> [2]
> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html
> Wicket Interface Speed-Up: Modifying Expires and Cache-Control Headers
> [3]
> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-caching.html
> Wicket Interface Speed-Up: Caching Resources Forever
> [4]
> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-merging.html
> Wicket Interface Speed-Up: Merging Resources for Fewer HTTP Requests
>
> -----
> -------
> Stefan Fußenegger
> http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
> --
> View this message in context: http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19197540.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Discussion on "Wicket Interface Speed-Up"
Posted by ywtsang <yw...@gmail.com>.
nice
we are also taking efforts in optimizing the webapp
as we serve the resources (images/css/js) using 3rd content provider, our
approach is different from your wicket-focus turning; but it indeeds give me
some insight, thanks
we also want to "merge" the css/js files, but after thinking carefully, it
can't work for us
because we are using "header contribution" at different panels, it is very
flexible for the designers to split the css/js files according to the panel
and they like it very much for the flexibility, maintainability and
reusability
however, since a panel can hide/show dynamically for the same url in
different times (though not common, but we can't avoid that), that means we
can't simply "merge" different css/js files from different panels for the
given page
Stefan Fußenegger wrote:
>
> I just finished the 4th and last entry of my series "Wicket Interface
> Speed-Up" on my blog. To give a short summary: I investigated one of my
> apps with YSlow and started optimizing it's interface rendering speed [1].
> Especially Wicket's way of handling resources, i.e. JS and CSS files,
> causes interfaces to load rather slowly. In my articles, I explain how to
> modify the cache interval [2], how to mount resources with a version (e.g.
> /css/all-1234.css) in order to use aggressive client-side caching (e.g.
> resources expire after a year) [3]. Finally, I show how to merge resources
> at application startup (using a class classed MergedResourceStream) to
> reduce the number of resources a client has to download [4], including
> code). I was able to increase interface loading times considerably, so
> it's surely worth a look.
>
> I feel that it would also be worth to discuss, whether this work could be
> part of upcoming Wicket versions. For the time being I'd like to make the
> code attached to [4] a wicketstuff project - sfussenegger needs commit
> access ;) - and wait for your feedback.
>
> The links:
> [1]
> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up.html
> Wicket Interface Speed-Up
> [2]
> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-modifying.html
> Wicket Interface Speed-Up: Modifying Expires and Cache-Control Headers
> [3]
> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-caching.html
> Wicket Interface Speed-Up: Caching Resources Forever
> [4]
> http://talk-on-tech.blogspot.com/2008/08/wicket-interface-speed-up-merging.html
> Wicket Interface Speed-Up: Merging Resources for Fewer HTTP Requests
>
--
View this message in context: http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19212465.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org