Closed Bug 636123 Opened 14 years ago Closed 13 years ago

nsDocument::GetRadioGroup should be split in two methods: one to get the radio group and one to create it

Categories

(Core :: DOM: Core & HTML, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla17

People

(Reporter: mounir, Assigned: Ms2ger)

Details

Attachments

(2 files, 1 obsolete file)

This method is currently creating a radio group if none is found and we might not want to do that in some cases (when we want to read a value, we don't want to bother creating an entry if none is found). That would also allow us make GetRadioGroup const.
Attached patch Patch v1 (obsolete) — Splinter Review
Was this what you were thinking?
Assignee: nobody → Ms2ger
Status: NEW → ASSIGNED
Attachment #561755 - Flags: review?(mounir)
Comment on attachment 561755 [details] [diff] [review] Patch v1 Review of attachment 561755 [details] [diff] [review]: ----------------------------------------------------------------- So what I wanted was: nsRadioGroupStruct* GetRadioGroup(const nsAString&) const; nsRadioGroupStruct* CreateRadioGroup(const nsAString&); And fix the callers to have them call CreateRadioGrup() when they actually need to do so. I do not like the GetRadioGroup()/GetExistingRadioGroup() naming. The former is still confusing and it's not obvious that it will create a group if none is found. In addition, I would prefer GetRadioGroupInternal() instead of GetRadioGroupLC(). I'm not even sure what LC means here. BTW, if you do that, some null-checks after GetRadioGroup() will still be needed (re: the bug where I told you you could remove them) Does that make sense to you?
Attachment #561755 - Flags: review?(mounir) → review-
Attached patch Patch v2Splinter Review
Something like this?
Attachment #561755 - Attachment is obsolete: true
Attachment #615071 - Flags: review?(mounir)
Comment on attachment 615071 [details] [diff] [review] Patch v2 Review of attachment 615071 [details] [diff] [review]: ----------------------------------------------------------------- I would have preferred something like: nsRadioGroupStruct* radioGroup = GetRadioGroup(str); if (!radioGroup) { radioGroup = CreateRadioGroup(str); NS_ENSURE_TRUE(radioGroup, OOM_ERROR); } But I understand it could be painful and error-prone to do that and I will try to not be stubborn ;) ::: content/base/src/nsDocument.cpp @@ +6498,5 @@ > + if (IsHTML()) { > + ToLowerCase(tmKey); //should case-insensitive. > + } > + > + if (nsRadioGroupStruct* radioGroup = GetRadioGroupInternal(tmKey)) { Hmm, I think I would prefer: nsRadioGroupStruct* radioGroup = GetRadioGroupInternal(tmKey); if (radioGroup) { return radioGroup; } @@ +6517,1 @@ > NS_ENSURE_TRUE(radioGroup, NS_OK); Shouldn't that return OOM instead? Given that if radioGroup is null that means we failed to create a new entry. @@ +6528,1 @@ > NS_ENSURE_TRUE(radioGroup, NS_OK); ditto @@ +6573,1 @@ > NS_ENSURE_TRUE(radioGroup, NS_ERROR_FAILURE); ditto @@ +6619,1 @@ > NS_ENSURE_TRUE(radioGroup, NS_OK); ditto @@ +6636,1 @@ > NS_ENSURE_TRUE(radioGroup, NS_OK); ditto @@ +6656,1 @@ > NS_ENSURE_TRUE(radioGroup, NS_OK); ditto
Attachment #615071 - Flags: review?(mounir) → review+
Thanks for this patch btw ;)
(In reply to Mounir Lamouri (:volkmar) (:mounir) from comment #4) > Comment on attachment 615071 [details] [diff] [review] > Patch v2 > > Review of attachment 615071 [details] [diff] [review]: > ----------------------------------------------------------------- > > I would have preferred something like: > nsRadioGroupStruct* radioGroup = GetRadioGroup(str); > if (!radioGroup) { > radioGroup = CreateRadioGroup(str); > NS_ENSURE_TRUE(radioGroup, OOM_ERROR); > } > > But I understand it could be painful and error-prone to do that and I will > try to not be stubborn ;) I thought you would, but I given the number of times I'd have to repeat this pattern, I'd rather not. > @@ +6517,1 @@ > > NS_ENSURE_TRUE(radioGroup, NS_OK); > > Shouldn't that return OOM instead? Given that if radioGroup is null that > means we failed to create a new entry. Fair point, but I didn't want to change behaviour in this patch.
I noticed hashtables are infallible now.
Attachment #643322 - Flags: review?(mounir)
Attachment #643322 - Flags: review?(mounir) → review+
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Backed out with the mass tree revert to get rid of the OS X M5 orange: https://hg.mozilla.org/mozilla-central/rev/c801b99d726f
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → RESOLVED
Closed: 13 years ago13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: