ha, i proposed this months ago and you said it wasnt a good idea! i remember you argument, which made sense to me, was:
on one page you will have &js=1,5,3,4,1 and on another page because you havent included some panel it would be &js=1,5,3 which will result in reloading js from 1 5 3 instead of it being cached from the first page. so there is a trade off, you can have many smaller but cachable requests, or you can have one huge request with a more likely cache miss. -igor On Feb 5, 2008 4:21 AM, Matej Knopp <[EMAIL PROTECTED]> wrote: > 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 >
