Огромная форма

[ksa]

Просто не думаю что это лучшая идея как у меня

У тебя так вовсе мутно.
И править/сопровождать будет дюже муторно...

[serj0110]

Уже теплее, но



опять не правильно.

Даже не знаю, можно по подробней, просто это первый проект крупный, в одного разрабатывать тяжеловато, могу чего-то не учесть

[serj0110]

У тебя так вовсе мутно.
И править/сопровождать будет дюже муторно...

Для этого я привел кусок скрипта с авито и попросил объяснить, просто там 40К строчек, пытался разобраться, но слишком много, и не могу понять что за метод)

[laimas]

Даже не знаю, можно по подробней

Можно, но в общих чертах.

Форма, это всего лишь инструмент обмена данными клиент->сервер и она никак не может определять структуру данных (таблиц) на сервере. А вот таблица базы вполне может это делать.

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

И так - категории объявлений "Транспорт", "Недвижимость", и т.д., это первичная таблица в базе, которая по мимо наименования категории содержит ее описание и прочее сопутствующее, как то идентификатор категории и связь ее с таблицей описывающей ее объявления.

У каждой категории своя таблица объявлений, связанная с первичной таблицей. А поля таблицы, это не только "ценный мех..." , то бишь name_field, а также и параметры этих полей: тип поля, размерность, null/not null, комментарий.

Если пользователь выбрал категорию объявления, то серверу достаточно передать идентификатор ее. По этому идентификатору сервер получает параметры таблицы объявлений, по которым и строит либо готовый html-код формы, либо отдает клиенту параметры для нее в виде JSON, а клиент "рисует".

При этом комментарий поля, это метка к нему, тип поля, это тип поля формы, размерность, это условие (длина введенного и прочее) и текст для placeholder, NULL/NOT NULL обязательно или нет поле формы для заполнения (required).

Таким образом требуется один сценарий для построения формы для любой категории объекта, а так как источник таблицы, то все изменения в ней автоматически будут применяться и к форме, что не потребует их правок.

Все.

[serj0110]

Можно, но в общих чертах.

Форма, это всего лишь инструмент обмена данными клиент->сервер и она никак не может определять структуру данных (таблиц) на сервере. А вот таблица базы вполне может это делать.

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

И так - категории объявлений "Транспорт", "Недвижимость", и т.д., это первичная таблица в базе, которая по мимо наименования категории содержит ее описание и прочее сопутствующее, как то идентификатор категории и связь ее с таблицей описывающей ее объявления.

У каждой категории своя таблица объявлений, связанная с первичной таблицей. А поля таблицы, это не только "ценный мех..." , то бишь name_field, а также и параметры этих полей: тип поля, размерность, null/not null, комментарий.

Если пользователь выбрал категорию объявления, то серверу достаточно передать идентификатор ее. По этому идентификатору сервер получает параметры таблицы объявлений, по которым и строит либо готовый html-код формы, либо отдает клиенту параметры для нее в виде JSON, а клиент "рисует".

При этом комментарий поля, это метка к нему, тип поля, это тип поля формы, размерность, это условие (длина введенного и прочее) и текст для placeholder, NULL/NOT NULL обязательно или нет поле формы для заполнения (required).

Таким образом требуется один сценарий для построения формы для любой категории объекта, а так как источник таблицы, то все изменения в ней автоматически будут применяться и к форме, что не потребует их правок.

Все.

Хм.. я задумывался по поводу того, чтобы хранить необходимые параметры в таблице, но как то откидывала меня. Кажется пришла идея, правда придётся снова проводить кучу тестов для получения мне нужных результатов.
Спасибо тебе огромнейшее

[laimas]

я задумывался по поводу того, чтобы хранить необходимые параметры в таблице

У каждого поля sql таблицы не зависимо от того хотите вы того или нет, вы обязаны указать ее параметры. А значит тип VARCHAR: если макс. длина выбрана к примеру 120, то это input type=text, а если 5000, уже textarea, и тип TEXT и с приставками к нему тоже textarea. А тип ENUM, это может быть список, или же если два три значения, то может быть и набором радио кнопок. А тип SET набор флажков. Ну и прочие параметры, о которых говорилось и будут определять "портрет" формы.

Разработка приложения начинается не с построения формы, а с представления структуры данных в базе. Определите ее удачно, значит 99% успеха уже есть, а нет, так никакая крутая форма не поможет, -99% к успеху будет обеспечено.

Таблицы по мимо данных которые будет присылать клиент для хранения обязательно имеют и другие поля, которые в форме никак не отражаются - дата добавления, к примеру.

Вот о чем в первую очередь надо думать, а формы по таблицам.

[serj0110]

У каждого поля sql таблицы не зависимо от того хотите вы того или нет, вы обязаны указать ее параметры. А значит тип VARCHAR: если макс. длина выбрана к примеру 120, то это input type=text, а если 5000, уже textarea, и тип TEXT и с приставками к нему тоже textarea. А тип ENUM, это может быть список, или же если два три значения, то может быть и набором радио кнопок. А тип SET набор флажков.

Разработка приложения начинается не с построения формы, а с представления структуры данных в базе. Определите ее удачно, значит 99% успеха уже есть, а нет, так никакая крутая форма не поможет, -99% к успеху будет обеспечено.

Таблицы по мимо данных которые будет присылать клиент для хранения обязательно имеют и другие поля, которые в форме никак не отражаются - дата добавления, к примеру.

Вот о чем в первую очередь надо думать, а формы по таблицам.

Не могу не согласиться с тобой, так я и не говорил что я разрабатываю приложение с формы
P.S. у меня была рабочая версия под недвижимость, но так как решился задать этим вопрос, удалил его полностью, чтобы перестроить всё с нуля)

[laimas]

я и не говорил что я разрабатываю приложение с формы

А я этого и не утверждаю, но камень преткновения "и как описать форму и ее построить" в то время когда это фактически определено, наводит на мысль о бутерброде дяди Федора.

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

[serj0110]

А я этого и не утверждаю, но камень преткновения "и как описать форму и ее построить" в то время когда это фактически определено, наводит на мысль о бутерброде дяди Федора.

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

Так я тебе плюсанул, так как ты подал мне идею в один сценарий)
Только как говорил, много тестов придётся провести пока получу нужные мне результаты.
Не получается с первого раза )

[serj0110]

serj0110, это называется пошаговая форма, предыдущие шаги хранятся на сервере в переменных сессии, собственно сессии для таких форм и создавались изначально.

Извини Rise, слегка не до понял тебя, допустим, я храню прошлые шаги в сессии, это я понял, проблема в том, как без рутинной работы подобрать что необходимо вывести пользователю для заполнения.
P.S. Меня не устраивает в моей работе то, что я прописываю вручную все формы в зависимости от выбора.