in html: <html> <head> <wicket:head> <wicket:link> <link href="MyComponent.css" rel="stylesheet" /> <script src="MyComponent.js" type="text/javascript"> </script> </wicket:link> </wicket:head> </head> <body> <wicket:panel> some foo.... </wicket:panel> </body> </html>
Which has the added bonus of being previewable. Martijn On Wed, Sep 3, 2008 at 5:34 PM, Al Maw <[EMAIL PROTECTED]> wrote: > 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] >> >> > -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.3.4 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]