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]
