18.01.2017, 16:30
|
|
CacheVar
|
|
Регистрация: 19.08.2010
Сообщений: 14,205
|
|
Сообщение от serj0110
|
Просто не думаю что это лучшая идея как у меня
|
У тебя так вовсе мутно.
И править/сопровождать будет дюже муторно...
|
|
18.01.2017, 16:32
|
Аспирант
|
|
Регистрация: 22.10.2016
Сообщений: 32
|
|
Сообщение от laimas
|
Уже теплее, но
опять не правильно.
|
Даже не знаю, можно по подробней, просто это первый проект крупный, в одного разрабатывать тяжеловато, могу чего-то не учесть
|
|
18.01.2017, 16:34
|
Аспирант
|
|
Регистрация: 22.10.2016
Сообщений: 32
|
|
Сообщение от ksa
|
У тебя так вовсе мутно.
И править/сопровождать будет дюже муторно...
|
Для этого я привел кусок скрипта с авито и попросил объяснить, просто там 40К строчек, пытался разобраться, но слишком много, и не могу понять что за метод)
|
|
18.01.2017, 16:49
|
Профессор
|
|
Регистрация: 14.01.2015
Сообщений: 12,990
|
|
Сообщение от serj0110
|
Даже не знаю, можно по подробней
|
Можно, но в общих чертах.
Форма, это всего лишь инструмент обмена данными клиент->сервер и она никак не может определять структуру данных (таблиц) на сервере. А вот таблица базы вполне может это делать.
Даже если у нескольких категорий объявлений одинаковое число параметров, то это еще не означает, что их нужно держать в одной таблице, это не выгодно.
И так - категории объявлений "Транспорт", "Недвижимость", и т.д., это первичная таблица в базе, которая по мимо наименования категории содержит ее описание и прочее сопутствующее, как то идентификатор категории и связь ее с таблицей описывающей ее объявления.
У каждой категории своя таблица объявлений, связанная с первичной таблицей. А поля таблицы, это не только "ценный мех..." , то бишь name_field, а также и параметры этих полей: тип поля, размерность, null/not null, комментарий.
Если пользователь выбрал категорию объявления, то серверу достаточно передать идентификатор ее. По этому идентификатору сервер получает параметры таблицы объявлений, по которым и строит либо готовый html-код формы, либо отдает клиенту параметры для нее в виде JSON, а клиент "рисует".
При этом комментарий поля, это метка к нему, тип поля, это тип поля формы, размерность, это условие (длина введенного и прочее) и текст для placeholder, NULL/NOT NULL обязательно или нет поле формы для заполнения (required).
Таким образом требуется один сценарий для построения формы для любой категории объекта, а так как источник таблицы, то все изменения в ней автоматически будут применяться и к форме, что не потребует их правок.
Все.
|
|
18.01.2017, 17:00
|
Аспирант
|
|
Регистрация: 22.10.2016
Сообщений: 32
|
|
Сообщение от laimas
|
Можно, но в общих чертах.
Форма, это всего лишь инструмент обмена данными клиент->сервер и она никак не может определять структуру данных (таблиц) на сервере. А вот таблица базы вполне может это делать.
Даже если у нескольких категорий объявлений одинаковое число параметров, то это еще не означает, что их нужно держать в одной таблице, это не выгодно.
И так - категории объявлений "Транспорт", "Недвижимость", и т.д., это первичная таблица в базе, которая по мимо наименования категории содержит ее описание и прочее сопутствующее, как то идентификатор категории и связь ее с таблицей описывающей ее объявления.
У каждой категории своя таблица объявлений, связанная с первичной таблицей. А поля таблицы, это не только "ценный мех..." , то бишь name_field, а также и параметры этих полей: тип поля, размерность, null/not null, комментарий.
Если пользователь выбрал категорию объявления, то серверу достаточно передать идентификатор ее. По этому идентификатору сервер получает параметры таблицы объявлений, по которым и строит либо готовый html-код формы, либо отдает клиенту параметры для нее в виде JSON, а клиент "рисует".
При этом комментарий поля, это метка к нему, тип поля, это тип поля формы, размерность, это условие (длина введенного и прочее) и текст для placeholder, NULL/NOT NULL обязательно или нет поле формы для заполнения (required).
Таким образом требуется один сценарий для построения формы для любой категории объекта, а так как источник таблицы, то все изменения в ней автоматически будут применяться и к форме, что не потребует их правок.
Все.
|
Хм.. я задумывался по поводу того, чтобы хранить необходимые параметры в таблице, но как то откидывала меня. Кажется пришла идея, правда придётся снова проводить кучу тестов для получения мне нужных результатов.
Спасибо тебе огромнейшее
|
|
18.01.2017, 17:08
|
Профессор
|
|
Регистрация: 14.01.2015
Сообщений: 12,990
|
|
Сообщение от serj0110
|
я задумывался по поводу того, чтобы хранить необходимые параметры в таблице
|
У каждого поля sql таблицы не зависимо от того хотите вы того или нет, вы обязаны указать ее параметры. А значит тип VARCHAR: если макс. длина выбрана к примеру 120, то это input type=text, а если 5000, уже textarea, и тип TEXT и с приставками к нему тоже textarea. А тип ENUM, это может быть список, или же если два три значения, то может быть и набором радио кнопок. А тип SET набор флажков. Ну и прочие параметры, о которых говорилось и будут определять "портрет" формы.
Разработка приложения начинается не с построения формы, а с представления структуры данных в базе. Определите ее удачно, значит 99% успеха уже есть, а нет, так никакая крутая форма не поможет, -99% к успеху будет обеспечено.
Таблицы по мимо данных которые будет присылать клиент для хранения обязательно имеют и другие поля, которые в форме никак не отражаются - дата добавления, к примеру.
Вот о чем в первую очередь надо думать, а формы по таблицам.
|
|
18.01.2017, 17:15
|
Аспирант
|
|
Регистрация: 22.10.2016
Сообщений: 32
|
|
Сообщение от laimas
|
У каждого поля sql таблицы не зависимо от того хотите вы того или нет, вы обязаны указать ее параметры. А значит тип VARCHAR: если макс. длина выбрана к примеру 120, то это input type=text, а если 5000, уже textarea, и тип TEXT и с приставками к нему тоже textarea. А тип ENUM, это может быть список, или же если два три значения, то может быть и набором радио кнопок. А тип SET набор флажков.
Разработка приложения начинается не с построения формы, а с представления структуры данных в базе. Определите ее удачно, значит 99% успеха уже есть, а нет, так никакая крутая форма не поможет, -99% к успеху будет обеспечено.
Таблицы по мимо данных которые будет присылать клиент для хранения обязательно имеют и другие поля, которые в форме никак не отражаются - дата добавления, к примеру.
Вот о чем в первую очередь надо думать, а формы по таблицам.
|
Не могу не согласиться с тобой, так я и не говорил что я разрабатываю приложение с формы
P.S. у меня была рабочая версия под недвижимость, но так как решился задать этим вопрос, удалил его полностью, чтобы перестроить всё с нуля)
|
|
18.01.2017, 17:18
|
Профессор
|
|
Регистрация: 14.01.2015
Сообщений: 12,990
|
|
Сообщение от serj0110
|
я и не говорил что я разрабатываю приложение с формы
|
А я этого и не утверждаю, но камень преткновения "и как описать форму и ее построить" в то время когда это фактически определено, наводит на мысль о бутерброде дяди Федора.
PS. Могу даже заключить пари, если строить формы по указанному выше, то для приема и обработки данных потребуется один сценарий на сервере, а не карячиться над каждой формой своим.
Последний раз редактировалось laimas, 18.01.2017 в 17:21.
|
|
18.01.2017, 17:28
|
Аспирант
|
|
Регистрация: 22.10.2016
Сообщений: 32
|
|
Сообщение от laimas
|
А я этого и не утверждаю, но камень преткновения "и как описать форму и ее построить" в то время когда это фактически определено, наводит на мысль о бутерброде дяди Федора.
PS. Могу даже заключить пари, если строить формы по указанному выше, то для приема и обработки данных потребуется один сценарий на сервере, а не карячиться над каждой формой своим.
|
Так я тебе плюсанул, так как ты подал мне идею в один сценарий)
Только как говорил, много тестов придётся провести пока получу нужные мне результаты.
Не получается с первого раза )
|
|
18.01.2017, 18:47
|
Аспирант
|
|
Регистрация: 22.10.2016
Сообщений: 32
|
|
Сообщение от Rise
|
serj0110, это называется пошаговая форма, предыдущие шаги хранятся на сервере в переменных сессии, собственно сессии для таких форм и создавались изначально.
|
Извини Rise, слегка не до понял тебя, допустим, я храню прошлые шаги в сессии, это я понял, проблема в том, как без рутинной работы подобрать что необходимо вывести пользователю для заполнения.
P.S. Меня не устраивает в моей работе то, что я прописываю вручную все формы в зависимости от выбора.
Последний раз редактировалось serj0110, 18.01.2017 в 18:53.
|
|
|
|