LINUX.ORG.RU

новый веб-фреймверк


0

2

Здравствуйте, мы с моим коллегой разрабатываем новый веб-фреймверк. Он не будет зависеть от языка или сервера. Вот вам пример

<html><head><title>Заголовок</title></head>
<body>
<?python
import somemodule
result = somemodule.do()
print result
?>
<div>текст</div>
<?python
print 123
?>
</body></html>

Фреймверк не ограничен каким-то конкретным языком, вполне допустимы и такие конструкции:

<?perl
print "<table>",(map{("<tr><td>",$_,"</td><td>",$ENV{$_},"</td></tr>")}keys %ENV),"</table>";
?>

Фреймворк поддерживает не только интерпретируемые, но и компилируемые языки:

<?c

char str[]="Hello world";

char *upcase=malloc(sizeof(str));
int i=0;
for(;i<sizeof(str);i++){
upcase[i]=str[i]>='a' && str[i]<='z'?str[i]-'a'+'A':str[i];
}
puts(upcase);
free(upcase);

?>

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

http://plasmon.rghost.ru/47517081/image.png -> http://rghost.ru/47517085/image.png

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

принять участие в обсуждении и развитии проекта

Не нужно.

anonymous
()

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

thesis ★★★★★
()

Нужно! делайте

wxw ★★★★★
()
Ответ на: комментарий от thesis

Вообще, все не так плохо.

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

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

Обработка и валидация форм - на уровне Tornado всё делается в несколько строк, но мы же хотели бы и интеграцию на клиентскую сторону, с добавлением условий прямо на клиент, без дополнительных запросов на сервер.

Трансформация данных для подготовки в модель - с самого начала сделано в базовом виде, но ведь, к примеру, мы хотим богатые возможности разметки для текстовых полей, а email-поля должны проверять MX-запись домена, у хоста должна быть обратка и при этом надо делать тестовый rcpt to, дабы убедиться в валидности.

Конечно, что такое фреймверк - мы тоже не очень понимаем, но мы хотим делать сайты просто и быстро

nogaemz
() автор топика
Ответ на: комментарий от anonymous

причем тут php? О нем тут ни слова не сказано. Понимаете, писать на php - это очень долго, разработка небольшого раздела для сайта занимает очень много времени, никакой поддержки устройств, проверка форм должна быть реализована несколько раз, сначала на клиенте, потом на сервере, потом иногда еще в логике. А проблемы с базами данных? Я лично не знаю как с этим бороться. Надо что-то делать, что поможет создавать сайты быстро и легко. Я мечтаю, что мы сможем сделать такой фреймворк, который бы позволил нам написать всю логику, все шаблоны, все модели, все нужное в одном и НЕБОЛЬШОМ файле, после чего загрузить его на сайт и все бы работало, причем везде и качественно.

nogaemz
() автор топика
Ответ на: комментарий от trashymichael

ваше сообщение настолько полезное, что я не понимаю как вы нашли на него ваше драгоценное время

nogaemz
() автор топика

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

Suntechnic ★★★★★
()
Ответ на: комментарий от nogaemz

Ваше поделие позволяет смешивать html и логику. Большинство фреймворков, начиная от битрикс и заканчивая симфони, стараются от этого уйти хотя бы на организационном уровне. Есть даже те, которые пытаются сделать это на уровне архитектуры, типа MODx.

Этого уже достаточно чтобы закопать. Про остальное даже писать лень.

Suntechnic ★★★★★
()
Ответ на: комментарий от nogaemz

Это все очень хорошие буквы, но для самого начала я бы озаботился мыслью о том, каким образом этот «фреймворк» будет независимо от языка предоставлять пользователю типы данных.
Вот, например, простое домашнее задание: хочу класс HTTPResponse, чтобы одинаково радостно создавать, расширять и дергать его объекты из питона, пыха и С++.

thesis ★★★★★
()
Ответ на: комментарий от nogaemz

Ты вообще понимаешь, что за последние 3/4 века все прогрессивное человечество шло к разделению кода и данных, кода и представления и т.д., а ты с коллегой дергаешь работу с данными непосредственно из вида? Идеальный шаблонизатор - такой, который позволяет проставить в нужных местах имена переменных (ссылки на данные) (в редких случаях - правила их получения), но а об остальном заботится другое.

