myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Werner Punz <>
Subject Re: Dojo + myfaces upfront refactoring warning
Date Fri, 10 Mar 2006 21:12:37 GMT
Mike Kienenberger schrieb:
> On 3/10/06, Laurie Harper <> wrote:
>> Werner Punz wrote:
>>> Afterwards I also contacted Mario who does the current refactoring of
>>> the addresource, and he said he would prefer to have this stuff in the
>>> body due to future performance refactoring reasons.
>>> So I am going to move the require and component includes down to the
>>> body while the dojo include still stays in the head for now.
>> Hmm, I thought there were XHTML compliance issues with having <script>
>> tags in the body? That's why I queried this in the first place :)
>> Although it appears to work, valid or not.
> I believe the reason for this is to remove the need for the Extensions
> filter.   While there's some question as to the standards compliance,
> Adam Winer reported that ADF Faces also does the same thing for the
> same reason -- put the scripts in the body to avoid the need for a
> servlet filter.
Actually to my knowledge of the extension filter mechanisms this does 
not have anything to do with it.

The main purpose of the filter is a resource loader, the filter more or 
less just serves scripts upon requests directly from the jar,
The pushing down to the body adds another performance improvement point.
As is if you want to push something into the head you have to keep an 
extre pre gathering step for request singletons.
Once a component says I want to have something in the head you have to 
collect the data first and then at a later stage do the rendering once 
all the components have pushed all their data into the singleton.

If you can rely on not having such mechanisms but having everything 
rendered on the fly (which is only possible if you push everything into 
the body) means you can skip the extra step in the rendering phase and 
start the rendering per component, which means a straig runtime 
complexity of n  up to n log(n) instead of 2n up to 2n log(n) for the 
rendering (depending of the operations).

Also it means way less mem consumption since the code is written as
it is called instead of having to go through an extra data collection 

But back to the topic
Well as for now the main dojo initialisation still is performed in the 
head but it will be moved into the body in the long run as well, the 
require has to be moved to already mentioned reasons.

View raw message