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 >