(исходники на си в шаблоне хтмл-страницы - этажы кокоита сумошесвие!11)

cdshines ★★★★★
()
Ответ на: комментарий от thesis

Вот, кстати, тебе и пример, ТС. О чем я выше писал. Вместо твоих кишков наружу в теле хтмл ты можешь просто сделать show(HTTPResponce(...)), а не городить все в одном месте.

cdshines ★★★★★
()
Ответ на: комментарий от nogaemz

писать на php - это очень долго

пятница в разгаре. Так и хочется поололокать.

rikardoac
()

код? в разметке?!
футакимбыть!!!111одинодин

aol ★★★★★
()
Ответ на: комментарий от nogaemz

Понимаете, писать на php - это очень долго, разработка небольшого раздела для сайта занимает очень много времени

Так-бы и сказал, что не осилил.

anonymous
()
Ответ на: комментарий от Suntechnic

Вы знаете, я бы с вами охотно согласился. Только сделал бы это лет 10 назад. Тогда я тоже стремился разделять все и вся, вот тут у меня 500 файлов-кусков шаблона по 20 байт, тут у меня пачка модулей из одного цикла, тут у меня портянка с геттерами-сеттерами. Все организованно, все красиво и... Совершенно неподдерживаемо. Другим людям тоже надоело нарезать шаблоны на тысячи мелких файлов, потому и умер в свое время SSI, а вместо него появились шаблонизаторы, где можно насоздавать кучу секций и дергать их из логики. Потому что проще править 1 файл, а не 500 мелких. И вот захотелось в шаблоне добавить лишнее поле, к примеру, аватарку вывести - это надо лезть в логику, надо лезть в базу за новым полем, надо-надо-надо кучу всего, и только потом мы можем поправить шаблон. Разве это нормально? Почему бы прямо здесь, не отходя от кассы, не выполнить запрос на аватарки, ведь они нужны именно в этом самом VIEW? Но нас заставляют размазывать этот код по множеству файлов. Не спорю, может быть в больших проектах, когда за каждый файл отвечает отдельный человек, это суровая необходимость, но когда одному тебе надо сделать простые аватарки - это явный переизбыток, проще все поправить в одном месте, нажать F5, убедиться что все нормально и закрыть задачу.

nogaemz
() автор топика

depo popova живет

anonymous
()

Боже мой, это просто тред радости. Пятница таки влияет на мозг человека.

Alve ★★★★★
()
Ответ на: комментарий от Suntechnic

начиная от битрикс и заканчивая симфони

xy*венький разброс. Однако, по-существу - всё ок.

helios ★★★★★
()
Ответ на: комментарий от helios

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

nogaemz
() автор топика

Какой ужас. Ну ладно на php можно одностраничник так написать, но пихать туда вызовы разных языков — извращение.

P.S. Две книги по MVC этому товарищу.

vurdalak ★★★★★
()
Ответ на: комментарий от anonymous

Хорошо, давайте поставим с вами мысленный эксперимент. Нужно реализовать простейший блог (вы ведь понимаете, что модель блога подходит как для интернет-магазина, так и для истории болезни?). Все просто, календарь с записями блога, выборки по тегам и облаку тегов, сами записи. Сколько у вас это займет кода? Сколько вы потратите на это времени? И как долго вы это будете допиливать, когда вдруг комментарии захотите разбить на страницы, подгрузку новых постов надо будет реализовать через AJAX по мере скроллинга, а в календарь надо будет вывести подсказку по популярным записям за эти дни? Я уже не говорю, что php - это сугубо серверная технология, которая в принципе не предназначена для клиента (проекты вроде php-gtk в расчет не берем), т.е. одну логику, к примеру валидации, надо будет сначала писать на клиенте, а потом и на сервере, а дублирование кода - это путь к ошибкам и трудноотлавливаемым багам. Если же мы еще захотим поддерживать пару-тройку версий сайта для андроида, айпада и телефона Siemens, то работа с сайтом превратится в ад, поэтому такие вещи могут себе позволить только крупные корпорации. В результате написание такого блога может длится годами, и так ничего хорошего написано и не будет.

