Все зависит от того, как этих специалистов обучают дальше. Если в дальнейшем они предоставлены сами себе, и день изо дня пишут тонны однотипного кода, то в будущем при работе над более серьезными проектами могут быть проблемы.
Если же компания заботится о повышении уровня своих сотрудников то результат наверняка будет хорошим. Как говорится главное придать начальное ускорение в нужном направлении. :)
Было бы интересно почитать про ваш Eav.
По поводу лифтов и т.п., а вариант с двумя связанными полями не катит?
Можно же такие поля обрабатывать каскадом например.
Читая этот комментарий вспомнилась картинка проекта «Карусель», а именно пункт «чего хотел пользователь».
Не принимайте на свой счет, я лишь хотел сказать что часто бывают ситуации, когда мега-крутой функционал пользователи ценят меньше чем внешнюю простоту.
Ну это с какой стороны посмотреть. С учетом того что есть автокомплит на этом поле, способ конечно хороший, но если бы я жил в Певеке, где нет метро, мне бы такая форма могла сразу субъективно вызвать отторжение.
Да и лишний трафик в конце концов.
ИМХО лучше делать форму проще, особенно если полей и без того хватает.
Теперь как раз все понятно.
Есть некоторые стереотипы для форм, которые включают в себя несколько атрибутов (например на этой форме все поля должны быть красного цвета, а уголки закругленные), я так понял что вы для каждой такой группы заводите таблицу?
Если так, что два последних комментария можно заменить словом нормализация :)
Кстати к вопросу о метро — было бы логичнее по умолчанию это поле не показывать, а показывать только при выборе города где метро есть.
Ясное дело что это демка, но вызвало некоторый диссонанс. Ведь если я не выбрал город, то в списке должно быть несколько сотен станций, а если я выбрал город, то искать нужную станцию будет гораздо комфортнее.
Что то чем дальше, тем непонятнее.
Про какие слои речь? Сбор свойств элемента формы?
Мне кажется не стоит все так усложнять. Таблица со значениями полей отдельно, таблица с мета-информацией отдельно, связь по ключу. Все, дальше дело техники :)
Ну в принципе можно раскидать по отдельным табличкам но это уже зависит от конкретной задачи.
В целом неплохо, но эта тема может быть довольно специфичной.
На моей практике использовалось два варианта динамических форм совершенно не похожих друг на друга:
1. Форма только со справочными значениями изменяющаяся каскадом. Для каждого элемента формы (select) присутствовала следующая информация: Описание основных свойств, ссылка на список возможных значений (обычно таблица, или функция БД) и список полей зависящих от него. HTML код у всех элементов был одинаков. Таким образом обновив одно значение процесс обновления далее каскадом шел вниз по дереву.
2. Более интересный вариант. Форма содержала огромное количество элементов. Количество и типы элементов заранее неизвестны. Для всех элементов присутствовала мета информация — тип поля (текстовое, выпадающий список, дата), доступность для редактирования, ссылка на родительский элемент от которого зависит поле, и т.п. Таким образом получилась форма с полями разного типа, и что более интересно с полями которые могут меняться в зависимости от изменения других полей. Вся мета-информация хранится в БД.
Учитывая вышесказанное, могу сказать только одно — универсального решения здесь нет, т.к. это чистой воды бизнес-логика.
Кстати на счет ПУЗов — раньше не слышал про такое сокращение. Это какой то общепринятый термин, или лично ваша терминология?
Для отдельно взятого сайта это может и не очень интересно — кому надо могут просто QR-код разместить (и многие размещают), а вот как дополнение к браузеру было бы очень даже неплохо.
Если же компания заботится о повышении уровня своих сотрудников то результат наверняка будет хорошим. Как говорится главное придать начальное ускорение в нужном направлении. :)
Так же как и в моем случае, и во многих других впрочем.
На счет описания, в топике есть описание реализации и ссылка на прототип, помоему этого вполне достаточно. Спускаться дальше к деталям было бы скучно.
Ну и в конце концов это же хабр — единственное место где из комментариев узнаешь больше чем из топика :)
По поводу лифтов и т.п., а вариант с двумя связанными полями не катит?
Можно же такие поля обрабатывать каскадом например.
Я бы тоже написал, да только времени нет.
Не принимайте на свой счет, я лишь хотел сказать что часто бывают ситуации, когда мега-крутой функционал пользователи ценят меньше чем внешнюю простоту.
Да и лишний трафик в конце концов.
ИМХО лучше делать форму проще, особенно если полей и без того хватает.
Есть некоторые стереотипы для форм, которые включают в себя несколько атрибутов (например на этой форме все поля должны быть красного цвета, а уголки закругленные), я так понял что вы для каждой такой группы заводите таблицу?
Если так, что два последних комментария можно заменить словом нормализация :)
Ясное дело что это демка, но вызвало некоторый диссонанс. Ведь если я не выбрал город, то в списке должно быть несколько сотен станций, а если я выбрал город, то искать нужную станцию будет гораздо комфортнее.
Про какие слои речь? Сбор свойств элемента формы?
Мне кажется не стоит все так усложнять. Таблица со значениями полей отдельно, таблица с мета-информацией отдельно, связь по ключу. Все, дальше дело техники :)
Ну в принципе можно раскидать по отдельным табличкам но это уже зависит от конкретной задачи.
На моей практике использовалось два варианта динамических форм совершенно не похожих друг на друга:
1. Форма только со справочными значениями изменяющаяся каскадом. Для каждого элемента формы (select) присутствовала следующая информация: Описание основных свойств, ссылка на список возможных значений (обычно таблица, или функция БД) и список полей зависящих от него. HTML код у всех элементов был одинаков. Таким образом обновив одно значение процесс обновления далее каскадом шел вниз по дереву.
2. Более интересный вариант. Форма содержала огромное количество элементов. Количество и типы элементов заранее неизвестны. Для всех элементов присутствовала мета информация — тип поля (текстовое, выпадающий список, дата), доступность для редактирования, ссылка на родительский элемент от которого зависит поле, и т.п. Таким образом получилась форма с полями разного типа, и что более интересно с полями которые могут меняться в зависимости от изменения других полей. Вся мета-информация хранится в БД.
Учитывая вышесказанное, могу сказать только одно — универсального решения здесь нет, т.к. это чистой воды бизнес-логика.
Кстати на счет ПУЗов — раньше не слышал про такое сокращение. Это какой то общепринятый термин, или лично ваша терминология?