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

[shade]

Слабо повторить успех Delphi? написав среду для разботки веб-приложений на PHP.

Вот уже некоторое время зреет идея написать IDE для разработки веб-приложений. Что-то типа Delphi, но для PHP. По началу это может быть просто набор вспомогательных GUI-утилит, таких как редакторы форм, файлов локализации, макетов ("шаблонов") форм, а то и просто шаблонов.

1. Редактор форм
Формы у нас описываются в виде INI-файлов. Думаю нет ничего сложного, чтобы сделать GUI-утилиту которая будет помогать редактировать такие файлы. Так, например, если человек хорошо знает все возможности обработчика форм, названия поддерживаемых параметров, то он без труда сам редактирует эти файлы, но новичку придется некоторое время изучать различные параметры, запоминать их названия. А графический редактор позволит быстро освоиться буквально методом тыка.

2. Редактор файлов локализации
Здесь тоже самое - намного проще использовать простой графический интерфейс. К тому же такие редакторы уже есть и используются в других средах (сам не использовал, но парочку встречал).

3. Редактор макетов форм.
Довольно сложный модуль. Веб-форма состоит из набора компонент. Если простого линейного расположения компонент достаточно, то никакой редактор макетов и не нужен. С другой стороны, редактор макетов позволил бы настраивать произвольный вид форм, произвольное расположение компонентов. Тут может быть два случая. Либо редактируется макет для каждого скина. Либо используется некоторый набор "абстрактных" компонентов, внешний вид которых определяется шаблонами находящимися в скинах. Разработчик/дизайнер с помощью редактора форм задает расположения компонент, а их конкретный вид определяется шаблонами и CSS.

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

Далее список утилит может расшириться...

Первые два пункта достаточно просты я думаю с них можно начать. 3-й и 4-й достаточно сложны, но и более интересны.

Я думаю среда должна быть кросплатформной и работать как под Windows, так и под Linux. Поэтому желательно выбрать какой-нибудь кросплафтормый язык/среду: FreePascal/Lazarus, C++/QT, C++/GTK, FreePascal/GTK, PHP/GTK, PHP/QT и т.п. Ну и совсем бредовая идея, на случай если никто не захочет поддержать эту идею, - сделать среду с веб-интерфейсом По крайней мере первые два пункта достаточно просты, чтобы сделать в веб.

Короче кому интересно пишите, быть может соберем команду и попробуем.

Добавлено спустя 4 минуты 1 секунду:
PS:
Есть некоторые наботки движка, на нем сейчас работает http://shamangrad.net/
А идея написать собственно IDE к движку, у меня начала зреть относительно недавно.

[alexs]

Интересное дело
если бдет возможность - поучаствую

[ev]

написав среду для разботки веб-приложений на PHP.

наверное для?

Вот уже некоторое время зреет идея написать IDE для разработки веб-приложений.

чем будет отличаться от Zend Studio?
бесплатностью и наличием примочек типа редактора форм?

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

[Attid]

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

а Delphi для PHP, это немного больше, только то что есть сейчас в "DelphiForPHP" работает не очень кузяво и мне не понравилось и с птичкой не захотел работать =(


а примеры веб редакторов страниц в сети есть тот же народ ру.


в общем идея сделать рабочий гуи для vcl4php то мне нравится =)

[ev]

то что описанно это все же под конкретный движек.

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

в общем идея сделать рабочий гуи для vcl4php то мне нравится =)

что-то там даже скриншотов нет

[ViTality]

начал с идеи о ИДЕ а описал конфигуратор движка

[v-t-l]

Может пригодится: http://web.fastermac.net/~MacPgmr/PhpTk/PhpTkStatus.html

[Vadim]

А всё-таки, писать IDE надо на самом РНР или всё же на Паскале?

[Attid]

что-то там даже скриншотов нет

дык там веть иде нет только набор пхп файлов , пример можно или по ссылке ниже http://web.fastermac.net/~MacPgmr/PHP/hello.php

или на сайте кодбира там где реклама ДельфиФорПХП

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

А всё-таки, писать IDE надо на самом РНР или всё же на Паскале?

если писать на пхп, то как бы логичнее, типа иде пишется на своем vcl чтобы сразу видеть как оно работает =)

если отдельно, то тут нужно коопирировать программы яля как сделали в дельфине с ним ставится апач "c:\Program Files\CodeGear\Delphi for PHP\2.0\apache2" сам вцл "c:\Program Files\CodeGear\Delphi for PHP\2.0\vcl" ну и пхп "c:\Program Files\CodeGear\Delphi for PHP\2.0\php" и потом он уже шаманит между ними =)