nogaemz
() автор топика
Ответ на: комментарий от vurdalak

Собственно, код выше - это и есть View, остальное пока не очень понятно как реализовывать, есть только наброски из серии «худшего случая», а хотелось бы лучше

nogaemz
() автор топика
Ответ на: комментарий от nogaemz

Вебсервер у нас не в отдельном процессе

Ой, а вот на этом месте по-подробнее. Что у вас (команды): треды/хитрая_vm/событийно-ориентированный_комбайн?

Исключение - это вызов бинарных библиотек

Ищите glue.

Вы ведь даунскейлите картинки с помощью PIL, правда?

Не фанат пистонов, но, ежели приходится - да. Кстати, там тот же glue - аналог XS.

Или пишите разбор JFIF самостоятельно?

Хех, была такая лаба в универскую бытность.

Код/схемы/доки есть? Хочется _мяса_, а не десертов.

# Извините за такой сволочной угол зрения, однако, мне сейчас так проще.
# Живите долго и процветайте!

helios ★★★★★
()
Последнее исправление: helios (всего исправлений: 1)

<?c
bl-bla-bla
?>

Можно Вас убить? Будет небольно.
Не ну я понимаю, еще ссылку на файл... Или что-то типо инклюда... Но писать исходник непосредственно в html файле - да ну вас нафиг.

comp00 ★★★★
()
Последнее исправление: comp00 (всего исправлений: 1)

Веб-фреймворки не нужны. PHP сам по себе вполне неплохой фреймворк.

enemysystems
()

Скорее бы каникулы закончились

skam
()
Ответ на: комментарий от nogaemz

Понимаете, писать на php - это очень долго, разработка небольшого раздела для сайта занимает очень много времени, никакой поддержки устройств.

4.2

проверка форм должна быть реализована несколько раз, сначала на клиенте, потом на сервере, потом иногда еще в логике

Обзаведись нужными классами (функциями), шаблонами файлов сайта.

А проблемы с базами данных?

Какие проблемы? SQLite проще простого. А третий итого проще, при полной функциональности.

все нужное в одном файле

Ты так говоришь, будто это что-то хорошее.

enemysystems
()
Ответ на: комментарий от helios

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

А JFIF я разбирал уже потом, когда со студенчеством было покончено, немного завидую современному поколению, у которого такие интересные задачки бывают в студенческой молодости.

nogaemz
() автор топика
Ответ на: комментарий от vurdalak

К сожалению, View - это не просто код, это МНОГО КОДА. К примеру, у меня есть 2 числа: А и Б - вывести их «как есть» зачастую уже недостаточно, надо вывести их сумму, разность, а то и историю по подобным записям с различной аналитикой и кучей разрезов. Если у нас не просто числа, а скажем гео-координаты, то тут чего только не бывает - от различных замеров расстояний, анализов движения, заканчивая всякими сторонними партнерочками по заказу билетов или тому подобной гадости. Сырые данные - это одно, а вот их представление - это такой ад и такая бесконечность, что можно годами лететь вниз головой и так и не достигнуть дна. Поэтому сложный код во View - это суровая необходимость. Да хотя бы покрасить результаты голосований разным цветом - уже логика (и не надо про XSLT)

nogaemz
() автор топика
Ответ на: комментарий от nogaemz

надо вывести их сумму, разность

Все это считается в контроллере, а не во вью.

а хотя бы покрасить результаты голосований разным цветом - уже логика (и не надо про XSLT)

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

vurdalak ★★★★★
()
Ответ на: комментарий от comp00

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

Если даже для CPU задача по переключению контекста невероятно дорога, то что говорить о человеке? Или вы любите переключать окошки редактора, выискивая нужный файл и сохраняя/восстанавливая контекст в своей голове? Лично мне это делать сложно

nogaemz
() автор топика
Ответ на: комментарий от nogaemz

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

Ты путаешь представление данных и расчеты. Сумма и разница чисел не имеет никакого отношения к представлению, это логика. Представление — это что в каком месте отображается и каким стилем.

vurdalak ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.