Причем пульсары очень разные, можно сказать что в их сигнале зашит GUID.
Забавно у вас, телепортировать материальные объекты в другую галактику просто, а вот телепортировать информацию — практически невозможно. Вообще материя, энергия и ифнормация — это одно и то же. Скорость распространения ограничена скростью света. Телепортация в данном понимании — махенизм обхода ограничений скорости света для передачи материи/энергии/информации.
Только Raphael — это SVG (векторная графика). Для стрелок и блоков гораздо удобнее чем Canvas (растровая), но надо держать в уме принципиальную разницу ИМХО.
Насчет указанного примера — подтверждаю, можно сделать вот так. Блоки на линию были наложены так (это вообще песочница рафаели, очень полезная штука, а вот юзер группа, где я два года назад пытался понять как это делать).
Строго говоря — это Ext.Net, библиотека компонентов ASP.NET на ExtJS (версии 3.4, четверка у них в разработке сейчас). А так то да, управляемая среда, корпоративное приложение, широкий канал, браузер IE 7+, FF 3.5+, Chrome 9+, версию опервы не помню :) Вы на 100% правы.
Я за демократию, чем больше систем на рынке — тем лучше ;) Думаю 1С пришли к этому своими путями, и это ещё один сигнал что это правильно. Мы все же разработчики, и кое-кто из нас, возможно, разрабатывает тот самый 1С, и это дико интересно! Статья скорее вводная, в принципе по ПУЗ-у можно выполнить любой код в контексте элемента сущности, формы и самого поля. Но это уже совсем другая история…
> Невидимые по дефолту поля у вас можно сделать появляющиеся в одной строке с выбранным чекбоксом?
Да, можно. В примерчике поле «Метро» может быть изначально невидимым, как после выбора города «Певек». Там контейнер колонок, в нем две колонки, в каждой из них поле. Одно поле прячется — второе раздвигается на всю ширину. Вообще это можно по разному делать, если ситуация типовая — я бы ввел структуры, и обрабатывал тип поля структуры как одно сложное поле, внутрях которой своя сложная логика (мы к этому подходим).
>Грешников делом, мы даже сначала думали захардкодить 42 формы и не париться, но на первой же форме поняли что это плохая идея
Вам чертовски повезло ;) Очень жирная грабля однако!
Раньше была реализация динамики чисто на JS. Это был метод на 600 строк (естественно он только логику отрабатывал, пуская и дергая нужные методы и события). В итоге я почувствовал что зарываюсь и мы сделали все на сервере. Работает достаточно стабильно, и как показала практика — проще менять и дополнять логику в сложных местах. Увы, сразу продумать зачастую просто невозможно, нет всего спектра требований. С каждой итерацией они добавляются и добавляются. Хотя я изначально форсил тему клиентского управления, ни что так не завораживает, как всплывающий эвент +)
Интересно у вас :) К нам приходит JS код, который уже конструирует ExtJS объекты, на которые накладывается состояние формы, и по мере ввода изменяется. Так достаточно гибко получается. Скоро будет приходить вообще только JSON структуры, и JSON состояния и данных. Слава всем богам, чистым HTML я не оперирую :)
Увы, я это знаю. Зачастую многие фишки умирают из-за того, что они слишком сложны. Вообще программистам нельзя давать в руки власть :) Я стараюсь придерживаться правила Apple — если 9 вещей из 10-и можно сделать просто, а 10 из 10 только сложно, то мы делаем лишь 9 вещей (но по человечески). Как-то так.
К слову можно обойтись и без EAV в вашем случае (но нужно ли). Все же EAV вещь такая, суровая сама по себе :) Главное чтоб о ней не знал уровень View, где живет форма — ИМХО.
Обязательно напишу подробнее о структуре, но к слову у нас ORM, и как бы обычные таблицы-сущности. Там мультилинки, ссылки, ТЧ, прочая фигня, хехе :) Но это не уровень абстрации View, повторяюсь.
А по поводу js, понимаю вашу боль… По этому мы пришли к выводу, что все это надо считать на сервере, ибо удобнее управляться на C# с этим, чем на js. А клиент должен только четко выполнить команды сервера по выставлению состояний полей и контейнеров (у нас это зовется состоянием формы).
Причем пульсары очень разные, можно сказать что в их сигнале зашит GUID.
Забавно у вас, телепортировать материальные объекты в другую галактику просто, а вот телепортировать информацию — практически невозможно. Вообще материя, энергия и ифнормация — это одно и то же. Скорость распространения ограничена скростью света. Телепортация в данном понимании — махенизм обхода ограничений скорости света для передачи материи/энергии/информации.
Насчет указанного примера — подтверждаю, можно сделать вот так. Блоки на линию были наложены так (это вообще песочница рафаели, очень полезная штука, а вот юзер группа, где я два года назад пытался понять как это делать).
Да, можно. В примерчике поле «Метро» может быть изначально невидимым, как после выбора города «Певек». Там контейнер колонок, в нем две колонки, в каждой из них поле. Одно поле прячется — второе раздвигается на всю ширину. Вообще это можно по разному делать, если ситуация типовая — я бы ввел структуры, и обрабатывал тип поля структуры как одно сложное поле, внутрях которой своя сложная логика (мы к этому подходим).
>Грешников делом, мы даже сначала думали захардкодить 42 формы и не париться, но на первой же форме поняли что это плохая идея
Вам чертовски повезло ;) Очень жирная грабля однако!
Обязательно напишу подробнее о структуре, но к слову у нас ORM, и как бы обычные таблицы-сущности. Там мультилинки, ссылки, ТЧ, прочая фигня, хехе :) Но это не уровень абстрации View, повторяюсь.
А по поводу js, понимаю вашу боль… По этому мы пришли к выводу, что все это надо считать на сервере, ибо удобнее управляться на C# с этим, чем на js. А клиент должен только четко выполнить команды сервера по выставлению состояний полей и контейнеров (у нас это зовется состоянием формы).