Im not sure if I understood it right,
Johan Compagner schrieb:
But if you want to program it your self (making that list)
why not combine it your self and add that combined resource to the shared
resources
Im thinking of situations where you use already existant wicket
components - e.g: you use the date-picker on every page of your calender
application, then you could have it in the default-resource CSS + JS and
save loading time/ bandwith/ requests (plus having more slots left on
the browser for other css resources) - having to plug these things
manually would mean to examine it every time you use a drop-in
replacement for a component (whats also a cool thing with wicket ->
upgrade usually means newer JAR of a component if its packed, or just a
copy of the files into the tree)
for every key that you did combine (so that if one is asked for you get the
same)
i only dont know if that really works correctly (because then 2 that are
combined should result in 1 output)
yeah, especially 1 outputfile for the defaultCSS-set (instead of X
nearly always needed files) would also speed up loading time as most
browsers limit their concurrent requests to 1 server to a special number
(e.g: 4 on IE default, 2 on FF) - because of this, YUI for example
suggests to use their servers for YUI files (as its faster for end user)
and the problem of having same CSS keys (in combining) could be solved
like browsers do it -> later ones overwrite earlier ones (thats pretty
the webstandard)
Best,
Korbinian
johan
On Feb 6, 2008 10:33 AM, Korbinian Bachl - privat <
[EMAIL PROTECTED]> wrote:
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
