[Payment Request] Generic edit form

ios/chrome/browser/payments/payment_request_edit_view_controller.h

Index: ios/chrome/browser/payments/payment_request_edit_view_controller.h
diff --git a/ios/chrome/browser/payments/payment_request_edit_view_controller.h b/ios/chrome/browser/payments/payment_request_edit_view_controller.h
new file mode 100644
index 0000000000000000000000000000000000000000..701838d95deec7f9c66a63b0fc5015a8865eca9d
--- /dev/null
+++ b/ios/chrome/browser/payments/payment_request_edit_view_controller.h
@@ -0,0 +1,62 @@
+// Copyright 2017 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#ifndef IOS_CHROME_BROWSER_PAYMENTS_PAYMENT_REQUEST_EDIT_VIEW_CONTROLLER_H_
+#define IOS_CHROME_BROWSER_PAYMENTS_PAYMENT_REQUEST_EDIT_VIEW_CONTROLLER_H_
+
+#import <UIKit/UIKit.h>
+#include <vector>
+
+#include "components/autofill/core/browser/field_types.h"
+#import "ios/chrome/browser/ui/collection_view/collection_view_controller.h"
+
+// Item type for the error message item. This value is chosen to avoid
+// overlapping with the values starting from kItemTypeEnumZero. This is a
+// repeated item type.
+const NSInteger ItemTypeErrorMessage = kItemTypeEnumZero + 100;

[lpromero, 2017/03/16 13:01:06]

Did you mean to add this to the implementation file?

[Moe, 2017/03/16 15:44:22]

Done.

+
+// Field definition for an editor field. Used for building the UI and

[lpromero, 2017/03/16 13:01:06]

s/an/a

[Moe, 2017/03/16 15:44:22]

It should be "an editor...", right?

[lpromero, 2017/03/16 16:08:08]

0_0 Why did I made this comment?

+// validation.
+struct EditorField {
+  EditorField(autofill::ServerFieldType data_type,
+              const base::string16& label,
+              bool required,
+              int item_type,
+              int section_id)
+      : data_type(data_type),
+        label(label),
+        required(required),
+        item_type(item_type),
+        section_id(section_id) {}
+
+  // Data type for the field.
+  const autofill::ServerFieldType data_type;
+  // Label for the field.
+  const base::string16 label;
+  // Whether the field is required.
+  bool required;
+  // Item type for the field.
+  int item_type;
+  // Section identifier for the field.
+  int section_id;
+};
+
+// The collection view controller for a generic Payment Request edit screen. It
+// Features sections for every EditorField returned by -editorFields. Each

[lpromero, 2017/03/16 13:01:06]

Nit: s/Features/features

[Moe, 2017/03/16 15:44:22]

Done.

+// section has a text field as well as an optional error message item.
+@interface PaymentRequestEditViewController
+    : CollectionViewController<UITextFieldDelegate>
+
+// Subclasses override this method to returns a list of field definitions for

[lpromero, 2017/03/16 13:01:06]

s/returns/return

[lpromero, 2017/03/16 13:01:06]

Is there an alternative to subclassing this controller? Can't it accept an
editorFields vector as property? Will subclasses also implement custom behavior?

[Moe, 2017/03/16 15:44:22]

Done.

[Moe, 2017/03/16 15:44:22]

I can definitely pass those as a property, but unfortunately it's not just the
field definitions that vary. The credit card editor and the address/contact info
editors feature some extra UI elements and functionality and slightly different
validation/submission behaviors. It's hard to know how much they can be
refactored before having both editors. But I'm more than happy to continue
refactoring the common UI and functionality into the generic editor and keep the
subclasses as shallow as possible.
go/pr-bling-mocks

+// the editor.
+- (std::vector<EditorField>)editorFields;
+
+- (instancetype)init NS_DESIGNATED_INITIALIZER;
+
+- (instancetype)initWithStyle:(CollectionViewControllerStyle)style
+    NS_UNAVAILABLE;
+
+@end
+
+#endif  // IOS_CHROME_BROWSER_PAYMENTS_PAYMENT_REQUEST_EDIT_VIEW_CONTROLLER_H_