[Cosmo-dev] Getting a handle on specific UI elements

[Bobby Rullo]

On Dec 11, 2006, at 1:27 PM, Matthew Eernisse wrote:

> More comments inline ...
>
> Bobby Rullo wrote:
>> Yeah, I don't think we should get too clever about figuring out  
>> the parent widget or whatever, my reasoning is that if you change  
>> the implementation (maybe have a different widget hierarchy or  
>> something) your id's all change, even though nothing changed to  
>> the user. And then Adam comes over complaining.
>
> This is a valid point, although it seems pretty likely to me that  
> changes in the actual widget hierarchy would only be driven by real  
> changes in the UI -- after all, the JS namespace for a widget just  
> reflects its logical position in the UI -- e.g.,  
> app.modalDialog.buttonPanel.

I disagree. I already want to refactor the way modalDialog works  
right now - if we go ahead with that, and follow some namespacing  
idea based on implementation of widgets, the ids will change.

And I've already added the ability for the modaldialog box to take  
another widget  as content - so would the namespace be  
"modaldialog.containerwidget.element"?

My point is that we will change our minds about how how granular or  
coarse widgets should be, and id's will be sensitive to that.

>
> And I think that'd be pretty much the same with whatever 'namespace- 
> like' ids you'd be setting with those long strings.

Yup.

>
>> If you just have a String set, you set it once and forget about it  
>> forever.
>
> So it doesn't sound like this is a simple, randomly generated String.
>
Nope, it's not random at all, it's the logical path to the element on  
the screen.
> It sounds like y'all are talking about some kind of logical  
> namespace that would also need to be kept up-to-date as the UI code  
> evolves -- otherwise you eventually end up with paths to UI  
> elements that don't really reflect what's going on in the actual UI  
> anymore.

Yes

>
>> Btw - I am 99% sure that if you give something a widget id, that  
>> also becomes the DOM id.
>

Easy to fix - just put "id=${this.widgetId}" in your widget  
templates, or path the widget code to do it automagically or have QA  
use widget IDs (prob not)

> I see conflicting stuff on the mailing lists, including this:
>
> http://dojotoolkit.org/pipermail/dojo-interest/2006-November/ 
> 021746.html
>
> The IBM tutorial they quote seems to say it's *supposed* to map the  
> main domNode id to the widgetId automagically. However, I did a  
> minimal widget test:
>
> http://www.fleegix.org/demo/minimal/widget_test.html
>
> And neither declarative widgets nor programmatic widgets get an id  
> for the domNode unless I manually stick it into the template. Could  
> be I'm screwing something up. :)

Yeah. I feel like this used to work. Mabes they took it out for some  
reason.

Bobby