Хочу свелосипедить цмс/фреймворк, подскажите марку велосипеда

Apache Jetty + JAX-RS.

Вот: http://www.restlet.org/documentation/2.0/tutorial
Обсуждение: http://www.theserverside.com/news/thread.tss?thread_id=38290
Что-то ещё: http://www.oreillynet.com/onjava/blog/2006/09/rest_for_java.html
И ещё: http://onjava.com/pub/a/onjava/2005/04/27/restweb.html

т.е. ты вот так за 10 секунд набросал мне пару кейвордов, дабы я потом 2 месяца решал, подходит ли оно мне?

Ну в общем случае идея моя, да, но коннекторов маловато, да и свойств у реквеста-респонса тоже. Ну и рест, в хорошем обществе (кроме веба) он нафиг не нужен. Но как точка отсчета штука неплохая, хотя я до конца и ниасилил.

Вот ты так взял и накидал функционал сайта как параметр веб-платформы.
На вскидку могу сказать - Grails. Сам сейчас вот изучаю. На вид - можно очень и очень многое. Гибкое. Большое. Много фич.

> Вот ты так взял и накидал функционал сайта как параметр веб-платформы.

Просто эти параметры автоматически отметают примерно 50% платформ, причем неглядя. И еще где-то 30% после рассмотрения.

Ключевая особенность - это отсутвие жеткой привязки к HTML/HTTP, в кастом-варианте веба вообще может не быть, будет, например, морда на qt и wap, а в таком виде все преимущества многих фреймворков просто рассыпятся.

На вскидку могу сказать - Grails. Сам сейчас вот изучаю.

Все указанное можно реализовать? Есть коннекторы к серверам, через которые можно ими управлять, например, скорость отдачи файлов?

На вид - можно очень и очень многое. Гибкое. Большое. Много фич.

О, да ты описал Perl! А если серьезно, то это можно прочитать о любом языке/платформе

>Ключевая особенность - это отсутвие жеткой привязки к HTML/HTTP, в кастом-варианте веба вообще может не быть, будет, например, морда на qt и wap, а в таком виде все преимущества многих фреймворков просто рассыпятся.

render as XML/JSON/ваш плагин, а его уже клиентом отображайте как хочется

Все указанное можно реализовать?

насчёт всего не скажу, но многое либо искаропки есть, либо реализуемо. Другое дело что grails всё-таки фреймворк, а не CMS, но есть, например, http://www.weceem.org на его основе

Есть коннекторы к серверам, через которые можно ими управлять, например, скорость отдачи файлов?

не очень понятно почему шейпингом должен заниматься application server, а не front-end, ведь передать в response header'е какой-нибудь X-download-speed-limit тому же nginx'у проще простого, не?

> render as XML/JSON/ваш плагин, а его уже клиентом отображайте как хочется

И как это поможет для транспортов, вроде email-интерфейса, где принцип «запрос-ответ» отсутствует полностью? Или будет предложено формировать 100500 текстовых документов и подкладывать их в спулер, дабы тот в течении суток их рассылал? Или так и надо (я действительно тут плохо ориентируюсь)?

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

Другое дело что grails всё-таки фреймворк, а не CMS, но есть, например, http://www.weceem.org на его основе

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

Пример: почти все системы роутинга завязаны на URI, т.е. от устаревшей концепции /blogs/food/2010-05-08/best-today/comments/page72.html уже не уйти. А ведь роутинг - это практически основная часть, средство адресации всего и вся, если его запороть, то что останется?

Еще пример: кеширование. Клиент запросил help.html, а система ему и выплюнула из кеша, не думая, наплевав на опции языка, скина, уровня доступа и прочие условия отображения. Такое будет легче выкинуть, чем прилизать, однако в статичной модели это должно работать идеально.

не очень понятно почему шейпингом должен заниматься application server, а не front-end, ведь передать в response header'е какой-нибудь X-download-speed-limit тому же nginx'у проще простого, не?

