Hmmm. As you say, there's no easy one-size-fits-all.
There is an obvious improvement you could make, though. All JS/CSS
contributions initially rendered on the home page could be batched up. This
will typically provide the biggest improvement anyway. You could then keep a
reference to this batch, and use it instead of individually including any of
these constituent contributions elsewhere.
This would also give fairly intuitive behaviour - if you want to pre-load
your JS/CSS in a single batch, just add the headercontributors to your home
page, and Wicket will figure it out.
I've long hated having to specify the component class in header
contributors, as 99% of the time the resources live in the same package (or
in a subpackage) as the component they belong to.
I'd even go so far as to remove the need for HeaderContributor code entirely
in 80% of the cases.
Wicket could automatically pick up css and js files that are named the same
as your component.
MyComponent.java
MyComponent.html
MyComponent.properties
So why not:
MyComponent.css
MyComponent.js
?
Heck, you could even include i18n for dealing with language-specific layout
issues:
MyComponent_jp.css
Regards,
Al
2008/9/3 richardwilko <[EMAIL PROTECTED]>
>
> I see your point, essentially we have 1 (relativity large) bundle file per
> page, and if you have 5 pages which use jquery, tinymce and ajax then you
> are worse off, since the normal way you would have already cached the 3
> individual files (this is what you meant right?)
>
> Maybe there is some way to automatically work out the best bundles to
> create
> depending on usage, so dont create bundles based on page, but based on
> contents?
>
> I think the real answer is that everyones usage is different and what is
> good for one system isn't good for another.
>
>
> igor.vaynberg wrote:
> >
> > It's not the pages that have these files. Let's say I have a page that
> > uses jquery and a textfield with a button that toggles tinymce.
> >
> > If we do what you say then there are two possible files: jquery and
> > jquery+tinymce.
> >
> > Than let's say I add Ajax to the page, now there are 6 possibilities
> > depending on which components are currently on the page.
> >
> > IMHO much cheaper to just cache jquery, tinymce, wicket-Ajax
> individually.
> >
> > -Igor
> > On 9/3/08, richardwilko <[EMAIL PROTECTED]> wrote:
> >>
> >> im not sure we could help in the cases where you have dynamic header
> >> contributors, like you say you would either have to specify them up
> front
> >> (ie add them into the page not the panel, breaking encapsulation) or
> just
> >> serve via the normal header contributor.
> >>
> >> But i dont see how this would result in many many large files. you
> would
> >> have a single file for the static stuff, and then each dynamic one would
> >> have its own file (assuming not specified up front). This would still
> >> bring
> >> down the total number.
> >>
> >> eg a page has 6 static js and 2 dynamic js which would get turned into 1
> >> static js and the same 2 dynamic js.
> >>
> >> cases where a component and resulting header contributers are added via
> >> ajax
> >> wouldnt be important for the initial page load speed anyway, as they are
> >> added after the page has loaded.
> >>
> >> Richard
> >>
> >>
> >> igor.vaynberg wrote:
> >>>
> >>> problem with this is that pages can have dynamic components which
> >>> dynamic header contributions.
> >>>
> >>> so either you have to somehow collect all possible header
> >>> contributions from all possible component combinations - breaking
> >>> encapsulation in the process, or you have to do what you do - ending
> >>> up with many many possible and big javascript files to serve to the
> >>> user.
> >>>
> >>> -igor
> >>>
> >>> On Tue, Sep 2, 2008 at 2:57 PM, richardwilko
> >>> <[EMAIL PROTECTED]> wrote:
> >>>>
> >>>> The problem of breaking encapsulation:
> >>>>
> >>>> I did some work on this problem on my own a few months ago, my
> solution
> >>>> was
> >>>> to use a header contrib manager, and instead of adding files with a
> >>>> header
> >>>> contributer i add them to the manager, then get a single contributer
> >>>> per
> >>>> page from the manger.
> >>>>
> >>>> for example in a panel you would do
> >>>>
> >>>> @Override
> >>>> protected void onBeforeRender() {
> >>>> super.onBeforeRender();
> >>>> ResourceReference rr = new
> ResourceReference(getClass(),
> >>>> "test.js");
> >>>> WicketApplication.get().getHcm().add(rr,
> >>>> getPage().getClass());
> >>>> }
> >>>>
> >>>> See how it uses getPage().getClass(), so the manager knows which class
> >>>> the
> >>>> panel is being added into
> >>>>
> >>>> then in the main page class
> >>>>
> >>>> @Override
> >>>> protected void onBeforeRender() {
> >>>> super.onBeforeRender();
> >>>>
> >>>>
> >>>>
> add(WicketApplication.get().getHcm().getHeaderContributor(getClass()));
> >>>> }
> >>>>
> >>>> since the manager knows all of the resources added for the page at
> this
> >>>> point, it is easy to compress them all together and serve a single
> >>>> file,
> >>>> and
> >>>> you dont have to list the files up front.
> >>>>
> >>>> What do you think of this idea?
> >>>>
> >>>> My code is here:
> >>>> http://www.nabble.com/file/p19279269/HeaderContribManagerTest.zip
> >>>> HeaderContribManagerTest.zip
> >>>>
> >>>> It still has bugs etc in it, and doesnt really work cos ive messed up
> >>>> the
> >>>> registerResource method, but you should be able to get the idea from
> it
> >>>>
> >>>> Richard
> >>>>
> >>>>
> >>>>
> >>>> -----
> >>>> http://www.richard-wilkinson.co.uk My blog:
> >>>> http://www.richard-wilkinson.co.uk
> >>>> --
> >>>> View this message in context:
> >>>>
> http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19279269.html
> >>>> Sent from the Wicket - User mailing list archive at Nabble.com.
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>>> For additional commands, e-mail: [EMAIL PROTECTED]
> >>>>
> >>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>> For additional commands, e-mail: [EMAIL PROTECTED]
> >>>
> >>>
> >>>
> >>
> >>
> >> -----
> >> http://www.richard-wilkinson.co.uk My blog:
> >> http://www.richard-wilkinson.co.uk
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19289766.html
> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
>
>
> -----
> http://www.richard-wilkinson.co.uk My blog:
> http://www.richard-wilkinson.co.uk
> --
> View this message in context:
> http://www.nabble.com/Discussion-on-%22Wicket-Interface-Speed-Up%22-tp19197540p19290662.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
