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]