Ну я это и подразумевал, просто апликейшен-сервер должен иметь какие-то общие коннекторы, дабы рулить всеми, т.е. X-download-speed-limit должен быть известен слоям приложения

Я вообще думаю над протоколом общения между всеми участниками:

content_type: text/partial
content_encoding: utf8
template: default_skin
language: en_RU
age_control: 21+
speed_download: 16000
speed_upload: 16000
cache: forever
actual: Вск Фев 14 08:32:30 MSK 2010
private: true

и дабы это понимали все сервера. Получается довольно громоздко и я даже начинаю думать о «реестре» вроде /proc/

>Просто эти параметры автоматически отметают примерно 50%...
Не 50, а 100. Ибо ты отметаешь понятие «веб-фреймворк».

Вообще, ты вот говоришь - морда на кути. А какое оно имеет отношение к вебу? Никакого. Я думаю ты сам не знаешь что хочешь, просто хочешь чтобы был фреймворк, на котором можно всё и сразу, при этом, почему-то, ты зозотел чтобы его называли «веб-фреймоврком», что в корне не верно.
Нужна морда на Qt? Парси XML, JSON, что могут отдавать такие фреймворки. Нужно управление скачиванием файлов? Строй свой middleware на любом фреймворке.

Да и вообще,

Ключевая особенность - это отсутвие жеткой привязки к HTML/HTTP

Что курил? Веб-фреймворк, без привязки к HTML/HTTP? Пипец...
Ладно, HTML это язык разметки для отдачи контента. Оно не важно, можно XML, JSON или даже plain text - дело твоё, а вот HTTP - ты явно курнул что-то сильное.

Если хочется веб-фреймворк для отдачи любого контента в любом нужном тебе формате - проще всего Pylons. Там из действия контроллера возвращается тупо строка. Для рендеринга по темплейтом функция просто возвращает строчку, что как-бы говрит что можно делать что угодно.
Сам Pylons достаточно прост, по сему middleware пишутся там не сложно, но это пайтон, со всеми вытекающими.

Да вообще, давай пройдёмся по твоим вопросам и решим что ты хочеш:

От интернационализации хочу как минимум многоязычные версии документов, переведенные элементы форм и виджетов

Любая система интернационализации в вебе есть система перевода строк. Ты так описал, как-будто ты не хочешь вообще использовать html, а хочешь чтобы он сам генерился и был интернациональным. А так не получится.
Есть на C++ интересная фигня как ты, видимо, хочешь - Wt. Но это треш. Удобнее делать сразу HTML ручками, а точнее темплейты, в которых каждую строку обёртывать в вызов функции модуля интернационализации, которая вернёт нужный текст.
В пайтоне GNU-gettext и юзается. просто в темплейтах каждый текст для интернационализации обёртывают в вызов вроде:

_(«Hello!»)

Идея понятна?
Далее

Сайт не должен представлять собой несколько отдельных сайтов

Современные веб-фреймоврки(кроме php) давно отказались от идеи хранения тысяч скриптов для каждой страницы. Всё описывается логикой с MVC.

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

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

Кастомизация

Систем css-шаблонов просто тысячи.

возможность выбирать пагинацию страниц

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

ввести фильтры слов и контроля «вызывающего контента»

Да как хочешь. Задачи на 10 минут.

Ну и игнор, куда без него, только игнор настоящий

Игнор чего? Нет, я понимаю что игнор людей на форуме, но выше ты вообще ничего не написал про форумы.
Свой форум пишется не сложно, а игнор - вообще проще простого.
«Качество» игнора у тебя идёт из-за непонимания что такое и почему. Дело в том что во всяких медленных веб-фреймворках стараются сунуть побольше оптимизации методом кеширования страниц. Полностью. В общем, как сделаешь - так и будет. Да хоть вообще без кеша.

Добавление новых сервисов должно быть простым

