On Feb 5, 2008 5:54 PM, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > 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. Yeah, it would probably only make sense to have some kind of grouping, so that it would be more granular. Anyway, I don't see this as a feature for 1.4. Doesn't seem to urgent to me.
-Matej > > -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 > > > -- Resizable and reorderable grid components. http://www.inmethod.com
