Opened 9 years ago

Closed 6 years ago

#16316 closed defect (wontfix)

dojox/mobile/Heading does not remove/avoid creating back button when back label is empty string

Reported by: Colin Snover Owned by: Patrick Ruzand
Priority: undecided Milestone: 1.11
Component: DojoX Mobile Version: 1.8.1
Keywords: Cc:
Blocked By: Blocking:


The default value of the back property is an empty string, which means that after fixing #16312 an empty back button always appears. Either the default value should be null and null should then be taken to mean "no back button" (so people can still create a back button with no label), or no back button should be created when the back property is set to an empty string. Either way, what is going on right now is wrong because the default properties do not match what happens if you actually set them to the same value after construction.

Change History (8)

comment:1 Changed 9 years ago by Adrian Vasiliu

My cents:

Indeed, null would have been a better default value in my eyes too. Now, at least for Dojo 1.x, it seems risky to change the default value.

On the other side, yes, users may want a button with empty label, so not creating the button when the string is empty doesn't sound optimal (although users would have the workaround to set a label containing a blank).

Clearly, if #16312 is fixed (meaning #7381 is implemented), something will need to be done in Heading. But for the time being, #7381 is planned for 2.0 (see also Bill's analysis of back compat issues in #7381). If #7381 will only be implemented in 2.0, changing the default from empty string to null in 2.0 might be the best.

comment:2 Changed 9 years ago by Colin Snover

If the default value is never actually applied, how would it be risky to change it?

comment:3 Changed 9 years ago by Adrian Vasiliu

I was just thinking to application code that would get the value (which can be the default value) then would do something with it and wouldn't expect the null value. In some extent, I would think the default value of a property is part of the API contract, which is painful to be changed, especially in a minor version (1.8.x). That said, if there's no better choice...

comment:4 Changed 9 years ago by cjolif

if I well understand that is not really (yet) a defect, this will be one if/when #7381 is implemented? If that is true, then sounds more like a task than a defect to me?

comment:5 Changed 9 years ago by Adrian Vasiliu

Yes, I also think there would be a critical need to modify our Heading only if/when #7381 is implemented. That said, we do have already the inconsistency mentioned by Colin: setting the default value does not have the same effect as not setting any value for "back" (in the first case a button with no label is created, in the second case no button is created). Properties such as "back" have been designed for being set only at construction time, I guess as a way to keep the code as light as possible. In some cases (say, the most frequently needed and those that require the less amount of code) this may change, see for instance #16275 which holds for Heading's "moveTo" property.

In any case, I think we can't resolve the inconsistency in Dojo 1.x by removing the back button if the setter is called with an empty string, because of users who would rely on the current behavior to get buttons with no label. Only the change of the default value from empty string to null would do the trick, but this change could wait till Dojo 2.0.

comment:6 Changed 9 years ago by Patrick Ruzand

Owner: changed from Eric Durocher to Patrick Ruzand
Status: newassigned

comment:7 Changed 8 years ago by Adrian Vasiliu

Since #7381 is marked wontfix (and for Dojo 2 we took another path, as Bill said in his comment on #7381), it seems this ticket should be closed as wontfix too.

comment:8 Changed 6 years ago by dylan

Milestone: tbd1.11
Resolution: wontfix
Status: assignedclosed

Closing as wontfix per Adrian's comment.

Note: See TracTickets for help on using tickets.