Что за сервисы? Ты хоть представляешь что будет у тебя? Я думаю что нет. Нужна просто единая система авторизации и статистики? Ну юзай OpenID и гугл, или просто построй одно такое приложение, а в остальных ссылкайся на первое.

Если есть RSS (а он нужен), то он должен быть ВЕЗДЕ

Где захочешь там и делай. Это лёгкая задача. Хелперы есть в любом веб-фреймворке.

возможности по переносу ее на мобильные решения

Напиши нужные темплейты и все дела.

soap/xmpp-подобный интерфейс для j2me-приложений

Отдавай xml, какие проблемы?

выхлоп хтмл (или http, как джанга)

Не позорься. По твоему PHP выдаёт HTML, а джанго HTTP? Ты ебанулся, прости за выражение. HTTP это протокол передачи информации, а HTML - язык разметки. HTTP используется в вебе всегда. Иначе это не веб(спорно, но...). HTML же отдаётся как post-данные после HTTP-заголовка.
Блин, это не я должен говорить, а в школе должны были тебе вбить в голову.

а в виде obml-подобного бинарника для экономии трафика

Ну ты пипец. OBML мало кто поддерживает и никому оно не нужно. При том что экономия трафика минимальна.

Например, шейпинг скорости скачивания файлов

Как сделаешь - так и будет. Middleware можно написать везде. Правда хз как по сложности.

ИТОГ:
Ты хочешь ничего не делать, а чтобы всё было. Не получится.
Изучай веб, потом html, потом опять веб(чтобы дошло), потом веб-фреймоврки. Пиши что хочешь.
Вообще, всё что ты написал более похоже на «хотелку» для исполнителя. Вот готовь $$$ и заказывай. Только приготовь ещё $ чтобы из этого чуда сделали ТЗ...

> Не 50, а 100. Ибо ты отметаешь понятие «веб-фреймворк».

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

Вообще, ты вот говоришь - морда на кути. А какое оно имеет отношение к вебу? Никакого.

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

Нужна морда на Qt? Парси XML, JSON, что могут отдавать такие фреймворки.

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

Нужно управление скачиванием файлов? Строй свой middleware на любом фреймворке.

Ну и как ты это представляешь? Написание пачки серверов со своим унифицированным интерфейсом для этой самой миддлвари? Или что?

Что курил? Веб-фреймворк, без привязки к HTML/HTTP? Пипец...

Ладно, специально для тебя, еще раз: пусть будет не веб-фреймворк, пусть будет инфо-фреймворк с богатой веб-мордой.

а вот HTTP - ты явно курнул что-то сильное.

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

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

И чем это отличается от голого языка? Кто будет заботится о кешировании на всех уровнях, о уровнях доступа (правах)?

Любая система интернационализации в вебе есть система перевода строк. Ты так описал, как-будто ты не хочешь вообще использовать html, а хочешь чтобы он сам генерился и был интернациональным. А так не получится.

Смотри выше - html действительно может ВООБЩЕ не использоваться. Опять же, смотри на жуйку или мейл-листы. Ну покрайней мере до тех пор, пока не придет первый пользователь через веб.

Удобнее делать сразу HTML ручками, а точнее темплейты

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

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

это вроде бы назвали php

_(«Hello!»)
Идея понятна?

Я с интернационализацией знаком не первый день, равно как и с плюрал формс, равно как и с говносайтами, где половина на одном языке, а половина на другом. Особенно хорошо выглядят скины, где текст выполнен графически, оно почти нигде не работает нормально, да и в _(«Hello!») обернуть будет проблематично. Я хочу комплексное решение, а не набор костылей.

Современные веб-фреймоврки(кроме php) давно отказались от идеи хранения тысяч скриптов для каждой страницы. Всё описывается логикой с MVC.

Причем тут это? Тебя совсем не в тот лес потянуло. Я имел в виду, что весь твой красивый MVC можно просто и ТУПО скопировать в директорию рядом и отдать переводчикам, после чего она живет своей, независимой жизнью. Со всеми этими MVC, и никак уже не связана с родительской версией.

