[Dojo-interest] HEEELP: parseWidget=false does not work?
zluspai at gmail.com
Sat Apr 8 14:13:59 MDT 2006
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:
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:
<table> <!-- heavy table with 100s of rows-->
<dojo tooltip connectid="row155" /> <!--
for some cells-->
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... :-)
> 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
More information about the Dojo-interest