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

Всем привет, разрабатываю сайт объявлений, идёт вроде всё хорошо, но меня беспокоит одно "НО", при переходе на страницу подачи объявлений, есть меню навигации для выбора какого типа объявления будет подавать пользователь, и у некоторых типов объявлений своя уникальная форма(например, у Недвижимости одна форма, у транспорта другая форма). И возник вопрос, как можно это реализовать(не могу точно сформулировать вопрос)?
P.S. Мой рабочий вариант меня как-то не устраивает, приходится каждый раз считывать элементы, и только потом ему выводится форма.
И второй вопрос, не сильно отличается от первого

avito.filters = {
    1: ["Транспорт"],
    4: ["Недвижимость"],
    110: ["Работа"],
    113: ["Услуги"],
    5: ["Личные вещи"],
    2: ["Для дома и дачи"],
    6: ["Бытовая электроника"],
    7: ["Хобби и отдых"],
    35: ["Животные"],
    8: ["Для бизнеса"],
    9: {
        0: "Автомобили",
        _2685: [{
            name: "Место осмотра",
            type: "c",

Как вы поняли, это кусок скрипта с авито, и как я понял, за счёт него генерируется форма. Может кто-нибудь знает что это за способ, больно он очень заинтересовал меня.

И где хранится будут эти объявления на сервере?

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

Совершенно верно

Верно то верно, но на чем это должно основываться?

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

if (value1 === "НЕДВИЖИМОСТЬ") {
			if (value2 === "Квартиры") {
				if (value3 === "Куплю") {
					addinfo("Населенный пункт *", "text", "location", "20");
					addperson();
					sel("Количество комнат", "rooms", "Студия 1 2 3 4 5 >_5");
					addinfo("Название объявления *", "text", "title", "50");
					adddescription("Описание объявления");
					addcoins("Цена");
					submitForm();
				}

addinfo, addperson, sel, adddescription,addcoins - это функции по генерации форм

Неправильно ты, дядя Фёдор, бутерброд ешь. ;)

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

Так вот и говорю, меня не устраивает мой метод работы :)

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

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

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

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

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

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

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

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

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

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

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

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

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

Все.

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

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

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

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

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

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

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

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

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

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

Как характеристики объекта недвижимости сгруппировать по каким либо признакам и можно ли это вообще сделать? Можно ведь, так? А если это можно, можно ли считать такие группы поэтапными шагами формы?

if (value1 === "НЕДВИЖИМОСТЬ") {
			if (value2 === "Квартиры") {
				if (value3 === "Куплю") {
					addinfo("Населенный пункт *", "text", "location", "20");
					addperson();
					sel("Количество комнат", "rooms", "Студия 1 2 3 4 5 >_5");
					addinfo("Название объявления *", "text", "title", "50");
					adddescription("Описание объявления");
					addcoins("Цена");
					submitForm();
				}
			}[
}

Всё что идёт после условий, это функции которые выводят необходимые поля для заполнения, ну а так как таких условий просто очень много, работа становится рутинной :(