IDE для разработки веб-приложений

[Logo]

...
А в идею CGI-программирования на паскале, тем более на Lazarus я не верю,
...

Ах, как мне пару месяцев назад именно этого не хватало.

...
Да, есть какая-то библиотека на FreePascal для CGI-программирования, но... пока не дотягивает (по крайней мере недотягивала, когда я последний раз её видел...)
...

Так может ее подтянуть совместным трудом?

[Vadim]

Извиняюсь, если скажу что-то не то.
Вот здесь: http://mrhx.clan.su/ товарищ написал отличный генератор, который на основе визуального проектирования формы и компонентов на ней выдаёт готовый код на Паскале, Си, Бейсике... И, я так понял, нет никаких проблем сделать скрипт, чтобы выдавался исходник на ПХП.
Что скажете, господа глубокоуважаемые потрясатели основ ПХП?

[*vmr]

А в идею CGI-программирования на паскале, тем более на Lazarus я не верю, можно конечно, но зачем мучать себя заведомо неправильным выбором инструмента? Да, есть какая-то библиотека на FreePascal для CGI-программирования, но... пока не дотягивает (по крайней мере недотягивала, когда я последний раз её видел...)

Действительно, не вижу никаких преград для того чтобы подтянуть библиотеку

[ev]

я вообще не вижу проблем написания cgi на fpc
проблема только одна - компиляция под требуемую платформу

[Slavikk]

В Lazarus уже есть тип создаваемого проекта - cgi (консольный проект, но с панелью (при проектировании) для размещения невизуальных компонентов). Есть Powtils (CGI units and frameworks that make working with CGI) - оформите его в виде компонентов для Lazarus и будет счастье. После чего сделайте свою сборку Lazarus где будут лишь Ваши компоненты и получите - IDE для разработки веб-приложений.

[shade]

Вот здесь: http://mrhx.clan.su/ товарищ написал отличный генератор, который на основе визуального проектирования формы и компонентов на ней выдаёт готовый код на Паскале, Си, Бейсике... И, я так понял, нет никаких проблем сделать скрипт, чтобы выдавался исходник на ПХП.

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

Исходников нет, работает только под Windows...

я вообще не вижу проблем написания cgi на fpcпроблема только одна - компиляция под требуемую платформу

Проблема в том, что та же задача, на PHP решается в три раза быстрее чем на паскале. Для каждой задачи свои инструменты.

Есть Powtils (CGI units and frameworks that make working with CGI) - оформите его в виде компонентов для Lazarus и будет счастье.

Есть PHP и я уже счастлив

[ev]

Проблема в том, что та же задача, на PHP решается в три раза быстрее чем на паскале.

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

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

[Attid]

Нет, нет, и ещё раз НЕТ! Это не редактор страниц. Редакторов страниц полно и не один из тех, что я видел мне не понравился. Я не предлагаю делать ещё один визуальный редактор HTML - это игрушки для новичков или тех, кому трудно/лень врубиться в HTML/CSS. В данном случае, я хотел бы редактор "макетов", с помощью которого можно визуально расталять элементы (компоненты): тут таблица, там текстовый блок, там-то список-коннтейнер для блоков-комментариев. А конретный вид пусть опреляется некоторым небольшим набором шаблонов - скином. Поменял скин - расположение элементов (логическая структура страницы) осталась прежней, а раскраска, вид всяких-там рамочек, шрифтов, рюшечек и т.п. поменялись.

ну и если я в редактор страниц на народ ру вставлю "таблица, там текстовый блок, там-то список-коннтейнер для блоков-комментариев" и буду их растовлять это то и будет . только выход там сайчес хтмл, а надо будет php.

Вот если бы там был пример реализации блога, чата, гостевой книги или т.п. то был бы другой разговор.

http://www.qadram.com/vcl4php/index.php?ac=1900

Для проверки всех данных передаваемых пользователем используется обработчик форм. У него всего одна цель - проверить данные на "вшивость". В первую очередь это проверки безопасности, во вторую проверка корректности введеных пользователем данных.

