not the Jar files, the WebApp -> find the used WebApp-class and get the
HomePage and follow the links to the used Webpage-classes and put them
all together in a walk-list (similar to what a search engine bot does)
and put together the associated CSS + JS, as this are the *really used*
resources.
of course the walk-list should also have a way to define an additional
ignore list where resources (perhaps based on regular expressions?) can
be defined to be ignored (and so only loaded later when they are really
needed) - if a class is not on the walklist (or it is on the
ignore-list) we know its not having default-resources and we could just
go the current way of adding all resources that are on that page.
We end up with 2 files - a CSS and a JS default-resource that are bigger
than usual (but could be compressed) and that save bandwith at
runtime... seems not so dramatical to me?
Remember, the problem of having a maximum of 30 Resource-refrences
beeing actually allowed by some browser means that the idea behind
wicket (have components with their own markup) only works for pages with
less than the allowed amount of resources. So you have components with
usually 2-3 resources this limits to a maximum of 10 to 12 components
per page before some browser will have problems...
Best,
Korbinian
Johan Compagner schrieb:
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
--
____________________________________
whiskyworld e.K.
http://www.whiskyworld.de
Ziegelfeld 6
94481 Grafenau/ Haus im Wald
Tel. 08555/ 406 320
Fax. 08555/ 406 319
Amtsgericht Passau: HRA 11760
Geschäftsführer: Franz Bachl
UstID: DE193152422
________________________________
