[dojo-contributors] dijit: removing id attributes in favor of widgetid

Scott J. Miles sjmiles at turboajax.com
Fri Aug 31 19:16:30 EDT 2007


Since the widgetId is guaranteed unique in the document (right?) it also 
makes a perfect DOM id.

For my $0.02, I would suggest it should be copied on to the node in 
absence of an override.

Regards,
Scott J. Miles
TurboAjax Group
www.turboajax.com

Tom Trenka wrote:
> I guess it's not so much a request as much as it's an asking for a 
> reason; if there's a good reason for doing it that way, I'm game for it.
> 
> trt
> 
> On 8/31/07, *Owen Williams* <owen at smartsoul.com 
> <mailto:owen at smartsoul.com>> wrote:
> 
> 
>     I think Tom's request is reasonable, perhaps it's just an oversight
>     that some widgets put the ID on the outer element, and some do not?
>     Seems like something we should standardize, as Tom's right that
>     styling without this will be an effing pain.
> 
>     thanks
>     Oe must be the change we wish to see in the world.   -- Mohandas K.
>     Gandhi
> 
> 
>     On Aug 30, 2007, at 6:09 PM, peter e higgins wrote:
> 
>      >
>      > I won't chime in like I know the reason, but the behavior is
>      > intended, yes.
>      > Some widgets with templates set id="${id}" on the first element
>     in the
>      > template, which provides the CSS access you are looking for, but
>      > others do
>      > not.
>      >
>      > the part in:
>      > http://trac.dojotoolkit.org/attachment/ticket/4063/presentation.patch
>      >
>      > that patches dijit/_Widget.js seems like it would fix what you are
>      > trying to
>      > do.
>      >
>      >
>      > On Friday 31 August 2007 12:53, Tom Trenka wrote:
>      >> Hi guys,
>      >> So in doing a lot of porting work from 0.4 to 0.9 with Dijit,
>      >> we've run
>      >> across a number of problems (many of them not Dijit-related), but
>      >> there's
>      >> one that stands out that seems like a deliberate choice.
>      >> Basically, it
>      >> seems that Dijit will take something like this:
>      >>
>      >> <div dojoType="dijit.Menu" id="myMenu"></div>
>      >>
>      >> ...and in the process of rendering, will change it to this:
>      >>
>      >> <table dojoType=" dijit.Menu" widgetid="myMenu"></table>
>      >>
>      >>
>      >> We haven't had any real issues with node swapping (i.e. the div ->
>      >> table
>      >> here), but not having the original ID available is causing us major
>      >> headaches, particularly when we run into a situation where we need
>      >> to be
>      >> able to define styles on very specific elements within a single
>      >> instance of
>      >> a Dijit.  In several places in this application, I've been forced
>      >> to pull
>      >> something like this:
>      >>
>      >> dojo.query("*[widgetid='myMenu']").forEach(function(node){ ...do
>      >> something... };
>      >>
>      >> ...in order to get access to help style internal structures (this
>      >> particular example came from trying a method of creating custom
>      >> icons on
>      >> tree nodes with dijit.Tree, but you get the idea).  In particular,
>      >> I've run
>      >> across a situation where we have a dijit.Menu that needs to
>      >> stretch to fill
>      >> the pane that it's placed in, and then be able to set widths on the
>      >> individual cells that are created.  To do this, I had to pull
>      >> something
>      >> like the following:
>      >>
>      >> dijit.byId("myMenu").domNode.style.width="100%";
>      >> var rows=dijit.byId("myMenu").domNode.tBodies[0].rows;
>      >> for(var i=0; i< rows.length; i++){
>      >>     rows[i].cells[0].style.width="16px";  // icon cell
>      >>     rows[i].cells[1].style.width="90%";  // label cell, stretch to
>      >> fill
>      >>     rows[i].cells[2].style.width= "16px"; // arrow cell,
>     regardless if
>      >> there's an arrow or not.
>      >> }
>      >>
>      >> This works ok for our situation because we only have one level of
>      >> items
>      >> ( i.e. no submenus), but it would have been a lot more intuitive to
>      >> pull
>      >> this in CSS for the overall width and the label:
>      >>
>      >> table#myMenu{ width:100%; }
>      >> table#myMenu tbody tr td.dijitMenuLabelItem{ width:90%; }
>      >>
>      >> ...but then we have no access to style the width of either the
>      >> icon cell or
>      >> the arrow one (inspecting the HTML shows both only have
>      >> "dijitReset" as
>      >> class names).
>      >>
>      >> My question (after all that) is this:  is there a reason why Dijit
>      >> shifts a
>      >> user-defined id to widgetid?  To give an example (along the lines
>      >> above) of
>      >> why this can be a bad thing, imagine what I'd have to do to make
>      >> the above
>      >> CSS work correctly:
>      >>
>      >> table[widgetid='myMenu]{ width:100%; }
>      >> table[widgetid='myMenu] tbody tr td.dijitMenuLabelItem{ width:90%; }
>      >>
>      >> ...which will (of course) not work in Internet Explorer at all.
>      >>
>      >> Thoughts?  Answers?
>      >>
>      >> Thanks--
>      >> trt
>      > ______________________________ _________________
>      > dojo-contributors mailing list
>      > dojo-contributors at dojotoolkit.org
>      > http://dojotoolkit.org/mailman/listinfo/dojo-contributors
> 
>     ______________________________ _________________
>     dojo-contributors mailing list
>     dojo-contributors at dojotoolkit.org
>     http://dojotoolkit.org/mailman/listinfo/dojo-contributors
> 
> 
>  
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at dojotoolkit.org
> http://dojotoolkit.org/mailman/listinfo/dojo-contributors



More information about the dojo-contributors mailing list