хотя мысль про ИДЕ на самом vcl4php мне кажется интересной =) надо поискать может кто уже сделал =)

Добавлено спустя 8 минут 14 секунд:
а вот тут справочка по vcl4php

[Logo]

А на сколько успешен Delphi for PHP? Я знаю многих ребят, которые с большой надеждой ожидали этот продукт, а потом с большим разочарованием бросили его. Основной аргумент был, - "никакие средства для написания JavaScript", "просто лепилка".

У меня была идея написать визуальную среду для создания JavaScript приложений на стороне клиента, а на сервере использовать CGI, в нашем случае написаных на Lazarus , или дать возможность использовать по выбору серверную часть.

Сейчас стремительно подымают скорость обработки JavaScript и помойму время уделить этому особое внимание. Не плохо бало бы использовать опыт Delphi. Среда позволяет начинающим лепить из готовых компонет приличные приложения и для профи дает возможность писать эффективно с нуля новые компоненты, или сложные задачи.

[*vmr]

JavaScript это круто, но есть ли бесплатная и вменяемая ВиртМашина этого скрипта?

[Logo]

Я может чего не догоняю, но Google V8 JavaScript Engine, WebKit Open Source Project разве не то?

[shade]

наверное для?

Пишут на языке, а не для языка

чем будет отличаться от Zend Studio?бесплатностью и наличием примочек типа редактора форм?

Он мне не покарману, даже не видел. Хотя, вроде есть пробная версия, попробую скажу.

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

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

а примеры веб редакторов страниц в сети есть тот же народ ру.

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

можно например договориться о формате форм, языковых файлов и т.п.

В принципе договориться о формате можно. Я не думаю, что один отдельно взятый редактор форм будет хоть сколько-нибудь полезным. Я думаю, что в среде всё должно быть продумано и гармонично - множество инструментов, подчиных некоторой общей коцепции. Иструменты должны быть взаимосвязанны и дополнять друг друга. Взять тот же Delphi, кому нужен формат dfm (описание форм) без самого VCL? или предендующего на совместимость LCL.

хотя насколько я понял на форуме шаманграда этот процесс идет довольно трудно? у каждого своя цмс и все такое...

Туго ... А на счет того, что у каждого своя цмс,.. ну вы не правы, хотя бы в том, что нас много, а цмс всего две. Наши проекты сильно отличаются. Например, я уже давно бросил писать цмс, и PMS это совсем не цмс (по крайней мере в моем понимании). И на данный момент пишется только одна цмс. Если процесс диалога и обмен идей идет туго, то нужно искать тех, с кем он пойдет более гладко. Поэтому здесь и отписываюсь, тем более, что такому проекту нужны GUI-программисты, а у нас почти все Веб-программисты. Сам я уже сильно отвык программировать GUI, да если честно никогда особо и не хотелось.

начал с идеи о ИДЕ а описал конфигуратор движка

Справедливое замечание. ИДЕ за неделю не напишешь - это долгий путь и лучше его начать с чего-нибудь простого, что можно побыстрее начать и использовать, например с конфигуратора движка. Иначе рискуем увлечься, годами писать кучу кода и понять, что это никому не нужно.
Что должно быть в ИДЕ?
1. редактор кода
2. утилиты для разработки (то бишь конфигуратор)
3. библиотека функций/классов (то бишь движек)
Вместе это ИДЕ, а по отдельности это редактор, движек и конфигуратор.

дык там веть иде нет только набор пхп файлов , пример можно или по ссылке ниже m http://web.fastermac.net/~MacPgmr/PHP/hello.php

Это совсем не то о чем мечталось.
Честно говоря, из этого примера, для меня осталось загадкой причем тут PHP и веб-программирование. Ну окошко, ну в браузере... и что дальше? Вот если бы там был пример реализации блога, чата, гостевой книги или т.п. то был бы другой разговор.

А всё-таки, писать IDE надо на самом РНР или всё же на Паскале?

Пока не определись, список возможнных языков я приводил в первом посте. Движок на PHP, а ИДЕ лучше наверное на компилируемом языке. Сам я неравнодушен к Паскалю

У меня была идея написать визуальную среду для создания JavaScript приложений на стороне клиента, а на сервере использовать CGI, в нашем случае написаных на Lazarus , или дать возможность использовать по выбору серверную часть.Сейчас стремительно подымают скорость обработки JavaScript и помойму время уделить этому особое внимание. Не плохо бало бы использовать опыт Delphi. Среда позволяет начинающим лепить из готовых компонет приличные приложения и для профи дает возможность писать эффективно с нуля новые компоненты, или сложные задачи.