http://dklab.ru/lib/HTML_MetaForm/

[galex]

Буквально на днях раскопал очень интересное поделие: http://www.morfik.com/. Причем в основе лежит иммено freepascal. Но честно говоря после пары часов теста бросил. Что мне не понравилось:
1. Не смог разобраться как прикрутить собственные скины (темплейты).
2. Не достаточно глубоко описанны компоненты и процесс их создания. (по крайней мере в той документации что я нашел)
3. Довольно дорого $995 на одного разработчика

С удовольствием перешел бы на что-то подобное даже в нормальных проэктах.

[shade]

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

На PHP кодю уже не первый год, использую обычный текстовый редактор (по началу AsmEdit - хороший редактор, жаль что разработчики не выпускают новых версий, а теперь Kate). Ни каких отладчиков, никаких zend studio и проблем с отладкой как-то не испытываю... хм, может мне просто везёт?..

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

Ответ в самом превом посте. Есть описание полей формы (читай Model), есть описание макета формы (читай View), есть аплет и обработчики событий (читай Controller), в сумме получаем пресловутый MVC (Model-View-Controller).

У меня нет идей по редактору макетов. Тут есть три решения. Один разработчиков на Шаманграде, в своей AT CMS использует генератор форм, т.е. по описанию подобного ini-файла он генерирует HTML-код формы. Просто удобно, но не гибко, нет возможности раставить элементы иначе, чем в виде линейного списка (который в большинстве случаев достаточен). Либо, как делаю на данный момент я - использовать макеты (шаблоны) форм. Третий вариант - промежуточный, который будет поддерживать обе возможности и генератор форм и макеты, подробнее обо всех трех читай тут:
http://forum.shamangrad.net/viewtopic.php?f=45&t=754

ну и если я в редактор страниц на народ ру вставлю "таблица, там текстовый блок, там-то список-коннтейнер для блоков-комментариев" и буду их растовлять это то и будет . только выход там сайчес хтмл, а надо будет php.

Есть ещё такая сущьность как скин/тема/оформление. То, о чем ты говоришь, просто редактор документа, типа как Word, что вижу, то и получаю. Другой подход TeX/LaTeX, описываешь логическую структуру, а конкреный вид (оформления таблиц, блоков, цитат и т.п.) определяется внешними модулями. Т.е. имеет место разделение содержания и внешнего вида.

http://www.qadram.com/vcl4php/index.php?ac=1900

Уже интереснее...

http://dklab.ru/lib/HTML_MetaForm/

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

=============================================

Очередная порция черновиков

Модульность

Delphi использует несколько очень хороших парадигм, что и сделало её столь популярной. Одной из таких парадигм является компонентный подход. Вместе со средой предоставляется некоторый набор стандартных компонентов, из которых как из кирпичиков можно строить новые приложения. Также в среде есть встроенные утилиты для создания новых компонентов. Благодаря этому сторонние разработчики могут создавать новые компоненты и тем самым расширять возможности среды.

Так же и в нашей среде будет использоваться модульный/компонентный подход. Компоненты могут быть самыми разными, от редактора бб-кодов, до модуля новостной ленты или блога. Модули/компоненты могут зависеть друг от друга, так например, модуль блога может использовать компонент редактора бб-кодов или визуальный редактор HTML-кода. Каждый компонент отвечает за свои задачи: если разработчик блога использует компонент редактора бб-кодов, то ему не нужно о том как он (редактор бб-кодов) работает и нужно только настроить пару его свойств.

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

Аплеты
Центральным элементом модульного подхода, в моём движке являеются аплеты (для тех, кто имел дело с cakePHP, это аналог контроллеров). Аплет отвечает за отображение страниц, обработку форм и действий пользователя. Так например, в PMS, за работу с новостями отвечает аплет news.php, за сообщения об ошибках - аплет report.php, за личные сообщения privmsgs.php. Они взаимно независимы: установка/удаление любого из них никак не влияет на работу остальных.

