LINUX.ORG.RU

Подскажите CMSку моей мечты

 


12

9

Сразу скажу, не уверен, что такое вообще существует в природе, ибо требования у меня противоположны всему, что сейчас воспринимается как мейнстрим. В общем, нужна CMS для сайтов, которые заведомо _не_ относятся (и никогда не будут относиться) к категории «высоконагруженных». При этом имеются два совершенно категорических требования:

1) свободное распространение и использование без ограничений (в том числе без всяких обязательных ссылок и т.п.)

2) ничего тьюринг-полного на стороне клиента; JS, HTML5, CSS3 запрещены под страхом смертной казни, то есть если CMS генерит что-то из перечисленного, то она не рассматривается вообще, вот то есть даром не нужна; в идеале — генерит XHTML и использует мелкий CSS-файлик на десяток классов;

Кроме того, есть ещё несколько более мягких, но тоже существенных пожеланий:

3) Язык реализации. В идеале она вообще должна быть написана на C или C++ с использованием минимума (лучше — zero) внешних библиотек, но такого, скорее всего, не бывает. PHP я терпеть ещё готов, Perl с его системой библиотек и dependecny hell — уже с трудом, что касается Питона, Руби, Джавы и прочей экзотики — мне проще будет её самому написать. Или без сайта обойтись.

4) Хранилище. Идеальная с моей точки зрения CMS не использует никакие СУБД вообще от слова совсем, то есть даже SQLite. Для хранения всего и вся — обычные текстовые файлы в обычных директориях.

5) Кастомизация. Сменные темы, среди которых есть что-нибудь лёгкое и НЕ привязанное к конкретной ширине экрана.

При этом она должна обязательно поддерживать настраиваемую навигацию, блоки, появляющиеся на определённых страницах (на всех или на некоторых), а также пользовательские комментарии (крайне желательно, чтобы пользователи могли заходить со своими OpenID — да, я имел в виду именно OpenID, а не OAUTH).

Если кто видел что-то подобное, киньте ссылочку :-)

★★★

Ответ на: комментарий от hobbit

плюсую этот коммент.

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

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

что юзер в вебе - либо злонамеренный хакер, либо окончательный дебил

Есть более краткое выражение - «браузер в руках врага».

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

Нужно же как то разбавить стаю вебщиков, налетевших на ТСа со своими базуками. Реляционную СУБД им подавай для хранения статеек с комментами, умора. Если б только этим ограничивалось, но вы неизбежно тянете за ней весь свой говностек. Потом смотришь: убогий бложик ворочает мегабайты неведомого жабаскрипта, начинаешь понимать, что радикалы вроде Столярова не такие уж и неадекваты.

bread
()

1) Разумное требование

2) Я могу понять требование, чтобы сайт не ломался при отключенном JS, но если уж пользователь его включил, то что плохого в том, чтобы дать ему небольшие ништяки?

3) Серьезно? Php ок, python не ок? К твоему сведению, с помощью pip все зависимости ставятся одной командой. А про наборы костылей и нелогичностей в php есть тонны статей.

4) Файловые БД будут либо тормозить, либо являться кривой и глючной реализацией функционала существующих БД. Чем тебе sqlite не угодил? Не нужно никаких серверов настраивать.

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

bread

Реляционную СУБД им подавай для хранения статеек с комментами, умора.

Вы считаете нелогичным хранить данные в базе данных? У меня для вас плохие новости.

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

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

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

bread

С нормализацией, все чтоб четко.

С нормализацией чего? Комментариев? Да вы, батенька, наркоман.

bread

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

ORM - отличная штука, тот же Entity Framework мне очень нравится. Но я на C# пишу, эти ваши PHP я не знаю. JSON тоже хорош. Когда нельзя по тем или иным причинам перезагрузить страницу.

ravdinve
()

ТС молодец, прикидывается идиотом, а сам уже 700 тысяч русских денег донейшенами насобирал

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

JS запрещён под страхом смертной казни

Поясните, пожалуйста, ещё раз. Вы против использования JS в самой CMS (админке) или против JS в коде сайта? Просто если первое, то получается, что вы хотите набивать контент в текстовом поле, не используя WYSIWYG редактор?

digiport
()

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

crutch_master ★★★★★
()

ТС, без БД будет очень сложно. Я себе когда-то даже CGI-библиотечку написал (поддержка кук, запросов, передачи файлов и авторизации с использованием sqlite). Но потом как-то перешел на вебсокеты, и CGI пользоваться перестал.

Скоро, правда, нужно будет сделать сервер доступа к архивным снимкам. И вот там придется городить CGI (чтобы выкусить из БД данные по требующемуся фильтру, собрать изображения, заархивировать их в один тарбол и отправить юзверю). Там, видимо, и буду эту библиотечку править.