Да, я тоже думаю что этому нужно уделить особое внимание. Я не очень хорошо знаю JavaScript, поэтому могу предлагать только идеи как оптимизировать разработку на PHP. Если вы хорошо владеете JavaScript, у вас есть опыт, вы знаете проблемы, с которыми сталкивается JS-программист, и что самое главное, у вас есть идеи как решить эти проблемы, возможно нам стоит объединить усилия? Если в одной ИДЕ будет поддержка не только PHP, но JavaScript, то такая ИДЕ будет особенно сильной.

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

PS:
Я очень рад такому бурному отклику - видимо задел

[ev]

Пишут на языке, а не для языка

для языка тоже пишут
тот же zend studio - для php, а не на php

Я не предлагаю делать ещё один визуальный редактор HTML - это игрушки для новичков или тех, кому трудно/лень врубиться в HTML/CSS.

хороший визивиг-хтмл редактор довольно серьезный и нужный проект

[shade]

Редактор форм
Более формальное описание задачи.

Для проверки всех данных передаваемых пользователем используется обработчик форм. У него всего одна цель - проверить данные на "вшивость". В первую очередь это проверки безопасности, во вторую проверка корректности введеных пользователем данных. Данные не принимаются на дальнешую обработку, пока они не пройдут проверку корретности. Каждая форма характеризуется набором полей. Каждое поле имеет свой тип + на него могут накладываться дополнительные ограничения. Например, для типа integer (целое) можно указать мнимальное и максимальное значение. Если значение в поле не соотетствует ограничению, то пользователю выдается сообщение об ошибке, чтобы он мог исправить и попробовать снова.

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

Обработчик форм поддерживает несколько типов и для каждого типа определяет свой набор возможных ограничений. Рассмотрим наиболее часто используемые:

1. строка (string)
minlen - минимальная длина строки
maxlen - максимальная длина строки

2. целое и вещественное число (integer, float)
minval - минимальное значение
maxval - максимальное значение

3. загружаемый файл (file)
minsize - минимальный размер файла в байтах
maxsize - максимальный размер файла в байтах

4. загружаемый файл изображения (image)
minsize - минимальный размер файла в байтах
maxsize - максимальный размер файла в байтах
minwidth - минимальная ширина картинки в пикселях
minheight - минимальная высота картинки в пикселях
maxwidth - максимальная ширина картинки в пикселях
maxheight - масимальная высота картинки в пикселях

5. логический (bool)
не имеет ограничений

Пример файла описания полей:

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

[comment_id]
type = int

[comment_text]
type = string
minlen = 3
maxlen = 4000

[author_nick]
type = string
minlen = 3

[author_mail]
type = string
maxlen = 80

[author_url]
type = string
maxlen = 80


Описание формы не ограничивается одним файлом описания формы. Кроме собствено файла описания формы используются файлы локализации форм. В файле локализации форм прописываются названия полей и подписи к ним на национальных языках. В место использования файла локализации формы, можно в описании типов ввести поля title, subtitle, которые будут хранить идентификаторы языковых констант, тогда пример файла описания полей может выглядеть так:

Пример 1: файл описания типов полей.

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

[comment_id]
type = int

[comment_text]
type = string
minlen = 3
maxlen = 4000
title = FORM_TITLE_COMMENT
subtitle = FORM_SUBTITLE_COMMENT

[author_nick]
type = string
minlen = 3
title = FORM_TITLE_NICK
subtitle = FORM_SUBTITLE_NICK

[author_mail]
type = string
maxlen = 80
title = FORM_TITLE_MAIL
subtitle = FORM_SUBTITLE_MAIL

[author_url]
type = string
maxlen = 80
title = FORM_TITLE_HOMEPAGE
subtitle = FORM_SUBTITLE_HOMEPAGE


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

Пример 2: файл описания форм:

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

[post]
title = post_title
text = post_text

[editpost]
post_id = post_id
title = post_title
text = post_text

[droppost]
post_id = post_id

[postcomment]
author_nick = comments:author_nick
author_mail = comments:author_mail
author_url = comments:author_url
comment_text = comments:comment_text
post_id = post_id


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

Каждый модуль может водить свой набор форм и полей. И каждый модуль может ссылаться на поля объявленые другими модулями. Например, модуль Blog может использовать другой модуль Comments, в частности использовать его описание полей. В примере 2 видно, что в форме postcomment используются поля модуля Comments.

Файлы описания полей и форм всех используемых в проекте модулей складываются в одном каталоге. Файлы описания полей имеют расширение *.typ, а файлы описания форм расширение *.frm. Имя файла описания совпадает именем модуля преобразованным в нижний регистр.

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