Примечание. Аплеты являются компонентами, но компоненты не ограничиваются одними аплетами. Упомянутый выше компонент редактирования бб-кодов не является аплетом, фактически это шаблон и небольшой JavaScript.

Если напрячь воображение, то аплет можно сравнить с формами/юнитами в Delphi. В Delphi каждая форма описывается двумя файлами: *.pas - юнит с кодом и *.dfm файл описания формы. В моем движке (WSCore) аналогично: *.php - php-скрипт аплета с кодом и *.frm, *.typ - файлы описания веб-форм, которые я описывал выше.

Delphi-разработчик создает форму, накидывает на неё компоненты, настраивает события и обработчики. Чтобы создать обработчик, нужно (в общем случае) выбрать в инспекторе объектов, вкладку "События", выбрать событие и сделать двойной щелчок на выбранным событии. В результате среда сама за разработчика добавляет в соответствующий юнит прототип функции-обработчика и разработчику нужно только написать тело. Это просто и удобно.

Аналогично можно сделать в WSCore. Разработчик создает аплет - среда создает за него по шаблону php-скрипт пустого аплета. Через специальную утилиту, назовем её "редактором аплетов", создает "страницы" и обработчики форм. Также по двойному клику по обработчику открывается редактор у соответствующей функции, если её нет, то создается заготовка.



Добавлено спустя 1 минуту 10 секунд:

Буквально на днях раскопал очень интересное поделие: http://www.morfik.com/. Причем в основе лежит иммено freepascal.

Качаю триал, посмотрим

Добавлено спустя 1 минуту 56 секунд:
Хм.. ссылки какие-то странные, интересно чем им классический UrlEncode не понравился:

http://www.morfik.com/#I(frmXappMain!!)I(Morfik%20Pioneers!frmXappMain%3ASubForm1!)I(frmGetWebOS!Morfik%20Pioneers%3AMainSubForm!)I(frmGetM2Express!frmGetWebOS%3ASubForm2!)I(frmGetM2WebOS!frmGetWebOS%3ASubform1!)I(frmMorfikBanner!Morfik%20Pioneers%3ASubForm1!)

Добавлено спустя 1 минуту 18 секунд:
Ааа, это якорь такой уродливый

Добавлено спустя 2 минуты 23 секунды:
Бббблин, System Requirements: M$ Windows
Ну ладно, винда так винда, но хотю под Linux

Добавлено спустя 14 минут 55 секунд:

http://dklab.ru/lib/HTML_MetaForm/

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

[GigoVich]