Переводишь их, добавляя в те-же файлы и компилишь их. Всё ок.

Про контекст не слышали, да? Что одна фраза может иметь 10 вариантов перевода тоже?

Систем css-шаблонов просто тысячи.

Кастомизация не заканчивается на css

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

А я еще раз повторю - хочу отдать весь контент сразу вебсерверу и пусть он с ним трахается, а вот изобретать свои пагинаторы я не хочу.

Игнор чего? Нет, я понимаю что игнор людей на форуме, но выше ты вообще ничего не написал про форумы.

Да чего угодно. Участников (они не только на форумах), групп, черный список слов (опять же парентал контрол), неинтересных событий/обсуждений. Даже целых разделов. Флаг «я не хочу этого видеть» можно прицепить куда угодно.

а игнор - вообще проще простого.

А вот если с кешированием, то мозги закипают.

Да хоть вообще без кеша.

И будет у меня 10 человек. Или надо будет по 300$/месяц за хостинг платить.

Что за сервисы? Ты хоть представляешь что будет у тебя? Я думаю что нет.

До конца - нет, ибо система должна развиваться и подстраиваться под текущие потребности. Захотели пользователи блекджек - нужно предоставить. Захотели список шлюх и обсуждения оных с предзаказами - тоже надо выполнить. И работать оно должно сразу везде - и в вебе, и в жаббере, и по рсс должны уведомления приходить.

Нужна просто единая система авторизации и статистики? Ну юзай OpenID и гугл, или просто построй одно такое приложение, а в остальных ссылкайся на первое.

а почему не LDAP тогда?

Отдавай xml, какие проблемы?

Дада, и каждый раз переизобретай ручками. Или копипаста, да?

Не позорься. По твоему PHP выдаёт HTML, а джанго HTTP?

толсто. Или слишком тупо.

Блин, это не я должен говорить, а в школе должны были тебе вбить в голову.

Видимо ты ее еще не закончил, раз так упорно мне это доказываешь.

Ну ты пипец. OBML мало кто поддерживает и никому оно не нужно. При том что экономия трафика минимальна.

Если я его вспомнил, то оно нужно как минимум мне. Сервисы надо делать для людей, а не «мало кому нужно», ибо «много кому» вообще ничего не нужно.

Как сделаешь - так и будет. Middleware можно написать везде. Правда хз как по сложности.

Ок, рецепт прикручивания мидлвари к апачу в студию.

Ты хочешь ничего не делать, а чтобы всё было. Не получится.

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

Изучай веб, потом html, потом опять веб(чтобы дошло), потом веб-фреймоврки. Пиши что хочешь.

мда...

Вообще, всё что ты написал более похоже на «хотелку» для исполнителя. Вот готовь $$$ и заказывай. Только приготовь ещё $ чтобы из этого чуда сделали ТЗ...

ну я какбэ и есть разработчик...

Да, аватарка у тебя говно, ничего личного.

1. Сервер приложений на основе запросов REST/Stateless (protocol: HTTP/1.0, port:80).
Почему?
a) Потому что протокол HTTP редко когда рубится на прокси-серверах.
б) «Stateless» — состояния соединений отслеживаются на прикладном уровне, а не на уровне протокола HTTP. Чтобы не зависеть от провайдеров, которые любят невовремя менять IP-адрес у клиентов.

2. Front-End может быть любым, способный прозрачно(!) транслировать в сервер приложений запросы от клиентов и перерабатывать/отдавать Web-контент по командам сервера приложений.

3. Клиентская часть — любая поддерживаемая — легковесная WAP/WML-страничка на мобильнике; J2ME-мидлет, способный посылать REST-запросы и принимать ответы; AJAX-реализация в браузере на десктопе; Gtk-, Flash- или Swing-UI для RIA-приложений.

PROFIT!

>Или так и надо (я действительно тут плохо ориентируюсь)?

другие варианты?

