Форум: Форум PHPФорум ApacheФорум Регулярные ВыраженияФорум MySQLHTML+CSS+JavaScriptФорум FlashРазное
Новые темы: 0000000
Социальная инженерия и социальные хакеры. Авторы: Кузнецов М.В., Симдянов И.В. PHP 5. На примерах. Авторы: Кузнецов М.В., Симдянов И.В., Голышев С.В. C++. Мастер-класс в задачах и примерах. Авторы: Кузнецов М.В., Симдянов И.В. PHP на примерах (2 издание). Авторы: Кузнецов М.В., Симдянов И.В. PHP 5/6. В подлиннике. Авторы: Кузнецов М.В., Симдянов И.В.
ВСЕ НАШИ КНИГИ
Консультационный центр SoftTime

Форум MySQL

Выбрать другой форум

 

Здравствуйте, Посетитель!

вид форума:
Линейный форум Структурный форум

тема: Динамичесские поля через админку.
 
 автор: dima_s_d_s   (08.05.2011 в 08:43)   письмо автору
 
 

Привет.

Нужно через админку создать поле с какими то параметрами и что-бы оно потом выводилось где-то на странице между какими то полями.

Есть одна идея как это реализовать, но не хочется строить велосипед.

Может кто подскажет как это лучше реализовать?

Есть ли Framework на котором все это можно реализовать? (например наличие готовых методов создания форм по типам, что-то такого).

Заранее благодарен.

  Ответить  
 
 автор: cheops   (08.05.2011 в 11:35)   письмо автору
 
   для: dima_s_d_s   (08.05.2011 в 08:43)
 

Вы планируете реализацию таких динамических полей через базу данных? Если да, то что вызывает затруднение? Организация базы данных?

  Ответить  
 
 автор: dima_s_d_s   (08.05.2011 в 12:04)   письмо автору
 
   для: cheops   (08.05.2011 в 11:35)
 

Да, через базу данных.

Допустим есть табличка car_info.
Хочу по необходимости вносить изменения в кол/тип. полей через админку.
А на клиентскй части выводить данные.

Как я себе представляю данные с car_info будут считываться в какой-то массив

array[type] = ..
array[name]=..
array[value]=..


При выводе уже можно смотреть по типу и приводить в нужный вид конкретное значение

Все это можно сделать, но что взять за каркас.
На данный момент я вижу много обработки при выводе.
Может есть другой подход?
Как ко всему этому можно подойти более объектно?

Спасибо.

  Ответить  
 
 автор: cheops   (08.05.2011 в 15:06)   письмо автору
 
   для: dima_s_d_s   (08.05.2011 в 12:04)
 

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

  Ответить  
 
 автор: dima_s_d_s   (08.05.2011 в 15:38)   письмо автору
 
   для: cheops   (08.05.2011 в 15:06)
 

>Готовый бесплатный каркас я не встречал.
А есть что-то платно?

>Мы подобную штуку разрабатывали и отлаживали в студии самостоятельно. Тут еще проблема в эффективности базы данных, объектный подход применить тут не сложно, сложнее, чтобы числа ложились у вас в цифровые поля базы данных, строковые - в строковые, а списки - в перечисляемые. Вот это реализовать гораздо сложнее, особенно если отказаться от пагубного подхода - один тип позиций - одна таблица в базе данных.
Какой у вас был принцип вывода, примерно такой как я описал?

Сапсибо

  Ответить  
 
 автор: cheops   (08.05.2011 в 16:27)   письмо автору
 
   для: dima_s_d_s   (08.05.2011 в 15:38)
 

Смысл такой, что задача разработки каталогов и позиций к ним возникает очень часто. Разный состав параметров позиций, а зачастую и доп.параметры каталогов приводят к тому, что требуется постоянная модификация полей базы данных и вывода. Т.е. тут хорошо бы разработать движок, причем задача идеальная для применения ООП. Ситуация осложняется тем, что такие приложения крайне чувствительны к производительности и поместить сериализованные объекты в базу данных или даже просто использовать для всех типов данных строковые типы очень накладно даже для небольшой базы данных, не говоря уже о каком-то объемном проекте. В идеале нужно, чтобы у нас появилось приложение, позволяющее вводить произвольное количество полей (строки, целые числа и числа с плавающей точкой, диапазоны, флаги состояния, изображения, ссылки). Причем система бы была расширяемая и позволяла бы для каждого из новых типов полей и элементов управления создавать допустим класс + тип таблиц, которые бы автоматически подцеплялись бы системой.
Мы в свое время начали решение задачи с решение задачи с построения SoftTime FrameWork, учебный вариант которого мы разбираем в наших книгах. Он позволяет строить расширяемые формы, содержит обертку для автоматизации сбора ошибок. Одновременно мы экспериментировали с построением базы данных, чтобы конечная система не потеряла в производительности. Чтобы с одной стороны, не было потери производительности, не было дублирующих подсистем, а с другой стороны система бы не интегрировалась бы очень сильно, чтобы можно было модули из одного сайта можно было безболезненно вынимать и вставлять в другой сайт.

Конечная цель, чтобы редактор щелкая мышью создавал структуру каталога, а движок автоматически размещал данные в устойчивой для нагрузке схеме базы данных, автоматически выстраивал систему управления (добавление, редактирование, сокрытие/отображение, перемещение позиции) и систему представления и поиска по данным. Причем наша цель предоставить не конечные интерфейсы, а API, позволяющая разработчику очень быстро разрабатывать страницы представления.

Пока вся система находится в стадии разработки и мы не готовы её представить (ни платно, ни бесплатно). Однако, все соображения по таким системам я всегда с удовольствием выскажу и при построении аналогичных систем с удовольствием помогу (возможно совместное обсуждение натолкнет на какие-то более изящные решения).

>А есть что-то платно?
Я не очень искал если честно, мы не очень любим впадать в зависимость от чужого инструментария. Это конечно до некоторой степени лукавство, так как приходится зависеть от множества платформ и языков программирования, но если есть возможность избежать чужой надстройки (особенно не стандартной, вроде шаблонизаторов), мы стараемся её избежать - каждая лишняя технология, сужает возможности (т.е. чужая система может безобразно использовать возможности базы данных, или иметь сильную интеграцию и сложное подключение/отключение модулей), лучше пусть она сужается под нашим контролем и в наших интересах.

  Ответить  
Rambler's Top100
вверх

Rambler's Top100 Яндекс.Метрика Яндекс цитирования