ПХП для меня это хлеб насущный, поэтому я так скажу - за всё время блуждания по инструментам разработки, программирования, копания, ковыряния, и тестирования в итоге я остался с голым vim-ом, подсветкой синтаксиса и парочкой нестандартных расширений для PHP, и абсолютным убеждением, что web-разработка это вечный компромисс, где универсальными решениями и не пахнет.... ((((

[Attid]

поделие: http://www.morfik.com/.
Что мне не понравилось:

больше всего растроило невозможность подключаться к существующим БД, только к созданным в самом морфике.

[shade]

SynEdit мягко говоря разочаровывает, его не любовью к кирилице и UTF8:



PS: С редактором в Lazarus у меня таже беда

Добавлено спустя 44 минуты 4 секунды:

http://www.morfik.com/

У меня нет слов, мне жаль тех 30 руб, что я потратил на скачивание сего "продукта", не говоря уже о том, чтобы что-то там покупать. На сколько я понял он весь сайт создает на JavaScript (зачем? для меня загадка), даже сам http://www.morfik.com/ с отключеными скриптами показывает дулю с маком. И я вообще не понял где там CGI...

[B4rr4cuda]

//Offtop
2shade
Закинь это в /usr/share/X11/locale/en_US.UTF-8 под именем XLC_LOCALE, должно помочь с кириллицей:

Код: Выделить всё

# $XFree86: xc/nls/XLC_LOCALE/en_US.UTF-8,v 1.2 2000/02/29 03:09:07 dawes Exp $
# XLocale Database Sample for en_US.UTF-8
#

#
# XLC_FONTSET category
#
XLC_FONTSET

on_demand_loading True

object_name generic

# fs0 class
fs0 {
charset {
name ISO10646-1
}
font {
primary ISO10646-1
}
}
# We leave the legacy encodings in for the moment, because we don't
# have that many ISO10646 fonts yet.
# fs1 class (7 bit ASCII)
fs1 {
charset {
name ISO8859-1:GL
}
font {
primary ISO8859-1:GL
vertical_rotate all
}
}
# fs2 class (ISO8859 families)
fs2 {
charset {
name ISO8859-1:GR
}
font {
primary ISO8859-1:GR
}
}
## fs3 class (Kanji)
#fs3 {
# charset {
# name JISX0208.1983-0:GL
# }
# font {
# primary JISX0208.1983-0:GL
# }
#}

## fs4 class (Korean Character)
#fs4 {
# charset {
# name KSC5601.1987-0:GL
# }
# font {
# primary KSC5601.1987-0:GL
# }
#}


## fs5 class (Chinese Han Character)
#fs5 {
# charset {
# name GB2312.1980-0:GL
# }
# font {
# primary GB2312.1980-0:GL
# }
#}


## fs6 class (Half Kana)
#fs6 {
# charset {
# name JISX0201.1976-0:GR
# }
# font {
# primary JISX0201.1976-0:GR
# vertical_rotate all
# }
#}

END XLC_FONTSET

#
# XLC_XLOCALE category
#
XLC_XLOCALE

encoding_name UTF-8
#mb_cur_max 6
mb_cur_max 2
state_depend_encoding False

# cs0 class
cs0 {
side GL:Default
length 1
ct_encoding ISO8859-1:GL
}

# cs1 class
cs1 {
side GR:Default
length 1
ct_encoding ISO8859-1:GR
}

# cs2 class
cs2 {
side GR
length 2
ct_encoding JISX0208.1983-0:GL; JISX0208.1983-0:GR; JISX0208.1983-1:GL; JISX0208.1983-1:GR

}

# cs3 class
cs3 {
side GL
length 2
ct_encoding KSC5601.1987-0:GL; KSC5601.1987-0:GR; KSC5601.1987-1:GL; KSC5601.1987-1:GR

}

# cs4 class
cs4 {
side GR
length 2
ct_encoding GB2312.1980-0:GL; GB2312.1980-0:GR
}

# cs5 class
cs5 {
side GR
length 1
ct_encoding JISX0201.1976-0:GR
}

# cs6 class
cs6 {
side none
ct_encoding ISO10646-1
}

END XLC_XLOCALE

[shade]

Закинь это в /usr/share/X11/locale/en_US.UTF-8 под именем XLC_LOCALE, должно помочь с кириллицей:

Офтоп, не офтоп, а проблема с SynEdit есть и её жалательно решить.
Хм... завтра проверю...
Но помоему это не выход. Остальные-то приложения нормально работают, помоему это баг SynEdit'а
И не понятно почему локаль en_US.UTF-8, когда у меня ru_RU.UTF-8:

Код: Выделить всё

alex@localhost:~> locale
LANG=ru_RU.UTF-8
LC_CTYPE="ru_RU.UTF-8"
LC_NUMERIC="ru_RU.UTF-8"
LC_TIME="ru_RU.UTF-8"
LC_COLLATE="ru_RU.UTF-8"
LC_MONETARY="ru_RU.UTF-8"
LC_MESSAGES="ru_RU.UTF-8"
LC_PAPER="ru_RU.UTF-8"
LC_NAME="ru_RU.UTF-8"
LC_ADDRESS="ru_RU.UTF-8"
LC_TELEPHONE="ru_RU.UTF-8"
LC_MEASUREMENT="ru_RU.UTF-8"
LC_IDENTIFICATION="ru_RU.UTF-8"
LC_ALL=
alex@localhost:~>