Заголовок у компонента(контрола)

[Psijic]

Здравствуйте, господа. Задался таким вопросом как необходимость создания заголовков (Label) для каждого компонента (по типу как в Delphi такое есть у каждого визуального компонента по умолчанию).
Раньше мы использовали кипячение:

public static function createIO(parent: FeathersControl, classType: Object, x: int, y: int, width: uint = 0, height: uint = 0, label: String = null): FeathersControl
        {
            var io: FeathersControl = new classType();
            io.x = x;
            io.y = (label && !(io is Button)) ? y + 20 : y;
 
            addLabel(io, parent, label, x, y);
 
            parent.addChild(io);
 
            return io;

Однако, такой способ весьма плох, т.к. создаваемый label вообще никак не определяется и получается как мусор, с которым ничего нельзя сделать (особенно если актуально передвинуть/удалить контрол).

Есть вариант 2: Заворачивать компонент в слой (layer) и давать ссылку на слой. Но тогда взаимодействовать с контролом становится геморно - нужно вставлять дополнительный уровень - что-то типа

layer.textInput.text = "foo"

Вариант 2.1 - заворачивать в слой, но отдавать контрол (или и слой и контрол в массиве, хотя это и бредово)

Вариант 3 - расширить класс Sprite/DisplayObject/etc и добавить к нему код для создания label. Однако, пока не вполне ясно, как это должно работать в плане addChild и подборки координат.

[caseyryan]

Есть вариант 2: Заворачивать компонент в слой (layer) и давать ссылку на слой. Но тогда взаимодействовать с контролом становится геморно - нужно вставлять дополнительный уровень - что-то типа

Что-то не пойму в чем сложность. Что мешает после этого сделать так?

public function set label(value:String):void {
   _layer.textInput.text = value;
}
public function get label():String {
   return  _layer.textInput.text;
}

[Psijic]

@caseyryan
Напрягает создание лишних оберток, контрол становится не контролом, а слоем. Хотелось бы более нативное внедрение общих свойств таких как label, hint etc.

P.S. Не понял, в предложенном коде предлагается проксирование всех свойств, которые возможно понадобятся? (Тогда еще надо бы и .text задавать как text, a не label) Допустим, с TextInput такое пройдет. Но если я, например, поставлю заголовок к DataGrid или List?

[GBee]

Контрол это всегда пирог. Если конечно, вы не рисуете в графиксе все состояния. Чекбокс - кнопка с тоглом и другой картинкой. Радиобаттон - чекбокс урезанный и другой картинкой. Так что лейбл погоды не сделает, если конечно вы не рисуете в графиксе. Я бы создал базовый компонент с лейблом, который просто текст запоминает. А в кнопке (от базового компонента) под лейбл уже создавалось бы поле, в датагриде ничего бы не происходило и так далее.

[caseyryan]

Ну так композиция - вполне себе нормальный паттерн.
Создайте отдельный класс Label, который будет только за текстувую часть отвечать, и его добавляйте куда надо

[Gerbert]

Ну так композиция - вполне себе нормальный паттерн.

Это основополагающей паттерн, который в ООП ставят ДАЖЕ выше наследования.

[Psijic]

Наверно надо было пояснить что я имел в виду под заголовком. В данном случае это Label1 для TextEditor1, Label2 для TextEditor2



Да, наверно придется вставлять в слой. Проблема еще виделась в том, что если через статичную фабрику делать компоненты, то те что с заголовком будут как "Слой с заголовком", а те что без заголовка - обычный контрол и тут может быть путаница в дальнейшем с унификацией использования. Придется делать проксирование свойств для каждого объекта, а это куча boilerplate code

public function get text
{
    return textInput.text
}

[caseyryan]

обычный контрол и тут может быть путаница в дальнейшем с унификацией использования.

На этот случай можно сделать все по-умолчанию с заголовком, но чтобы он не отображался до тех пор, пока не введен текст. Ну или сделать флаг lableEnabled, который и будет включать / выключать заголовок

[dimarik]

Программирование — боль. Можно глянуть хотя бы на механизм скинирования во Flex 4. Там боль завернута на метаданные, компилятор и сам класс. Проксирование величин для недоступных пока компонентов — это обычное дело.
В общем там суть вся в скинах. Есть компонент TextEditor, а есть его скин. Кстати, TextEditor по сути может принимать ввод с клавиатуры и отображать набранный текст, вроде того. Сам компонент является логикой, а скин — его отображением. Что такое логика для этого компонента? Нужно установить каким стилем отображать текст и этот текст должен быть набран на клавиатуре. А еще у компонента может быть опциональный Label, отображаемый где захочешь. Вроде все просто. Вот объявлен у тебя label для компонента TextEditor как опциональный, т.е. лабеля может не быть в скине. Если есть, то поле TextEditor#labelText заполняет свойство text именно Label#text из скина. А поле labelAlign позиционирует лабель где захочешь. Кстати... Вот ты компиляешь для десктопа, и TextEditor пользует скин с обычным flash.text.TextField. А начал ты компилять для мобилки, то тут уже включается скин с использованием StageText. Подумай над этим.

[Psijic]

Скины, скины... Интересная тема, можно задуматься. Тут еще 1 вариант выплыл - в Feathers можно переопределить ItemRenderer, думаю, будет что-то типа скинов. Или в инициализации темы прописать

Добавлено через 9 минут

Сообщение от caseyryan

На этот случай можно сделать все по-умолчанию с заголовком, но чтобы он не отображался до тех пор, пока не введен текст. Ну или сделать флаг lableEnabled, который и будет включать / выключать заголовок

По сути это расширить какой-то общий предок для компонентов типа Sprite (либо рендерер). Если расширять Sprite то как в данном случае добавить label сверху, а "компонент" вниз (по сути, это получается, надо передвинуть сам себя, а label в данном случае это уже часть "себя")?