[rac] Use i18n address inputs with --enable-autofill-address-i18n flag

chrome/browser/ui/autofill/autofill_dialog_controller_impl.h

Index: chrome/browser/ui/autofill/autofill_dialog_controller_impl.h
diff --git a/chrome/browser/ui/autofill/autofill_dialog_controller_impl.h b/chrome/browser/ui/autofill/autofill_dialog_controller_impl.h
index 818149d69f2de4e07384f5f9a749addaaacd5f00..45342316ebb5222538aab462af2f155a3feac2f1 100644
--- a/chrome/browser/ui/autofill/autofill_dialog_controller_impl.h
+++ b/chrome/browser/ui/autofill/autofill_dialog_controller_impl.h
@@ -59,6 +59,10 @@ class AutofillPopupControllerImpl;
 class DataModelWrapper;
 class TestableAutofillDialogView;
 
+namespace common {
+class AutofillDialogInput;
+}
+
 namespace risk {
 class Fingerprint;
 }
@@ -743,6 +747,9 @@ class AutofillDialogControllerImpl : public AutofillDialogViewDelegate,
   // A username string we display in the card scrambling/generated overlay.
   base::string16 submitted_cardholder_name_;
 
+  // An object for building inputs for autofill sections.
+  scoped_ptr<common::AutofillDialogInput> inputs_builder_;

[Evan Stade, 2013/10/02 00:57:19]

I don't see any reason for this to be a member variable. Instead of creating an
interface, can you expose the BuildInputs methods as static utilities, with the
check inside each one proxying to other static functions?

[please use gerrit instead, 2013/10/02 18:21:50]

I've decided to make AutofillDialogControllerImpl own the AutofillDialogInput
object because AutofillDialogInputI18n will own the libaddressinput context. It
makes sense to keep one libaddressinput context per address input form.
AutofillDialogControllerImpl has two address input forms, actually, so I think
that it needs two instances of AutofillDialogInput. I prefer to not have a
single static libaddressinput context be used by multiple address forms.

[Evan Stade, 2013/10/02 20:27:19]

what state is the object going to hold?

+
   DISALLOW_COPY_AND_ASSIGN(AutofillDialogControllerImpl);
 };