Slow Resources rendering time in 2-5-x

[Knoop, Peter]

It sounds like we need someone to test the newer version of Dojo to see
if it helps.  Is that something you could do Colin, or perhaps someone
else on one of these lists?

Thanks.

-peter

> -----Original Message-----
> From: Colin Clark [mailto:colin.clark at utoronto.ca]
> Sent: Sunday, March 30, 2008 9:45 PM
> To: Clay Fenlason
> Cc: sakai-dev at collab.sakaiproject.org;
content at collab.sakaiproject.org;
> fluid-work at fluidproject.org
> Subject: Re: Slow Resources rendering time in 2-5-x
> 
> Hi all,
> 
> Sorry for the delay in responding. I've been really sick with the flu
> for the past several days...
> 
> On 27-Mar-08, at 2:09 PM, Clay Fenlason wrote:
> >> Are the dojo/dijit buttons a dead-end or can they be improved?
> >
> > I don't know, but perhaps a JS maven on the Fluid lists might have
> > some suggestions.  Colin or Eli?  Client-side caching of some sort?
> 
> A quick profiling with Firebug does show an *awful* lot of cycles
> being sunk into the Dojo rendering process. My first suggestion is to
> upgrade to Dojo 1.1. I know they did a lot of performance tweaking for
> 1.0 and beyond. It's likely a trivial upgrade, and worth a shot as a
> quick fix.
> 
> As for Dijit's long-term prospects for improvement, that's an
> difficult question. It's a great toolkit, and I have colleagues who
> have invested a lot of hard work and diligence in making it the first
> accessible DHTML toolkit. But I'll be honest in saying that it can be
> very heavyweight. One of the reasons it can be slow is that It always
> imposes a significant amount of client-side template rendering, even
> for simple cases where the server could have easily produced a fully-
> baked DOM for the widget.
> 
> Indeed, this is one of the reasons I've encouraged markup over JSON in
> many circumstances. It's faster and it has the potential to degrade
> gracefully.
> 
> If the Dojo 1.1 version doesn't improve the performance problems, I'd
> suggest we proceed first by re-evaluating the user interface a little
> bit. Why are we using custom-built menu widgets in the first place? Is
> there anything they provide that a standard HTML select drop-drown
> can't?
> 
> If we want to stick with a custom DHTML widget instead of a standard
> form element, I'd be willing to help roll a simple alternative to the
> Dijit drop-down button. Fluid's recent work on jQuery accessibility
> plugins will be pretty useful for this. Here's a simple sketch of what
> I'm thinking:
> 
> Some decently semantic, Velocity-rendered markup for the drop-down:
> 
> <span id="drop-down-button">
> <a href="#">Add...</a>
> <ol id="menuItems" class="closed">
> <li><a href="...">Upload Files</a></li>
> <li><a href="...">Create Folders</a></li>
> <li><a href="...">Add Web Links (URLs)</a></li>
> <li><a href="...">Add Citation List</a></li>
> <li><a href="...">Create HTML Page</a></li>
> <li><a href="...">Create Text Document</a></li>
> </ol>
> </span>
> 
> And some simple JavaScript code using my plugin to make it keyboard
> navigable:
> 
> initComboButton: function (buttonId) {
> var buttonContainer = $("#" + buttonId);
> buttonContainer.tabbable(); // Put the button in the tab order
> buttonContainer.activatable(activateButton); // Make it activatable
> with Enter & Space
> 
> var menuItems = $("#menuItems > li", buttonContainer);
> // Make each menu items selectable with the arrow keys
> menuItems.selectable(buttonContainer, selectionHandlers());
> menuItems.activatable(activateOption);
> }
> 
> Add some ARIA semantics using the jARIA plugin, and we're pretty much
> done.
> 
> Hope this helps,
> 
> Colin
> 
> ---
> Colin Clark
> Technical Lead, Fluid Project
> Adaptive Technology Resource Centre, University of Toronto
> http://fluidproject.org
> 
> ----------------------
> This automatic notification message was sent by Sakai Collab
> (https://collab.sakaiproject.org/portal) from the DG: Content & Author
> site.
> You can modify how you receive notifications at My Workspace >
> Preferences.