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
<[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
