Maybe we could have header contribution as we have now, but without writing the <script / <link tags immediately. We would just remember url, and then assign a unique id to each package reference (stored in application);
Thank we could generate resources like /resource/wicket/javascript&js=1,5,3,4,5,7 etc. The complicated part would be to make sure that the url stays stable (e.g. the ids stay stable so each javascript resource gets same id) between application restarts. The id could be some kind of hash including the last modified time. (just thinking loud) -Matej On Feb 5, 2008 12:50 PM, Johan Compagner <[EMAIL PROTECTED]> wrote: > scan all the jar files and include everything upfront even things that wil > never be used? > > those js and css files would huge.... > > if we would do that with js. then just wicket.jar and wicket > extentions.jarwould result in a file > that would be all the stuff from the basic event/ajax to the modal stuff in > one file? > > Then we just hope that some where it wouldn't conflict.. > > johan > > On Feb 5, 2008 12:33 PM, Korbinian Bachl - privat < > > [EMAIL PROTECTED]> wrote: > > > Hello, > > > > some time age there was a thread where sb. had problems because they > > used more CSS references (in their pages combined of many panels) than > > the IE would actually load in the end (some limit of around 30 I think). > > > > Today I surfed to theserverside.com and this one cathced my interest: > > http://www.theserverside.com/news/thread.tss?thread_id=48318 > > > > based on that idea, I wondered if it would make sense to have wicket > > scan at start *all* CSS + JS references of a webapp and unite them into > > 1 file each that would be compressed and then only deliver this file > > from that time on (cached - of course this should be possible to > > disable/ enable vie the init() to also allow current behaviour, and > > maybe allow to exclude certain recources from default). > > > > This would lead to the effect that the needed JS + CSS would only be > > loaded once on wicket apps as browsers cache these things (usually even > > longer than 1 visit) which would reduce overall bandwith and > > server-usage (no more multi panel-for-CSS/ JS scanning that is done > > currently at each page-creation) as well as page-loading times for > > end-users of the webapps. > > > > Now, what do you think? Would this be a good idea for 1.4 or not? > > > > > > Best, > > > > Korbinian > > > -- Resizable and reorderable grid components. http://www.inmethod.com
