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
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)
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
> >>>>
>
>
