ok, johan, thanks for the info about that - now, im not 100% sure if
this then may work but couldnt we allow the developer to at least define
a List<Resources> defaultCSSResources / defaultJSResources to provide
the ability to have a cached default CSS and JS resource-files that
combine the added Resource's of the list?
e.g: in the init you'll do
List drl = new DefaultResourcesList();
drl.addDefaultResource("path to it/A.css");
drl.addDefaultResource("path to it/B.css");
...
mountDefaultResourcesList(CSS, drl, "myNiceDefaultName.css");
and wicket only adds then resources based on the current page if it isnt
part of the mounted DefaultResourceList?
So we can give the developer the way to combine often needed Resources
while he usually knows best what size is maximum and what he needs often
as a defaultResource and also allow him to overcome the maximum-resource
limitation of some browsers quite easy - the path to the resource could
include a hash (like matej said) based on the defaultResourceList, so it
even would be stable over app-restarts if nothing of the CSS has changed.
Is this idea better then?
Best,
Korbinian
Johan Compagner schrieb:
follow the links?
the links are in java code, you have no idea what is all coming thats pretty
much impossible to do.
also in my case (i have hit that target hard at this time for us) where we
can have a huge number
of tabs that are replaced with ajax calls and all the tabs can have 1 or
more css. Thats all pretty much completely dynamic.
We have no idea what is really coming. I could go over every possible tab
there is and gather every css
but then the first hit to the applicaiton would maybe download more then 1MB
for the first time
johan
On Feb 5, 2008 6:52 PM, Korbinian Bachl - whiskyworld <
[EMAIL PROTECTED]> wrote:
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
