Здравствуйте, sharez, Вы писали:
S>В таком случае все setTitle(), setColor() внутри помимо изменения DOM-дерева должны будут ещё и проверять, создано ли оно — тоже неплохое такое усложнение, особенно, если таких методов много (а их много).
Сложность не такая уж и большая, и это скорее вопрос требований. Если хотим иметь такого рода свойства — в любом случае проверять. Можно конечно и не проверять и всегда менять/читать из DOM, но, имхо, возможность аттача выгоднее. (*)
S>Основная задумка была в том, что удобно создать this.el со всей внутренней структурой без аттача к DOM-дереву непосредственно документа, и добавлять его только при явном вызове, как-то так:
Не-не-не, связывание объекта и DOM элемента это уже и есть тот самый аттач. Только, с разницей что элемент строится безусловно самим контролом.
S>При этом нам ничего не помешает уже на этапе вызова конструктора задавать Title, Color в дереве, хранящемся во внутреннем поле this.el. Можно даже делать addEventListener/removeEventListener.
Помешает: как их задавать если условный createElement ещё не вызван? Возвращаемся к началу (*), и нам всё равно надо контроллировать создан он или нет в аксессорах. Если же речь о задании только значений по умолчанию в наследниках — то объект-шаблон/параметров поможет.
Опять же, установка новых значений по умолчанию в наследниках — имхо плохой вариант сам по себе: это местами может быть неожиданно (равно как и наоборот).
На самом деле куда интереснее, что делать если наследник хочет предоставить своё DOM tree, а базовый setTitle не виртуальный и пишет текст не туда.
А в финале — цепочка Control — Button сложна сама по себе. Я имею ввиду, что Control будет жутко перегружен в любом случае, а допиливаться будут все связанные классы сразу (и те которые не button тоже). Я делал себе Button и LinkButton, но LinkButton устанавливал только дефолтное базовое имя стиля (а точнее префикс). А вот в процессе пиляния такого фреймворка с 10-15 контролами — перетрушивал байду эту не раз, и в итоге пришел к тому, что напрямую я их в омновном все равно не создавал, а создавал на основе шаблона (dom tree), где спец элементы (скажем xcontrol) раскрывались в уже настоящий dom. А код уже обращался к ним по именам. Я к тому — что ну вот не вижу необходимости обсуждаемой возможности хоть убей. Или мы заранее знаем набор/значений свойств и свободно можем их передать в конструктор, или мы используем аксессоры после. Внутри конструктора аксессоры вполне могут быть использованы — ведь пока элемент не приатачен — ломаться нечему (разумеется, если свойства не виртуальные). Кроме того, не стоит и забывать, что DOM — это всегда интероп, поэтому подход: изменения только через контрол а не в DOM напрямую работает немножко лучше. (Ведь поверх этого надо ещё биндинг построить, так ведь?).
В общем, закончу пожалуй тем, что я на уровне веры считаю, что базовый класс не должен вызывать наследника. Но, признаюсь, что изредка в упоротых мною же случаях в шарпе грешу.
А создать удобный фреймворк — сложная задача. Удачи в этом.
Кстати половина новомодных с легкостью делают долбанный туду лист и тут же фейляться где-нибудь в самом неудобном месте.
S>К сожалению, с Google Closure Tools я не знаком, но посмотрю на досуге.
Без фанатизма только, там много кода + длинная история.
Примеры могут грузятся долго т.к. нескомпилированный js состоит из большого кол-ва модулей/файлов. Но они (модули) там хотя бы есть... а не профанация как в TS.
Я не со всем там согласен, но вдохновение в свое время почерпнул и не мало. Особенно система модулей и disposable (в дебаге) понравился. Кое что из идей перенес и себе.
Мне кажется это самый взрослый набор тулзов, но нетипизированность JS отталкивает, а его для их компилятора ещё и правильно писать надо. И реально нормальных редакторов нету, подпорки везде одни.