Я в картинке не просто так упомянул гофер-сервер и асечку, я хочу максимальной гибкости

с гофером не знаком, но GAE работает поверх XMPP без проблем по принципу запрос-ответ

Пример: почти все системы роутинга завязаны на URI, т.е. от устаревшей концепции /blogs/food/2010-05-08/best-today/comments/page72.html уже не уйти. А ведь роутинг - это практически основная часть, средство адресации всего и вся, если его запороть, то что останется?

а вам какой именно роутинг нужен?

Еще пример: кеширование. Клиент запросил help.html, а система ему и выплюнула из кеша, не думая, наплевав на опции языка, скина, уровня доступа и прочие условия отображения. Такое будет легче выкинуть, чем прилизать, однако в статичной модели это должно работать идеально.

в таком случае лучше кэшировать на уровне базы данных, не?

Ну я это и подразумевал, просто апликейшен-сервер должен иметь какие-то общие коннекторы, дабы рулить всеми, т.е. X-download-speed-limit должен быть известен слоям приложения

зачем нужен лишний слой абстракции (коннекторы), когда нужен всего лишь X-download-speed-limit, который известен nginx, ну или пара других вариантов для того чтобы поддержать ещё apache/lighty?

Ва-у. первый более-менее адекватный пост iZEN.

2ТС: перед велосипеденьем поучи матчасть. и главное не забывай принцип KISS.

> 1. Сервер приложений на основе запросов REST/Stateless (protocol: HTTP/1.0, port:80).

Странно, но допустим, реализуемо.

a) Потому что протокол HTTP редко когда рубится на прокси-серверах.

И смысл, если это сервер приложений? Перед ним все равно будут свои рендереры, а между ними ставить прокси нет смысла.

б) «Stateless» — состояния соединений отслеживаются на прикладном уровне, а не на уровне протокола HTTP. Чтобы не зависеть от провайдеров, которые любят невовремя менять IP-адрес у клиентов.

сессии никто не отменял, равно как и возможную привязку к IP/подсети

2. Front-End может быть любым

3. Клиентская часть — любая поддерживаемая

ты первый человек, который открыл мою картинку? Молодец, я удивлен

> другие варианты?

Имхо, директория спулера в качестве IPC - это несколько странно. И криво.

GAE работает поверх XMPP без проблем по принципу запрос-ответ

Я так мельком посмотрел и эта штука мне начинает нравится.

а вам какой именно роутинг нужен?

Я бы хотел адресовать как целые таблицы бд, так и некоторые отдельные выборки, элементы. В качестве решения напрашивается что-то sql-подобное, которое хешируется в уникальный код вида Di7Xm, и отдается юзеру. Ссылка из 5 символов может адресовать 39135393 уникальных адресов, мне этого хватит. Но вот как это к ORM прикручивать я не знаю. Да и какую ORM использовать я пока тоже не решил.

в таком случае лучше кэшировать на уровне базы данных, не?

Эффективность будет меньше. Кроме того, юзерагент транспорта известен, поэтому help может содержать информацию по конкретному браузеру/почтовику/мессенджеру пользователя, с уже локализованными скриншотами, без сотен «если вы пользуетесь оперой, то тыкните туда, а если ИЕ, то туда». Так поступает Яндекс. Вариантов согласования контента еще больше, кеширование еще сложнее (еще и поисковики клоакинг могут увидеть)

зачем нужен лишний слой абстракции (коннекторы), когда нужен всего лишь X-download-speed-limit, который известен nginx, ну или пара других вариантов для того чтобы поддержать ещё apache/lighty?

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

> перед велосипеденьем поучи матчасть

/r/ link

>В качестве решения напрашивается что-то sql-подобное, которое хешируется в уникальный код вида Di7Xm

и в чём тут проблемы с роутингом-то?

Эффективность будет меньше.

учитывая тот факт, что основная нагрузка - это БД, то потери минимальны

