Идеальный мини-фреймворк

[Psycho Tiger]

murz, да проблем нету, сел и написал. Мне просто хочется написать так, чтобы допиливание происходило через наследование, нормально и понятно, причем желательно достаточно гибко, вот и интересуюсь, не было ли у кого опыта.

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

И да, для меня Алерт это сообщение, сообщение с кнопками да нет, любой дисплей обджект.. короче, для меня это многое)

[etc]

Сообщение от Котяра

Был соблазн делать что-то вроде mxml и css для варавниваний/позиций итп, но потом понял, что легче писать as-код конкретного компонента чем городить непонятно на каком языке без автокомплитов и валидации.

А мы таки сгородили mxml/css. Жаль, правда, что оно умрет скоро.

[switcher!]

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

Жаль, правда, что оно умрет скоро.

если не секрет - почему?

[etc]

Сообщение от switcher!

если не секрет - почему?

Потому что в TZ не осталось тех, кто его знает вдоль и поперек.

[Котяра]

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

Потому что в TZ не осталось тех, кто его знает вдоль и поперек.

Вот и я о том же. Выгода от написания внешних нагромождений резко падает с исчезновением инициаторов этих нагромождений)

[switcher!]

фуф, я пишу нечто похожее в свободное время и начал было беспокоиться ))

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

Потому что в TZ не осталось тех, кто его знает вдоль и поперек.

Сообщение от Котяра

Выгода... резко падает с исчезновением инициаторов

а документацию написать... не?

[Psycho Tiger]

А я вот кстати думаю, как написать скроллпейн.
В идеале я так думаю в него можно делать addChild, задав высоту и ширину самого скроллпейна, остальное он сделает сам.
Только вот при движении детей ширина и высота "контента" может меняться... Не вешать же на ENTER_FRAME проверку. Какие есть идеи?)

[expl]

Сообщение от Psycho Tiger

Только вот при движении детей ширина и высота "контента" может меняться... Не вешать же на ENTER_FRAME проверку. Какие есть идеи?)

А при изменении ширины контента может понадобиться перерасположить детей

Перегружать set x и set y и вызывать внутри них что-то типа:

var container:IMyContainerBase = parent as MyContainerBase;
if (container != null)
{
    container.invalidateByChild();
}

а в контейнере вызывать тяжолую функцию validate(), только если его девалидировали перед отрисовкой следующего кадра единожды

protected function validate()
{
     if (_isValid)
     {
           return;
      }
     _isValid = true;
     // Погнали пересчитывать свои размеры и перерасполагать детей
}

И можно еще вызывать при спрашивании размеров, если эта функция размеры контейнера пересчитывает(не дожидаясь начала перерисовки кадра):

public function get width():void
{
    if (!_isValid)
    {
        validate();
    }  
    return _width;// это значение уже правильно пересчитано методом validate()
}

Можно событиями - но дороже по ресурсам.
И ломать голову как сделать циклы валидации - инвалидации, чтобы оно не зациклилось
Подсматривать как это сделано - во флекс и aswing - я сам до конца не вкурил.

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

[Psycho Tiger]

Да это ежу понятно.
Только если что-то большое требует скролла (ну, такие дела) - переределывать им всем геттеры-сеттеры на x, y не вариант.
x, y, scaleX, scaleY, graphics, width, height... Многовато будет. Причем для каждого объекта. А SimpleButton финальный, к тому же.

И перегрузка подразумевает изменение сигнатуры. Правильнее сказать "переопределение".

[expl]

Сообщение от Psycho Tiger

переределывать им всем геттеры-сеттеры на x, y не вариант.
x, y, scaleX, scaleY, graphics, width, height...

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

Если компонент о своем изменении не раскажет - кто же раскажет?
Только его обертка, если ее сделать. Ее можно и поверх объекта с финальным классом натянуть,
Про удобство такого подхода все понятно (и если сама кнопка вдруг вздумает изменить положение без внешнего присвоения x - ничего обертка не сможет сделать), но, тем не менее, можно сделать при необходимости.


Вообще, проблемы может и не возникнуть:
- Когда обычно задаются координаты элементов? - при добавлении в родитель (если мы лайаут не используем)
Т.е. отложенная валидация после добавления объекта - и все, не надо никаких перемещений отлавливать.

Тут проблема больше не в x и y, а высоте и ширине - они чаще меняются - т.е. изменилась высота текстового поля - родитель должен отреагировать.