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] > >