а как мне рулить FTP-сервером? Как мне сделать шейпинг для жабберной передачи файлов?

а много ли вы знаете фреймворков, в составе которых есть втч _кастомизуемые_ ftp и xmpp? как мне кажется, если вы хотите всё искаропки, то у вас вариантов-то немного..

http://ru.wikipedia.org/wiki/HTTP
http://ru.wikipedia.org/wiki/HTML
http://ru.wikipedia.org/wiki/Веб-фреймворк

Это так, чистый минимум.

> и в чём тут проблемы с роутингом-то?

т.е. я один вижу тут костыль? Но лучше ничего придумать не могу. Фактически роутинг будет представлять что-то вроде:
from TABLE1 where
from TABLE2 where TYPE=2
from TABLE2 where TYPE=2 and TAG=7

Система адресов это хорошая, но у нее есть жирный недостаток - непонятно какую ORM с ней использовать, да и надо будет еще табличку для родственных связей держать, что «from TABLE2 where TYPE=2 and TAG=7» - это родитель «from TABLE2 where TYPE=2 and TAG=52». Можно конечно просто взять и набыдлокодить все, но я хочу расширяемую систему, где в будущем появление вил будет минимальным.

а много ли вы знаете фреймворков, в составе которых есть втч _кастомизуемые_ ftp и xmpp? как мне кажется, если вы хотите всё искаропки, то у вас вариантов-то немного..

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

Первые 2 я изучил где-то 10 лет назад, а по поводу фреймворка ткну тебя же:

Каркас — в информационных системах структура программной системы; программное обеспечение, облегчающее разработку и объединение разных компонентов большого программного проекта. В его состав могут входить вспомогательные программы, библиотеки кода, язык сценариев и проч.

Является переводом [1](англ. framework — каркас[2], структура[2], сфера деятельности[3]), часто также бытует в техническом жаргоне[источник?] слово «фреймворк».

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

Отличается от библиотеки тем, что выполняет код, написанный для него, а не исполняется сам. Пример программного каркаса — CMF (Content Management Framework), а пример библиотеки — модуль электронной почты.

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

Ровно то, что мне и нужно

>Но лучше ничего придумать не могу. Фактически роутинг будет представлять что-то вроде:
интересно, я один не понимаю связи роутинга с SQL'ем или нет?

Неужели раньше таких интегрированных систем никто не делал?

видимо, всем хватало 2 фронтендов с разным шейпингов безо всяких извращений

> интересно, я один не понимаю связи роутинга с SQL'ем или нет?

Роутинг в фреймворках - это внутренняя система адресации, в моем случае адресации контента, диспетчеризации функций. А что может эффективнее всего указывать на объекты, списки объектов, части списков? Фактически каждый запрос - это выборка определенной информации с сервера, а SQL - уже готовый язык для подобных выборок.

если обычный роутинг транслируется примерно так:

/food/vegetables.html => select * from FOOD where cat=1
/food/meat.html => select * from FOOD where cat=2
/food/meat/soup.html => select * from FOOD where cat=2 and subcat=5

то зачем мне лишнее звено в этой цепи?

видимо, всем хватало 2 фронтендов с разным шейпингов безо всяких извращений

вот и я смотрю, что сайтов с полноценными вап-версиями можно по пальцам пересчитать, а на FTP/торрентах обычно надо вообще регаться отдельно

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

А ты уверен, что sql выборки всегда подойдут для адресации? А если у тебя поиск по сайту, и там вариантов запроса около нескольких миллионов?

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

> А ты уверен, что sql выборки всегда подойдут для адресации?

Практически всегда.

А если у тебя поиск по сайту, и там вариантов запроса около нескольких миллионов?

А это уже диспетчеризация внутренних приложений. Поиск - это уже не указатель «дай мне это», это уже полноценное приложение, которое вернет ссылки на контент. Эдакая хранимка, если говорить в терминах SQL. Посмотри картинку - там описан пример получения формы.

