Opened 5 years ago

Closed 5 years ago

#17738 closed defect (invalid)

dijit.register scope-issues

Reported by: artclifford Owned by: artclifford
Priority: undecided Milestone: tbd
Component: Dijit Version: 1.9.2
Keywords: Cc: Brian Arnold
Blocked By: Blocking:


I just spent a long day trying to figure out why I was getting dijit_WidgetsInTemplateMixin_0 already exists errors.

There were two reasons.

1) in my declare function for my custom widgets I was not providing a class naem so the default was dijit_WidgetsInTemplateMixin.

2) I was committing error 1 at two different scopes. That is I was adding a widget within a widget.

When I added a proper class name to each of my widgets I made the error go away.

However, I wasn't convinced the problem wasn't still lurking.

So, I added the same templates widget in a document and then again within another widget in the same document.

Again I got the id already exists error, but at least this time it was reporting the class name I provided.

What this tells me is that the unique id routine does work as ya'll think it does. It is behaving like it is not incrementing based on global location of a node, but rather limited to a given context.

OR, it may be that djit.register or WidgetsInTemplate? is are new instances iwhen used in a widget within a widget and therefore are not aware that there are prior instances.

So, what in effect happens is the new (inner) instance sees it is incrementing from 0 attempts to find a an element by that id (globally in the document) finds it and then complains.

However, adding the same widget multiple times at the same level will be ok.

What should happen is that it finds something with the existing id (matching declaredClass_# and bumps the increment and tries until it finds something that doesn't exist. Or find all elements with the declaredClass_ prefix that end with a number and figure out the next highest index from that.

I'm sure y'all will find a more elegant solution. But the bottom line is that the current behavior for dijit_WidgetsInTemplateMixin widgets is faulty. In particular dijit.registry.getUniqueId is not producing document-wide uniqueIds

I'd also suggest that if dijit_WidgetsInTemplateMixin detects its declaredClass is 'dijit_WidgetsInTemplateMixin' that it should throw an error and tell the developer to add a class name to the widget's declare function with a link to a documentation page about that. If you fix the scope issue it won't be a problem, but it is probably better to force people to name their widgets.

Anyway, I've seen where people have problems with this and there are some workarounds but nothing I found particularly satisfying; honestly, this is clearly a bug.

Change History (4)

comment:1 Changed 5 years ago by bill

Owner: set to artclifford
Status: newpending

It's possible there's a bug but I'd need you to provide a test case (a single HTML file that reproduces the problem) to demonstrate it, and also so that I could test if I had fixed it. So, please attach such a file using the "Attach File" button. Thanks.

I'd also suggest that if dijit_WidgetsInTemplateMixin detects its declaredClass is 'dijit_WidgetsInTemplateMixin' that it should throw an error and tell the developer to add a class name to the widget's declare function

Well, it's a bit random. What if someone makes the same mistake but their base class in _TemplatedMixin or KeyNavContainer? or ... ?

PS: are you doing something unusual like loading multiple versions of dojo onto the same page? In any case, please provide a test case.

comment:2 Changed 5 years ago by artclifford

Status: pendingnew

Ok, so I setup some test scripts to mimic my general setup with very minimal widgets and of course they work as I would hope they would. Which means I have to figure out what I was doing different with my more complicated code.

I'll keep my scripts around and if I figure out what triggers the problem I'll update this ticket.

I do think there is a use case for triggering the behavior.

As to other questions. No, I'm not using multiple dojos. And I"m not mixing dojo with jquery or any other frameworks.

And i suppose for backward compatibility not requireing a class name would be reasonable. However, if it is considered a better habit to create one, it might be better if tutorials such as this one reflected that: (which doesn't include the classname in the declare).

If I find the trigger for this issue even if it is something wonky I'm doing I'll provide details.

comment:3 Changed 5 years ago by bill

Cc: Brian Arnold added
Status: newpending

OK thanks.

About that tutorial, I agree it should be updated. CC'ing Brian Arnold who wrote it. Although the goal of AMD is to remove things like global variables, we aren't quite ready to do it in 1.x, so the tutorial shouldn't claim the opposite. I guess omitting the class name works in general, but fails for corner cases like this.

comment:4 Changed 5 years ago by trac-o-bot

Resolution: invalid
Status: pendingclosed

Because we get so many tickets, we often need to return them to the initial reporter for more information. If that person does not reply within 14 days, the ticket will automatically be closed, and that has happened in this case. If you still are interested in pursuing this issue, feel free to add a comment with the requested information and we will be happy to reopen the ticket if it is still valid. Thanks!

Note: See TracTickets for help on using tickets.