Ignoring the iPhone - not everyone has that as a target platform - the
bruteforce method of packaging everything into one file isn't that
bad. The initial bandwidth hit is outweighed be reducing requests to
one (or two, one js, one css file). That means the first page loads a
bit longer, which is normal in most cases anyway, while all other
pages loaded afterwards need no additional css/js at all, therefore
being potentially lightning fast.
Putting all page specific scripts into one file isn't trivial. I've
found that its very easy to handle by starting each script to check if
a certain dom element, selected via ID, exists. In my case, using
jQuery, something like this:
Subpage.js
jQuery(function($) {
if ($("#somePageSpecificId").length) {
// Subpage is active, do something
}
});
ID selectors should have no performance impact at all, as long as
there aren't thousands of them, which is very unlikely in this
scenario.
The same applies to CSS, where page specific styles are "namespaces"
with parent ids - same concept, easier to write.
If you *are* targeting the iPhone, you proably shouldn't load a full
library and tinymce and what not anyway...
Jörn
On Wed, Sep 3, 2008 at 4:21 PM, Matej Knopp <[EMAIL PROTECTED]> wrote:
> There is yet another thing to consider. Iphone doesn't cache resources
> bigger than 25kb (after unzipping). So instead of grouping files
> together sometimes it even might be appropriate to split them...
>
> -Matej
>
> On Wed, Sep 3, 2008 at 4:11 PM, <[EMAIL PROTECTED]> 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]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
