Вверх ↑
Ответов: 9906
Рейтинг: 351
#1: 2008-08-29 14:59:40 ЛС | профиль | цитата
nesco писал(а):
Не понял, что, никто не тестирует, что ли

Ну смотри, сам напросился: получай фашист гранату

Вообще-то, тестировать такое, даже настроения никакого нет
Чего тестировать-то
Умение писать килограммы тупого кода
Чтобы потом превратить его в тонны
Который появится у всех, даже ничего не знающих про "сохранение/восстановление"
Благодарю покорно

Мне кажется, что в вашей версии среды (там где CodeGen имеет наконец-то api для определения "внешности" св-ва, хотя первое упоминание о необходимости такового было сразу после появления этой птыцы) возможен значительно более адекватный вариант
ДАЖЕ при полном равнодушии автора этой среды к данной проблеме
Ну русские люди мы, или нет, наконец-то
В отличие от всего мира, наше главное достоинство, это владение высоким искусством "что такое ничего, и как из него сделать что-то"
Именно на этом стояла всегда Россия

Как это могло бы выглядеть...

  • В данной конкретной схеме всякое св-во, желаемое нами к восстановлению из INI или реестра объявляется внешним (ставим птыцу, и всего делов), и, что характерно - делаем ему имя которое и используем в последствии в нашей технологии
  • Создаем (пишем для него коды) один элемент-контейнер. И пусть у него будет рабочее название Option. Внимание, очень важно !!! -- это действительно контейнер, внутри которого содержится схема пользователя Но этот контейнер НЕ ИМЕЕТ точек связи со схемой. Категорически лысый снаружи, грубо говоря

  • Для этого элемента коды в CodeGen генерируются особым образом. А именно: он не только создается РАНЬШЕ всех элементов схемы, но и его внутренняя схема (это же контейнер) начинает работать раньше создания остальных элементов внешней схемы. Скажем, у элемента-парента этого контейнера есть точка onCreate, к которой подключена схема пользователя.
    Которая то ли открывает INI-файл, то ли находит ключ в реестре, то ли читает параметр типа Lang (опять же, то ли из своих настроек, то ли из настроек системы), и по результатам определяет имя какой-то секции для дальнейшего чтения параметров...
    Прошу пардону, но это идеология у меня такая: думать о таких вещах ДО создания алгоритма, а не после создания очередного "пока это допустимо"

  • Этот же элемент-парент имеет еще три точки: onRead, onWrite, onDestroy onRead срабатывает в момент конструирования элемента (внешняя схема еще не сделана и не работоспособна, это все еще в процессе) и содержит в потоке имя одного из тех внешних св-в, которое мы ранее героически оптичили
    А пользователь сам и придумает, чего делать дальше (в смысле - откуда взять данные для этого св-ва, чтобы подать его на левую точку парента SetData, по аналогии с элементом EventFromData)

  • onWrite будет срабатывать при выполнении деструктора элемента. Правда в кодах сегодняшних элементов мы не имеем гарантий, что св-ва элемента, доступные к записи, также будут и успешно читаться. Но тут уж ничего не сделаешь - не все можно сделать уж из совсем ничего.
    НО, можно завсегда дописать в коды элементов необходимые property. Причем, тем, кто понятия не хочет иметь про Option - это не добавит ни одного лишнего байта кода.
    Не GCC чай...

  • При кодогенерации, в тот героический момент, когда CodeGen норовит записать присвоение значения св-ва для элемента, необходимо проверить, не является ли сие св-во "внешним" (для чего и необходимо вышеупомянутое api со средой), и, коль скоро это так -- запустить необходимый метод (чтобы там сработал onRead) уже работоспособного (это очень важно) элемента Option. Естественно, перед генерацией конструктора схемы, следует установить тот факт, что в схеме присутствует сей замечательный элемент...

  • Аналогично и в деструкторе схемы: коль скоро существует элемент Option, перед Destroy каждого элемента проверить наличие у него внешних св-в, и запустить нужный метод Option (чтобы там сработал onWrite) для таковых onDestroy -- да просто контрольный выстрел....


    В общем, не так уж все и не преодолимо...
    Остается вопрос про вложенные контейнеры, но и это решаемо, может быть даже и без глючности сегодняшнего MakeElement (в смысле - идеи-то есть)...
    Об этом можно и после подумать, если первая часть будет работать - она самодостаточностью и сама по себе обладать должна....

    Идею я изложил, пробуйте, у кого есть возможность

  • карма: 9

    0