[Dojo-interest] HEEELP: parseWidget=false does not work?

[Zoltan Luspai]

Jon,

Jon Sykes wrote:

> I haven't looked, but sure widget parsing is done onload?

Yes, it is done onload.

>
> If it's done in the head, the rest of the page hasn't loaded so the  
> widgets don't exist.

You are right; that was a bug in my script as Brian pointed out too. In 
fact I tried that, but I could not make it work, because of the bugs I 
was not aware of, one is that you can not add a dojo widget's id to 
djConfig.searchIds, but you must use it's parent. See this bug here: 
http://trac.dojotoolkit.org/ticket/187
But my script does work around this, by parsing the widget's parent 
instead of the widget directly.

>
> I may be wrong, but there is NO different between a page that is  
> server side generated with hundreds of JSP includes, and a static  
> page.  They are both servered the same way in the same order when the  
> page is loaded by the browser.
>
> Or am I missing something.

My story is:

    I have several pages which are using some templating on server side 
to have common header and such. We have changed all these pages to use 
the excellent SplitContainer widget to improve usability, and we use 
other dojo widgets (like tooltips around).
    Because some of the pages are heavy it has turned out that we need 
to use the searchIds workaround and do manual parsing. I've also found 
that if you use the searchId at any places then the automatic dojo 
parsing will be turned off completely. (As you can see it in: 
hostenv_browser.js --> dojo.hostenv.makeWidgets function).
    This is already a problem, because if we use the searchIds anywhere 
that will force us to change it EVERYWHERE around the pages, as they are 
interdependent to each other (via templating). That's however can be 
lived with if you invest some time to it :-)...
    Yet another -more important- problem is that the heavy parts of the 
pages are inside a mentioned SplitContainer dojo widget. For example the 
page looks like something like this:

     <splitContainer id="part1">
             <table> <!-- heavy table with 100s of rows-->
                      <tr>
                            <td id="row155">
                                <dojo tooltip connectid="row155" /> <!-- 
for some cells-->
                            </td>
                      </tr>
             </table>
     </splitContainer>

   That means that even if I add the splitContainer to the searchIds, 
that will not help in performance, because all the heavy parts of the 
pages are still parsed !
   Therefore my suggestion is that the dojo parser should stop below the 
splitContainer at the <table> if I add a parseWidget="false" attribute 
to this. This will immediately help, because those 100s of rows will not 
need to be parsed!
    Of course there's still one problem left: the <dojo tooltip> should 
still be parsed, which can be done, if I add it to the searchIds array.

Finally to save the work of adding searchIds all around the application 
I've decided to leave the automatic parsion on, but use a different 
array variable similar to searchIds, where I collect only those widgets 
which are left unparsed, because they are inside a parseWidget="false" 
block. This means I don't have to change all my pages to use searchIds, 
just only the heavy parts, and these changes will be all local to single 
jsps, that's much easier to manage.

That's it; sorry for poor English... :-)
Zoltan



>
> Jon Sykes
>
>
> On Apr 8, 2006, at 8:45 AM, Zoltan Luspai wrote:
>
>> The real problem with the djConfig.searchIds is that it does not  
>> allow dynamic pages, those which are built on server side, because  
>> the widget ids are not yet known when the dojo.js is already loaded  
>> in the header.
>
>
> _______________________________________________
> Dojo FAQ: http://dojo.jot.com/FAQ
> Dojo-interest at dojotoolkit.org
> http://dojotoolkit.org/mailman/listinfo/dojo-interest
>