Предложение:
Добрый день, у меня есть вопрос к коллективу 
дротик мудрость-доверие. Я сделал наблюдение, пытаясь устранить загадочную ошибку с помощью Dart и Dart-Polymer (см. связанные).
То, что я обнаружил, относится к дарт-полимер (и дротик-полимер) Элемент повторное использование кода; во время моего исследования вышеупомянутой ошибки я создал два клонированных дротик-полимерные элементы:
<x-fred>и<z-fred>
Оба являются клонами элемента Секундомер в dart-полимер пример.
- Руководство по Определить настраиваемый элемент.
Единственное отличие от оригинала - это названия элементов.
Что мне приходит в голову, так это то, что я могу повторное использование кода "стандартный элемент", например секундомер Мне как минимум нужен отдельный fred .html для каждого элемента I повторное использование кода.
Это предполагает, что я могу организовать свой проект так, чтобы его было удобно и просто поддерживать.
Вопросы):
Настоящий вопрос заключается в том, как разработчик может делать следующие вещи ...?
- повторное использование кода определение макета элемента без необходимости создавать клон (или копию).
- Есть ли шаблон дротик-полимер? чтобы (по крайней мере) разрешить проекту повторно используйте код базового < img src = "https://i.stack.imgur.com/r0io0.png" height = "16" width = "18" alt = "" class = "спонсор-тег-img"> код dart для клонированного dart- полимерные элементы?
- Is there a way to code-reuse an Element definition, using a declarative or "what-not-how" pattern so that I can say:
<z-fred>is-a stopwatch-element (for example).
- Существуют ли шаблоны или рецепты, позволяющие быть элементом секундомера и настраивать и / или настраивать экземпляр в соответствии с определенными стилями, параметрами или поведение.
Если нет, то эти вещи нужно вынести на обсуждение. Где это происходит для 
дротик и [дротик: полимер]? Есть comp.lang.dart? :-)
Пример:
Предположим, у меня есть элемент Polymer с именем <z-fred>. И я хочу создать подкласс элемента z-fred для создания нового определения (дочернего) элемента: <x-fred>
Как я могу это сделать?
Я ожидал, что смогу сделать что-то вроде ...
<!DOCTYPE html>
<polymer-element name="x-fred">
<link rel="import" href="elements/zfred/fred.html">
<template>
<style>
:host { /* override zfred defiitions */
background-color: blue;
text-align: center;
display: inline-block;
border: solid 1px;
padding: 10px 10px 10px 10px;
}
</style>
<div>
<x-fred>
<h1>X-Fred: {{counter}} </h1>
<p>Fred X is a count-down timer. Fred Z is a normal stopwatch (count-up).</p>
<override>
<button on-click="{{stop}}" id="stopXFredButton">Stop</button>
</override>
</x-fred>
<div>
<p>this is a count-down timer. Remaining time at end: {{ counter }} </p>
</div>
</div>
</template>
<script type="application/dart" src="xfred.dart"> </script>
</polymer-element>
Видеть? Мой пример не сработает, потому что здесь требуется, чтобы XFred.polymer унаследовал от ZFred.polymer.
Тем не менее, я не видел ничего, чтобы связать .html плюс .dart с каким-то «элементом module». По-своему, я хотел сделать это, поместив каждый виджет в отдельную папку. Чтобы это работало (и будет лучшая механика), дочерняя должна иметь возможность переопределять родительские атрибуты Public и Protected (не частные).
Я думал, что xfred.dart неявно унаследует zfred.dart (поскольку лексически) оба файла Dart не связаны с элементом Polymer. На этом этапе необходимо изучить вопросы дизайна продукта. Варианты вроде:
- HTML files have independent inheritance tree to the .Dart files.
- That means that zfred and xfred might use (share) the same underlying implementation, per various examples.
- В качестве альтернативы можно «вызвать» подходящую реализацию .Dart определенного интерфейса.
- Смешанный элемент widget, состоящий из спецификаций кода .html и .dart.
В реальном пользовательском интерфейсе я могу захотеть объединить различные базовые элементы пользовательского интерфейса в различные виды подэлементов для создания страницы, формы или макета. Я думаю, что после концепции №1 жизнь остается менее беспорядочной. Это удовлетворяет другое требование для меня, связанное с возможностью управлять альтернативным поведением кода программной части для одного и того же элемента.
В конце дня. Главный вопрос, который я задаю, - насколько это часть фреймворка и сколько требуется ручной работы, чтобы все оставалось счастливым? :-)