Или например постраничный вывод, где пользователь меняет количество данных на страницах?

Я думаю сделать так: ядро отдает рендереру полную версию «контента», он кладет его в _кеш_, рендерер уже преобразовывает этот контент в формат пригодный для дальнейшей транспортировки пользователю, например, в HTML, попутно рендерер может нарезать его как угодно, хоть по 1кб на 100 страниц, хоть на 1 странице все выдать. Ядро это не касается, оно и знать об этом не должно, а сам рендерер будет разбираться с пагинацией, т.е. часть запросов рендерер будет обслуживать самостоятельно.

Для таких случаев нужно предусматривать дополнительные параметры к sql запросу, а местами они в запрос имхо укладываться не будут.

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

>то зачем мне лишнее звено в этой цепи?

одна строка для мапинга всего - эти лишнее звено? 0_о
зы http://www.grails.org/URL%20mapping

>Я думаю сделать так: ядро отдает рендереру полную версию «контента», он кладет его в _кеш_, рендерер уже преобразовывает этот контент в формат пригодный для дальнейшей транспортировки пользователю, например, в HTML, попутно рендерер может нарезать его как угодно, хоть по 1кб на 100 страниц, хоть на 1 странице все выдать.

А если контента очень много, и вытягивать его постранично в адекватное время можно только ограничивающим запросом в БД?

Плюс для очень хитро работающих с БД приложений рендерер будет гораздо более сложен, чем работа с БД, т.е. привязка к БД вообще получается не главное. Стоит ли на неё так сильно завязываться тогда?

А кстати что будет в случае, когда для отображения одной страницы нужно сделать например 2 разных запроса в БД? Тогда однозначно адресация не привязывается к БД.

наиболее универсальный MVC framework который мне встречался - catalyst framework

> зы http://www.grails.org/URL%20mapping

class MyUrlMappings {
static mappings = {
«/product/$id» {
controller = «product»
action = «show»
}

«/$blog/$year/$month/$id» {
controller = «blog»
action = «show»
constraints {
year(matches:/d{4}/)
month(matches:/d{2}/)
}
}
}
}


Позвольте, а если за это не убивать, то за что тогда убивать? Поясню:

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

2. представте, что разрабатываемая система - мейллист. Будет удобно скидывать ей сообщения вида /$blog/$year/$month/$id? Или по жабберу наберать километровые ИД ресурсов? В этом плане я беру пример с жуйки

3. сама избыточность. Ну к чему мне /$blog/$year/$month/$id, если достаточно RecordID?

> А если контента очень много, и вытягивать его постранично в адекватное время можно только ограничивающим запросом в БД?

Я об этом тоже думал. Тут варианта 2 - или делать предварительный выбор и сразу класть в кеш, или, если контент особенно динамичный, оформлять в виде «хранимок», как и в случае с поиском.

Вообще есть такая мечта, но даже идей нету по ее реализации - это фоновые функции. Например, какие-то ресурсоемкие задачи. К примеру: юзер заливает видео, которое надо как-то процессить. Файл доливается на сервер, стартует ffmpeg/mencoder и молча все процессит. В едином потоке, код даже не знает, что есть какая-то вебморда. Вебморда же сразу говорит «во, началось, абажди» и может рисовать красивые прогрессбары, процессить другие запросы и т.д. Кончились ресурсы на процессинг? А не беда, поставим в очередь, через часик запустится. Сервак вообще ддосят и нету ресурсов даже для отправки комментов? А не беда, запросы просто складываем в очередь, а потом в оффлайне процессим, по мере сил, при этом морда (фронтэнд) все еще позволяет смотреть, так как у нее свой кеш, а она сама может быть даже на другом сервере. Но это только идея, я пока ее забросил.

Плюс для очень хитро работающих с БД приложений рендерер будет гораздо более сложен, чем работа с БД, т.е. привязка к БД вообще получается не главное. Стоит ли на неё так сильно завязываться тогда?