На счет же CMS — мне оно никогда не было нужно, к счастью. Задолбался бы свою писать...

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

Если бы мир был устроен правильно, то внешний вид (в смысле appearance) информации выбирал бы не хозяин сайта, а пользователь.

Удваиваю. Браузеры то еще дерьмо. Круто было бы, если с сервера передавались только необходимые данные, вместо каши с разметкой. А клиент бы уже сам думал, что с этими данными делать, как их показывать, что и когда отправлять назад. Есть, например, форум, а у него набор стандартных серверных функций, которые дёргай хоть через telnet.

crutch_master ★★★★★
()
Ответ на: JS запрещён под страхом смертной казни от digiport

Поясните, пожалуйста, ещё раз. Вы против использования JS в самой CMS (админке) или против JS в коде сайта?

Против исполнения левого кода на тачке клиента. Перечитай тред.

Просто если первое, то получается, что вы хотите набивать контент в текстовом поле, не используя WYSIWYG редактор?

Зачем нужен WYSIWYG редактор на JS?

crutch_master ★★★★★
()

ТС, а нафига тебе на 4 книжки аж 900тыр? Ты хочешь бешеным тиражом издать что ли?

Лучше бы собрал "на зарплату" тысяч 50, да написал и выложил в электронном виде!

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

Против исполнения левого кода на тачке клиента.

И это тоже неправильно. Как без жабоскрипта запросы посылать? Или сервер должен генерить веб-страницу каждый раз, как юзверю что-то нужно?

Как-то это неправильно.

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

С нормализацией чего? Комментариев? Да вы, батенька, наркоман.

О, неужели начало доходить где статейки с комментами и где реляционные БД. Микроскоп, гвозди, вот это все.

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

Как без жабоскрипта запросы посылать?

Ха-ха. Продолжаем наблюдения за незамутненными вебдванольщиками.

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

Лучше бы собрал «на зарплату» тысяч 50, да написал и выложил в электронном виде!

Он так и сделал, лол.

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

ТС прав насчёт БД. На небольших проектах она избыточна.

digiport
()
Ответ на: комментарий от crutch_master

Ну давай, пошли мне фоновый post-запрос без жабоскрипта! Или будешь со скрытыми iframe'ами извращаться и get-запросами?

anonymous
()

С такими требованиями - берешь bottle и пишешь сам.

Update: а, мсье готов терпеть пых, но не готов использовать Python. Ну тогда поищи что-то минималистичное на пыхе - там такого говна должно быть навалом.

Pinkbyte ★★★★★
()
Последнее исправление: Pinkbyte (всего исправлений: 1)
Ответ на: комментарий от crutch_master

Странный ты: да, пхытон говно. Но если сравнивать с пыхпыхом, то даже пхытон сойдет!

// но оба не нужны вообще в этом мире — это правда

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

Странный ты

Да это не я странный. Но хотя, да. Я тоже странный. На php ТС согласен потому, что он просто разворачивается на его серваке.

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

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

anonymous
()

1) свободное распространение и использование без ограничений (в том числе без всяких обязательных ссылок и т.п.)

Толсто. Не можешь в гугл.

2) ничего тьюринг-полного на стороне клиента; JS, HTML5, CSS3 запрещены под страхом смертной казни, то есть если CMS генерит что-то из перечисленного, то она не рассматривается вообще, вот то есть даром не нужна; в идеале — генерит XHTML и использует мелкий CSS-файлик на десяток классов;

2к17 на дворе, а ты хочешь 1998. Так уже не бывает, к сожалению.

3) Язык реализации. В идеале она вообще должна быть написана на C или C++ с использованием минимума (лучше — zero) внешних библиотек, но такого, скорее всего, не бывает. PHP я терпеть ещё готов, Perl с его системой библиотек и dependecny hell — уже с трудом, что касается Питона, Руби, Джавы и прочей экзотики — мне проще будет её самому написать.

Эта CMS-поделка не вылезает в Веб? Ты ж главное требование таки не описал! Оно вообще для кого (желательно еще — для чего?)?

4) Хранилище. Идеальная с моей точки зрения CMS не использует никакие СУБД вообще от слова совсем, то есть даже SQLite. Для хранения всего и вся — обычные текстовые файлы в обычных директориях.

WebSQL.

5) Кастомизация. Сменные темы, среди которых есть что-нибудь лёгкое и НЕ привязанное к конкретной ширине экрана.

Не делай так. Спасибо :) Ты не хочешь JS, а между тем responsive Web-design строится во многом на CSS, JS.

bookman900 ★★★★★
()
Последнее исправление: bookman900 (всего исправлений: 1)
Ответ на: комментарий от Stanson

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

Меня всегда забавляли кодеры, которые всегда думают, что они в таком ключе отлично знают аудиторию.

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

Да, вот еще что. Сайт работает крайне медленно, что странно. Ведь он крайне прост по своей структуре.

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

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

