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

James Burke jburke at dojotoolkit.org
Fri Aug 31 20:57:37 EDT 2007


This comment:
http://trac.dojotoolkit.org/ticket/4191#comment:2

seems to indicate that ID should be copied, but it is not in place for
all widgets yet (perhaps fixed with #3058 gets applied?).

James

On 8/31/07, Scott J. Miles <sjmiles at turboajax.com> wrote:
> 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
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at dojotoolkit.org
> http://dojotoolkit.org/mailman/listinfo/dojo-contributors
>



More information about the dojo-contributors mailing list