Ну я и не привязываюсь, я просто хочу адресовать контент везде и максимально просто+эффективно.

А кстати что будет в случае, когда для отображения одной страницы нужно сделать например 2 разных запроса в БД? Тогда однозначно адресация не привязывается к БД.

Легко. Посмотри на картинку - рендерер отвечает за финальное отображение страницы, в том числе за ее шаблон, скин, язык пользователя и т.д, эдакий Декоратор. Если рендерер посчитает, что страничку надо украсить еще чем-то (комментарии, релейтед-лист, облако тегов, рекламу), то он просто запросит у ядра еще один ресурс, после чего просто заинклюдит в страницу и выдаст в одном ответе.

о, оно еще и на перле, надо будет потестить, спасибо

>1. а если я захочу еще 1 раздельчик быстро задеплоить
что такое «задеплоить раздельчик»?

2,3

это всё кастомизуемо. ничего не мешает написать

«/$recordId» {
controller = «record»
action = «show»
}

(ну или «/$recordId»(controller: «record», action: «show»), что аналогично)


а внутри RecordController.show() доставать params.recordId

Фреймворк != веб-фреймворк. Просто в русской вики не сделали страницу.
Хочется ответить на твой ответ на мой пост выше, но лень. Что я тебе могу сказать?
Тебе нужен сервер приложений(любых) + форум с хорошим игнором как child сервера приложений.
Однако, ты говоришь:

Ровно то, что мне и нужно

Тогда я тебе могу сказать одно - бери джаву или пайтон и пиши. Это тоже фреймворки. Не веб-фреймворки, как ты и хочешь, на них можно сделать всё, как ты и хочешь.

>Вообще есть такая мечта, но даже идей нету по ее реализации - это фоновые функции. Например, какие-то ресурсоемкие задачи. К примеру: юзер заливает видео, которое надо как-то процессить. Файл доливается на сервер, стартует ffmpeg/mencoder и молча все процессит. В едином потоке, код даже не знает, что есть какая-то вебморда. Вебморда же сразу говорит «во, началось, абажди» и может рисовать красивые прогрессбары, процессить другие запросы и т.д. Кончились ресурсы на процессинг? А не беда, поставим в очередь, через часик запустится. Сервак вообще ддосят и нету ресурсов даже для отправки комментов? А не беда, запросы просто складываем в очередь, а потом в оффлайне процессим, по мере сил, при этом морда (фронтэнд) все еще позволяет смотреть, так как у нее свой кеш, а она сама может быть даже на другом сервере. Но это только идея, я пока ее забросил.

Ну тут можно реализовать кучей способов. Например юниксвейный - два приложения, одно занимается тем, что собирает каким-либо образом информацию о нагрузке, а второе занимается конкретной работой, но периодически опрашивает первое приложение на предмет состояния системы, и выбирает правильный метод работы. Даже наверное можно сделать универсально ядро, аналогичное прогам, меняющим частоту процессора от нагрузки (по смыслу), которое будет в зависимости от текущего состояния системы выбирать правила для работы подпрограмм (конвертация видео, чистка БД, итд). А между всем этим счастьем и веб-мордой организовать общение - хоть через БД и чтение по крону, хоть через модные сейчас приложения для работы с очередями (stompserver итд). Или форкать процесс прям из веб-морды, но тут надо смотреть на тему того, как работает вебсервер, позволит ли оно сильно извращаться. В общем можно далеко зайти:)

> а внутри RecordController.show() доставать params.recordId

Ну и смысл тогда какой вообще? Зачем оно?

что такое «задеплоить раздельчик»?

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

> форум с хорошим игнором как child сервера приложений

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

Java как фреймворк? Сильно конечно...

>Ну и смысл тогда какой вообще? Зачем оно?

что - оно? одна строчка маппинга?

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

и? в маппинге максимум одну строчку дописать нужно, если он сильно кастомный.

> В общем можно далеко зайти:)

Потому идею и отложил, слишком глубокая нора :)