Меня гораздо больше волнуют те из посетителей моего сайта, у которых он откючён. Как, замечу, он выключен и у меня самого. Вообще у любого _здорового_ человека JS должен быть выключен, как и какие бы то ни было способы для приехавшего непойми откуда тьюринг-полного кода взять и выполниться.

Эх, напишите книжки про Эльбрус. Замечательно выйдут.

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

Там

Где?

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

WDWTFWW
()
Ответ на: комментарий от bread

с этим вот соглашусь на все сто.

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

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от Iron_Bug

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

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

Я когда-то давным-давно прикола ради микро-болталку и тестировалку на гольном баше сделал в компьютерном классе. Вполне себе работало...

anonymous
()

Очень интересно посмотреть на конечную реализацию данной идеи...

Venediktov
()
Ответ на: комментарий от Croco

Мне за поддержку сайта денег не платят, а жизнь, зараза, короткая. Я прекрасно знаю, что в SQL всё просто, но у меня есть существенно лучшие идеи, нежели тратить время и силы на SQL.

# Забираем посты с БД.
@posts = Post.all

# Отображаем посты
- @posts.each do |post|
  = post.content



Банальный пример на тех же рельсах.
Ни единого SQL не присутсвует, зато всё работает и никакого задротства с файлами.

Маргинальные задроты — это те, кто делают сайты с использованием JS и не знают слова «безопасность». Да, безусловно, это поголовно все, кто сейчас занимаются сайтостроением. А объяснение простое: человек, который может что-то ещё, сайтостроительством заниматься не станет, поэтому в области уЭбразработки остались одни идиоты.

Кандидату наук следует всё-таки знать определение слову «маргинал».

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

и что, это повод целый год мучить сервер и юзеров?

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

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 3)
Ответ на: комментарий от bread

Нужно же как то разбавить стаю вебщиков, налетевших на ТСа со своими базуками. Реляционную СУБД им подавай для хранения статеек с комментами, умора. Если б только этим ограничивалось, но вы неизбежно тянете за ней весь свой говностек. Потом смотришь: убогий бложик ворочает мегабайты неведомого жабаскрипта, начинаешь понимать, что радикалы вроде Столярова не такие уж и неадекваты.



Реляционная СУБД в связке с ORM позволяет сэкономить время. От слова совсем. Особенно если сравнивать работу с файлами.
Никто не заставляет тянуть весь стэк. Особенно js-стэк.

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

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

Сейчас тренд по витку идёт снова в утолщение клиента.
Поэтому куча js в браузере и мало кода в бэке: api, rest, json - вот это вот всё.

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

мучить сервер и юзеров

Чем они будут мучиться? Если лишнего говна (вроде jquery) не пихать, все будет ОК. Вот ЛОР противоречит идее нормального сайта — все через жопу сделано.

Помню я, как генерились странички без жабоскрипта. Сам этим когда-то занимался: средствами апача вполне можно кое-чего вытворять. Но это все черезжопно.

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

ЛОР как раз почти идеален. ничего лишнего. всё читабельно.

а современный веб отличается ещё и наплевательским отношением к юзеру. раньше была обязательна подстройка разметки сайта под клиента. и за несоблюдение серьёзно били по рукам. обязательным требованием было то, чтобы на каждом браузере (а тогда они были дико несовместимы меж собой), при каждом разрешении экрана (а минимальное было указано 640x480, хотя тогда уже ни у кого таких экранов не было) сайт должен был выглядеть нормально и плавно и красиво ресайзиться при изменении размера окна браузера. и это всё писали вручную, и в пыхе, и в разметке ставили if'ы и проверки. но это стоило труда и веб не был похож на соверменное УГ, когда заходишь на страницу и понимаешь, что её разработчику было насрать на то, как она будет выглядеть у конечного юзера. сейчас вебне вообще насрать на юзера и его мнение, на загрузку сервера и клиента. им важно только чтобы дешёвая вебмакака сделала сайт за неделю. и вся прелесть старого веба, кастомная подстройка и удобный интерфейс, похоже, канули в лету. поэтому я решила, что надо делать свой сервер и там базироваться. перенести туда и весь свой контент, и почту, и сорцконтроль. и вот я на досуге потихоньку занимаюсь неспецифическим для себя занятием: ковыряю веб. только не то говно, которое сейчас модно, а нормальные серьёзные реализации. я взяла сервер на ассемблере и CMS на C. и сервер на ассемблере отъедает 1 мегабайт (да, именно мегабайт!) памяти на сервере и работает быстро, как понос. вот это веб, а не какое-то макачье поделие.

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

сервер на ассемблере отъедает 1 мегабайт

где тебе удалось откопать сервер с 16 мегабайт ОЗУ?

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

Потому что это затраты времени на её развёртывание и администрирование.

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

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