[DB_Login]
title="Логин для входа в Базу Данных"
description=""
inConfig=1
editable=1
type="string"
value="root"
[User_Charset]
title="В какой кодировке отдавать данные пользователю"
description=""
inConfig=1
editable=1
type="enum"
enum="UTF-8;WINDOWS-1251;KOI8-R"
value=0
[Gzip_Use]
title="Использовать Gzip-сжатие"
description=""
inConfig=1
editable=1
type="boolean"
value=0
Веб-интерфейсы
Приветствую.
Хочется поднять вот какую тему. Наверняка, многие из вас сталкивались с необходимостью программировать веб-интерфейсы с большим количеством элементов (CMS, админки разнообразных скриптов и т.д.). В таких интерфейсах много элементов: тут и чекбоксы, и текстовые поля, и выпадающие списки и т.д. Порой на одной странице их количество может исчисляться десятками.
Как вы лично подходите к проблеме программирования и обработки большого количества таких элементов?
Меня интересует прежде всего подход, методики: фреймворки ли это, либо просто самописная библиотечка... ;)
Хочется поднять вот какую тему. Наверняка, многие из вас сталкивались с необходимостью программировать веб-интерфейсы с большим количеством элементов (CMS, админки разнообразных скриптов и т.д.). В таких интерфейсах много элементов: тут и чекбоксы, и текстовые поля, и выпадающие списки и т.д. Порой на одной странице их количество может исчисляться десятками.
Как вы лично подходите к проблеме программирования и обработки большого количества таких элементов?
Меня интересует прежде всего подход, методики: фреймворки ли это, либо просто самописная библиотечка... ;)
самописная библиотечка... была написала пару лет назад в "конторе", в которой я работаю :) до сих пор апгрейдится местами, но в большинстве случаев просто используется, без изменений.
Вручную :D
Цитата: int
Вручную :D
Чаще всего вручную. Но есть и самопальная библиотечка, которую в простых случаях можно использовать. Вот только, к сожалению, простых случаев почти не попадается теперь.
Цитата: RussianSpy
Как вы лично подходите к проблеме программирования и обработки большого количества таких элементов?
я не исключения, тоже вручную :D (Только хорошо документированную!)
делал редко но вручную
Самописная библиотечка в очень плохом состоянии. (Валидацыя + подсветка ошибок + подгрузка списков селектов аяксом)
Меня как-то достало вручную обрабатывать (элементарные настройки с textbox, checkbox, select), так что написал бибилиотечку) Правда кривоватая, но переписывать пока не собираюсь, так как пока функционала её хватает. Принцип простой - весь конфиг храниться в *.ini, например:
и т.д.
Соответсвенно форма для редактирования библиотекой сама делается, и обрабатывается опять же ей. При редактировании парсит на то, является ли новое значение bool, int и далее (ну короче элементарная проверка, чтоб не ввели че не надо). Может и муторно и кривовато, но зато хоть не надо вручуню все проверять))
ЗЫ: поля inConfig - это когда происходит кэширование в php файл конфига. Т.е. пихать его туда или нет
[COLOR="Silver"]ЗЫЫ: надо бы ещё, чтоб по регулярке, было б прикольно, да лень(([/COLOR]
Код:
и т.д.
Соответсвенно форма для редактирования библиотекой сама делается, и обрабатывается опять же ей. При редактировании парсит на то, является ли новое значение bool, int и далее (ну короче элементарная проверка, чтоб не ввели че не надо). Может и муторно и кривовато, но зато хоть не надо вручуню все проверять))
ЗЫ: поля inConfig - это когда происходит кэширование в php файл конфига. Т.е. пихать его туда или нет
[COLOR="Silver"]ЗЫЫ: надо бы ещё, чтоб по регулярке, было б прикольно, да лень(([/COLOR]
Вручную )
Это все конечно грустно. Я думал, что хоть кто-то тут делает не так как я и натолкнет на новые идеи(((
Все зависит от кол-ва полей, их разнородности, смысла и пр. Иногда проще написать вручную. В последнем проекте писал автоматическую подсистему считывания параметров, проверки и пр.
Цитата: RussianSpy
Как вы лично подходите к проблеме программирования и обработки большого количества таких элементов?
Меня интересует прежде всего подход, методики: фреймворки ли это, либо просто самописная библиотечка... ;)
Меня интересует прежде всего подход, методики: фреймворки ли это, либо просто самописная библиотечка... ;)
.NET - я не хочу париться о сохранении состояния контрола, о его внутренней логике и еще тонне мелочей.
.NET не катит
Интересует только OpenSource
Интересует только OpenSource
если надо многофункционально, но быстро - беру Catalyst Framework.
А я самописные классы применяю, которые генерят мне что надо. А вообще в Drupal такой проблемы нет почти :)
Для мелких проектов юзаю phpdbform со своими доработками. Вещь хоть и мёртвая, но зато рабочая и податливая. Встроил туда FCKeditor и больше мне от жизни ничего не надо :)
Хорошую идею ты подал. phpdbform можно доработать, встроить туда много полезностей и чуть адаптировать под современные реалии. И заново подать публике - уверен, интерес к таким вещам есть (как в своё время он появился у меня).
Для мелких проектов юзаю phpdbform со своими доработками. Вещь хоть и мёртвая, но зато рабочая и податливая. Встроил туда FCKeditor и больше мне от жизни ничего не надо :)
Хорошую идею ты подал. phpdbform можно доработать, встроить туда много полезностей и чуть адаптировать под современные реалии. И заново подать публике - уверен, интерес к таким вещам есть (как в своё время он появился у меня).
Цитата: RussianSpy
.NET не катит
Интересует только OpenSource
Интересует только OpenSource
Чегож так категорично. Есть Mono.
Недоделанный и брошенный Mono. Нет - не катит. К тому же .NET не стоит ни на одном хостинге. Так что подойдут только библиотеки или фреймворки написанные на открытых скриптовых языках. Плюс не хочу иметь ничего общего с компанией БГ. ))))
Давайте тогда подумаем над тем каким требованиям должна соответствовать такая библиотечка)) Кто что думает?
Давайте тогда подумаем над тем каким требованиям должна соответствовать такая библиотечка)) Кто что думает?
Цитата: RussianSpy
К тому же .NET не стоит ни на одном хостинге.
Зря вы так батенька ;) Хостингов с .NET полно.
Цитата: RussianSpy
Давайте тогда подумаем над тем каким требованиям должна соответствовать такая библиотечка)) Кто что думает?
1) полный ООП
2) Поддержка парадигмы MVC
Барабанная дробь, получаем клон Ruby on Rails/JSP/ASP.NET :D
Тем не менее их значительно меньше чем хостингов с Perl или РНР. Или вы предлагает выбирать заказчиков по принципу наличия у них относительно редкой веб-платформы?
Обычно ведь как бывает - заказчик имеет уже дизайн, ТЗ и хостинг (либо выделенный сервер). Попытка же смены ключевой технологии - это дополнительные издержки, а значит повышение конечной стоимости проекта и увеличение сроков.
Для особых случаев и отдельных конретных проектов иногда .NET имеет смысл. Но как технология для разработки фреймворка или библиотеки для обширного использования в вебе - не катит никак. И дело тут вовсе не в наличии "передового опыта" или отсталости той или иной технологиии - каждая имеет свои достоинства и недостатки (.NET, PHP, Perl, Ruby - да и все что создано человеком).
Еще раз повторюсь - у РНР и Perl есть одно неоспоримое и железобетонное преимущество - распространненость (точно такое же как у Windows хотя с технической точки зрения она отстает от передовых технологий почти на 10 лет и имеет огромные недостатки).
Посему приемлемы только РНР, Perl и Python. Все остальное встречается гораздо реже (.NET, JSP, Ruby) либо почти не встречается вовсе (ColdFusion).
Но самое главное!! Мы обсуждаем здесь не технологии, а идеи. Надеюсь, что остальные участники не будут впрягаться в нашу с hardcase беседу на грани холивара.
Идеи и предложения, господа!
Обычно ведь как бывает - заказчик имеет уже дизайн, ТЗ и хостинг (либо выделенный сервер). Попытка же смены ключевой технологии - это дополнительные издержки, а значит повышение конечной стоимости проекта и увеличение сроков.
Для особых случаев и отдельных конретных проектов иногда .NET имеет смысл. Но как технология для разработки фреймворка или библиотеки для обширного использования в вебе - не катит никак. И дело тут вовсе не в наличии "передового опыта" или отсталости той или иной технологиии - каждая имеет свои достоинства и недостатки (.NET, PHP, Perl, Ruby - да и все что создано человеком).
Еще раз повторюсь - у РНР и Perl есть одно неоспоримое и железобетонное преимущество - распространненость (точно такое же как у Windows хотя с технической точки зрения она отстает от передовых технологий почти на 10 лет и имеет огромные недостатки).
Посему приемлемы только РНР, Perl и Python. Все остальное встречается гораздо реже (.NET, JSP, Ruby) либо почти не встречается вовсе (ColdFusion).
Но самое главное!! Мы обсуждаем здесь не технологии, а идеи. Надеюсь, что остальные участники не будут впрягаться в нашу с hardcase беседу на грани холивара.
Идеи и предложения, господа!
Что-то ни кто не вспоминает ZendFramework с его Zend_Form. А ведь тут тебе и валидация, и вывод ошибок и отрисовка...
В большинстве случаев мне хватает CakePHP и консольного скрипта bake.php, который поставляется с ним в пакете. Немного усовершенствованные правила валидации полей, хотя, и в этом я не пионер improved-advance-validation-with-parameters.
В простых случаях, как было выше, - вручную пишу HTML + PHP.
В тяжелых - даю заказчику генератор форм (JS+HTML+PHP+MySQL). ИМХО - пусть лучше заказчик выучит пару регулярных выражений, чем будет ежедневно иметь мой мозг.
В простых случаях, как было выше, - вручную пишу HTML + PHP.
В тяжелых - даю заказчику генератор форм (JS+HTML+PHP+MySQL). ИМХО - пусть лучше заказчик выучит пару регулярных выражений, чем будет ежедневно иметь мой мозг.
Цитата: AGRONOM
ИМХО - пусть лучше заказчик выучит пару регулярных выражений, чем будет ежедневно иметь мой мозг.
Ну-ну... В 98% случаев заказчик с трудом пользуется своим собственным сайтом не то, что изменять скрипты.
Я могу вспомнить те времена, когда писал SQL запросы с помощью phpMyAdminа. Создать таблицу в нём проще простого. Конструирование таблиц с помощью phpMyAdmin не тянет на "изменение скриптов", чтобы там ни говорили фанаты мышекликательного программирования.
Ну и возможно, мне повезло с заказчиком (он оказался из тех 2%) и согласился создать все формы сам с помощью конструктора a la phpMyAdmin, вместо того чтобы подрорбно изложить свои требования к ним в документе MS Word.
Ну и возможно, мне повезло с заказчиком (он оказался из тех 2%) и согласился создать все формы сам с помощью конструктора a la phpMyAdmin, вместо того чтобы подрорбно изложить свои требования к ним в документе MS Word.
В моем лично случае запросы приходится писать кросс-СУБД поэтому автоматическое генерирование:
1) Тупо тк проще и быстрее написать руками
2) Не будет кросс-СУБД
К тому же мы говорим несколько о другом, чем о визуальном конструкторе форм
1) Тупо тк проще и быстрее написать руками
2) Не будет кросс-СУБД
К тому же мы говорим несколько о другом, чем о визуальном конструкторе форм
RussianSpy, корсс-СУБД - замечательная вещь.
Однако, я привёл phpMyAdmin не имея в виду сочинение корсс-СУБД запросов, а как пример интерфейса понятного опытному пользователю веб-браузера.
И так как мы вводили в phpMyAdmin: имя поля, тип (из списка), значение по умолчанию и т.д.
в конструкторе форм можо написать: имя поля, имя переменной, html-тэг (input:text, input:radio, textarea и т.д.), набор значений (для select и radio) и рег-выражение для проверки введёных данных (е-mail, телефон, ИНН...) + надо вывести подсказку в случае неправильного заполнения поля (введите телефон - 10 цифр без пробелов).
Это решение, как и многие другие, приведеённые здесь, решает проблему создания пользовательского интерфейса не во всех случаях. К "тяжелым" случаям я бы отнёс 10++ форм с ~50 полей в каждой, хотя дело не только в числе но и в неопределённости, в которой находится заказчик относительно точного состава каждой формы.
Со слов заказчика:
придётся писать например ^\d+$. Но при создании больших форм, такой подход экономит время.
Однако, я привёл phpMyAdmin не имея в виду сочинение корсс-СУБД запросов, а как пример интерфейса понятного опытному пользователю веб-браузера.
И так как мы вводили в phpMyAdmin: имя поля, тип (из списка), значение по умолчанию и т.д.
в конструкторе форм можо написать: имя поля, имя переменной, html-тэг (input:text, input:radio, textarea и т.д.), набор значений (для select и radio) и рег-выражение для проверки введёных данных (е-mail, телефон, ИНН...) + надо вывести подсказку в случае неправильного заполнения поля (введите телефон - 10 цифр без пробелов).
Это решение, как и многие другие, приведеённые здесь, решает проблему создания пользовательского интерфейса не во всех случаях. К "тяжелым" случаям я бы отнёс 10++ форм с ~50 полей в каждой, хотя дело не только в числе но и в неопределённости, в которой находится заказчик относительно точного состава каждой формы.
Со слов заказчика:
Цитата:
Мы оказываем юридические услуги, но в ближайшее время будем оказывать и бухгалтерские, а потом будем устанавливать 1C и SAP
Флаг, как говорится в руки. Более того, есть ИМХО, что yandex.market или другой магазин с большим асортиментом (nix.ru) не просит программистов создать в БД новую таблицу и формы для неё, при добавлении нового типа товара.
Автоматизированное создание пользовательского интерфейса несомненно ограниченичивает нашу свободу в средствах валидации данных, возможно, в наборе html-элементов, стилях и в чём-то ещё. Вместо
Код:
if (is_int($_POST['var'])) { ... }
Цитата:
К тому же мы говорим несколько о другом, чем о визуальном конструкторе форм
Визуальный конструктов форм является одним из аспектов создания пользовательских интерфейсов (наряду с генерацией из .ini файлов, ORM объектов и php помощниками, заменяющими html), который не был раскрыт в этой теме. Если нет - прошу прощенья за оффтопик.
Визуальный редактор форм самый настоящий оффтопик. Мы тут обсуждаем библиотеку или фреймворк для облегчения жизни разработчика.
Цитата: RussianSpy
Визуальный редактор форм самый настоящий оффтопик. Мы тут обсуждаем библиотеку или фреймворк для облегчения жизни разработчика.
Из мелочных проектов никому это нафик не нужно + затрудняет понимание кода для следующих разрабов если будут (зы я до сих пор противник смарти), для крупных проектов никакой библиотеки не хватит - создавать формы самое что наверное есть плохое для программиста (не для кодера). В свое время пробовал писать классы, но даже написав - через- полгода забывал как они работают, а вспомнив видел что они неудачные и проще пройтись (хоть и влом) руками.
ЗЗЫ кто на гугл конференшн едет?