Scaffold for MD-Settings, inside chrome://md-settings.

chrome/browser/resources/settings/settings_page/settings_page.js

+// Copyright 2015 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.
+
+/**
+ * @fileoverview
+ * 'cr-settings-page' is the base class for settings pages.
+ *
+ * Example:
+ *
+ *    <polymer-element name="cr-settings-a11y-page" extends="cr-settings-page">
+ *      ...
+ *    </polymer-element>
+ *
+ * @group Chrome Settings Elements
+ * @element cr-settings-page
+ */
+Polymer('cr-settings-page', {
+  publish: {
+    /**
+     * Preferences state.
+     *
+     * @attribute prefs
+     * @type CrSettingsPrefsElement
+     * @default null
+     */
+    prefs: null,

[Jeremy Klein, 2015/03/07 23:55:14]

I don't think that all pages will need a prefs in the long run. This is one of
the downfalls of inheritance IMO. I think I'd prefer adding a
cr-settings-page-metadata element for the titles, icon, and help. Each of the
pages could have a metadata element, thus exposing a shared interface to the
page container. I think this would make things less tightly coupled while also
being more flexible in the transition to 0.8. WDYT?

[michaelpg, 2015/03/08 04:22:47]

Good stuff! This isn't out for review yet, but I wanted to respond.

On 2015/03/07 23:55:14, Jeremy Klein wrote:
Agreed. The models will need to be included on a page-by-page basis. We could
have the individual pages include them, like how components can include
<app-globals> in Polymer examples.
Putting shared properties in a metadata object provides an interface for the
container like you say, so we can use type annotations for closure, but then it
feels like we're letting closure dictate our design. Like, "pageTitle" is a core
property of what a page is, so giving a page a title via composition doesn't
seem natural. Can we look for a better compromise?

"shared interface" sounds good -- is there a way we could just do that, without
doing class-like inheritance or metadata elements? Would "@implements" help
here?
I've been assuming 0.8 doesn't intend to *ship* without inheritance just because
the preview doesn't have it yet. Because it's a core part of the web component
spec and it's used throughout core-elements and paper-elements. IOW, we should
take advantage of inheritance where it makes sense -- not saying it does, here,
or necessarily will anywhere, but IMHO parity with a work-in-progress isn't
worth handicapping ourselves.

I'll write up these concerns in a design doc so we can talk about this in a more
permanent place.

+
+    /**
+     * Title for the page header.
+     *
+     * @attribute pageTitle
+     * @type string
+     * @default ''
+     */
+    pageTitle: '',
+
+    /**
+     * Title for the navigation drawer.
+     *
+     * @attribute navTitle
+     * @type string
+     * @default ''
+     */
+    navTitle: '',
+
+    /**
+     * Name of the 'core-icon' to show.
+     *
+     * @attribute icon
+     * @type string
+     * @default ''
+     */
+    icon: '',
+
+    /**
+     * Text for help articles.
+     * TODO(michaelpg): Expand and set on actual pages once Help features are
+     * clarified.
+     */
+    helpArticles: [{
+      title: 'Help Article',
+      content: 'Odi et amo. Quare id faciam, fortasse requiris? Nescio, sed ' +
+               'fieri sentio et excrucior.',
+    }, {
+      title: 'More Help',
+      content: 'Arma virumque cano, Troiae qui primus ab oris Italiam, fato ' +
+               'profugus, Laviniaque venit litora, multum ille et terris ' +
+               'iactatus et alto vi superum saevae memorem Iunonis ob iram; ' +
+               'multa quoque et bello passus, dum conderet urbem, ' +
+               'inferretque deos Latio, genus unde Latinum, Albanique ' +
+               'patres, atque altae moenia Romae.',
+    }],
+  },
+});