[rAc OSX] Factor out AutofillHeader class to contain dialog header elements.

chrome/browser/ui/cocoa/autofill/autofill_header.h

Index: chrome/browser/ui/cocoa/autofill/autofill_header.h
diff --git a/chrome/browser/ui/cocoa/autofill/autofill_header.h b/chrome/browser/ui/cocoa/autofill/autofill_header.h
new file mode 100644
index 0000000000000000000000000000000000000000..c6b8c6db586d0d8f6cf1ec79ccd39874ddb4e8da
--- /dev/null
+++ b/chrome/browser/ui/cocoa/autofill/autofill_header.h
@@ -0,0 +1,43 @@
+// Copyright 2013 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 CHROME_BROWSER_UI_COCOA_AUTOFILL_AUTOFILL_HEADER_H_
+#define CHROME_BROWSER_UI_COCOA_AUTOFILL_AUTOFILL_HEADER_H_
+
+#import <Cocoa/Cocoa.h>
+
+#include "base/mac/scoped_nsobject.h"
+#import "chrome/browser/ui/cocoa/autofill/autofill_layout.h"
+
+namespace autofill {
+class AutofillDialogViewDelegate;
+}  // autofill
+
+@class AutofillAccountChooser;
+
+@interface AutofillHeader : NSView<AutofillLayout> {

[groby-ooo-7-16, 2013/11/20 23:51:44]

Please make this an NSViewController - unless things do custom drawing, they
should rarely be NSViews.

[Ilya Sherman, 2013/11/22 05:01:13]

I made this an NSView because I wanted a flipped view.  So, two questions:

(1) How do you recommend having a flipped view if I switch this over to be an
NSViewController?
(2) What's the advantage of inheriting from NSViewController?  From what I've
seen, that just adds an extra object into the mix, as our NSViewControllers all
have one primary view that we attach a bunch of subviews to, and clients of the
controller frequently access that primary view directly as [controller view]. 
So, it doesn't seem like we instantiate fewer views, nor do we provide a smaller
API surface.  What's the benefit?

[groby-ooo-7-16, 2013/11/22 14:51:37]

Don't make it flipped unless you have to :) (The easiest way to do it is a
top-level FlippedView, and then children beneath that)

As to the larger NSViewController question, it's a stylistic choice, separating
logic and presentation. In general, we try to only use views for things that
need drawing things. I don't feel that strongly about it (since NSViewController
is, uh, anemic at best :), but in previous reviews of my code, I've received
strong pushback on not using a controller.

Maybe it's worth raising this with the other Cocoa peeps on Chrome?

[Ilya Sherman, 2013/11/23 00:23:54]

Well, fair enough :)
Made it an NSViewController, because I do like encapsulating the contents of
-update: within this class, and I guess I'm fine with the tiny bit of overhead
from separating out the view and the controller as per MVC.

+ @private
+  base::scoped_nsobject<AutofillAccountChooser> accountChooser_;
+  base::scoped_nsobject<NSTextField> title_;
+  // TODO(isherman): Include notifications in the header.
+
+  autofill::AutofillDialogViewDelegate* delegate_;  // not owned, owns dialog.
+}
+
+// Designated initializer.
+- (id)initWithDelegate:(autofill::AutofillDialogViewDelegate*)delegate;
+
+// Returns the anchor view for notifications, which is the middle of the account
+// chooser view.
+- (NSView*)anchorView;
+
+// Updates the header's state from the dialog controller.
+- (void)update;
+
+// Get the preferred view height for a given width.
+- (CGFloat)heightForWidth:(int)width;
+
+@end
+
+#endif  // CHROME_BROWSER_UI_COCOA_AUTOFILL_AUTOFILL_DIALOG_HEADER_H_