LINUX.ORG.RU

подскажите cms по функционалу...

 


0

2

почти завершив свой проект начинают опускаться руки, и хочу поковырять что-то подобное, если такая cms существует.

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

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

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

★★★★★

любой фреймворк заюзай, на вкус и цвет.

lorovec
()

поковыряй sNews, проще я не находил

q11q11 ★★★★★
()

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

делим на

просто в поисках простого, но качественного в плане кода блога

Ну ты понял, да?

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

без ООП нельзя написать качественный код?

С ООП нельзя написать качественный код.

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

без ООП нельзя написать качественный код?

Качественный, для своей единственной задачи, можно (и то, не в случае с ТС). А вот нормальный масштабируемый проект - нет, нельзя.

VirRaa ★★★
()

Годы идут, а они все наступают на те же грабли и все так же уверены, что у них получится лучше всех.

Зачем делать базу на текстовых файлах? Назови одно преимущество, кроме «ничего другого не осилил»?

По сабжу - думаю найти такое будет тяжело, ибо никому не нужно такое.

lllnk
()

WolfCMS - проще уже не куда. Расширяется по желанию плагинами, код и API более менее нормальные. По крайней мере, какой-то намек на продуманную изначально архитектуру, а не чудовищная помесь ООП и процедурщины как в Wordpress, Drupal и прочих

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

Качественный, для своей единственной задачи, можно (и то, не в случае с ТС). А вот нормальный масштабируемый проект - нет, нельзя.

а как же быть с такими вещами, как eJabberd или CouchDB?

xpahos ★★★★★
()

Неправильный ход мыслей: я не знаю SQL -> делать базу на текстовых файлах Правильный ход мыслей: я не знаю SQL -> учить SQL -> делать базу данных

Yasenfire
()

даешь больше велосипедов-cms! их слишком мало, как плееров

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

WolfCMS

Фу. Опять не-инлайн администрирование?

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

А что с ними? Я без понятия.

ну есть такая вещь, называется функциональное программирование. Вполне себе нормально все работает без ООП.

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

а как же быть с такими вещами, как eJabberd или CouchDB?

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

ну есть такая вещь, называется функциональное программирование. Вполне себе нормально все работает без ООП.

В каком месте оно нормально работает? Не видел еще ни одного нормального веб-приложения, написанного на фукнциональном языке. Функциональщики даже приличного веб-фреймворка уже сколько лет родить не могут, получается только всякое убожество. Вообще ИМХО будущее за гибридным подходом с сильным уклоном в ООП...

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

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

Что значит мастабируемый код? Если ты про плагины для движка, вроде того, что сделано в LiveStreet(первое что вспомнил), то это как раз показатель того, как не нужно делать. Получается что класс расширяется в 3х местах и в большинстве случаев просто невозможно понять где что было изменено.

В каком месте оно нормально работает? Не видел еще ни одного нормального веб-приложения, написанного на фукнциональном языке. Функциональщики даже приличного веб-фреймворка уже сколько лет родить не могут, получается только всякое убожество. Вообще ИМХО будущее за гибридным подходом с сильным уклоном в ООП...

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

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

Что значит мастабируемый код?

Это код, который легко развивать и подстраивать под новые требования.

Если ты про плагины для движка, вроде того, что сделано в LiveStreet(первое что вспомнил), то это как раз показатель того, как не нужно делать. Получается что класс расширяется в 3х местах и в большинстве случаев просто невозможно понять где что было изменено.

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

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

Это код, который легко развивать и подстраивать под новые требования.

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

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

Нужно ограничить свободу использования ООП. php кодеры очень любят создавать классы даже без методов, а в половине еще и не больше 3х методов.

xpahos ★★★★★
()

долго думал над базой
делаю ее на текстовых файлах

Плохо думал.

если подскажете такой блог с использованием sql

Любой нормальный сайт/блог/форум. Этот например.

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

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

И давно ты программируешь? Еще не встречал ни одного активно занимающегося разработкой программиста с опытом хотя бы 2-3 года, который бы утверждал, что в общем случае процедурный код предпочтительнее объектно-ориентированного. ООП - это хороший способ разложить все по полочкам: есть такие-то сущности (классы) с таким-то поведением. От этого и читаемость, и гибкость кода только возрастают. А если ты не можешь сделать нормальную декомпозицию, то ты либо не умеешь проектировать объектно-ориентированные программы, либо просто не понимаешь задачу над которой работаешь и у тебя каша в голове.

Нужно ограничить свободу использования ООП.

Качество кода это никак не повысит. Те, кто писал ковнокод в объектно-ориентированной парадигме продолжат писать его и в любой другой.

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

И давно ты программируешь? Еще не встречал ни одного активно занимающегося разработкой программиста с опытом хотя бы 2-3 года, который бы утверждал, что в общем случае процедурный код предпочтительнее объектно-ориентированного. ООП - это хороший способ разложить все по полочкам: есть такие-то сущности (классы) с таким-то поведением. От этого и читаемость, и гибкость кода только возрастают. А если ты не можешь сделать нормальную декомпозицию, то ты либо не умеешь проектировать объектно-ориентированные программы, либо просто не понимаешь задачу над которой работаешь и у тебя каша в голове.

Дейкстра, Степанов, Вирт, остальных не помню. Декомпозиция и без ООП возможно. Пример с корявым использованием ООП выше я привел и люди не задумываются об его использовании.

В проектах, если это не использует Torrnado/Twisted/Pyramid/Django у меня получаются только функции, которые выполняют определенную задачу(например, получают URI и кладут в очередь параметры для WSGI приложения), а потом уже дальше используется другой скрипт, который эту очередь парсит. Все читаемо без ООП.

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

ООП — это ЧудоТренажёр-3000 Ультра, всего за $299!

anonymous
()

Typo3. Мощное, но не слишком простое.

unfo ★★★★★
()

почти завершив свой проект начинают опускаться руки

«Подъезжая к сией станцыи и глядя на природу в окно, у меня слетела шляпа. И. Ярмонкин».

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

Дейкстра, Степанов, Вирт

Пруфы будут? А то я сомневаюсь.

Декомпозиция и без ООП возможно.

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

Пример с корявым использованием ООП выше я привел и люди не задумываются об его использовании.

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

В проектах, если это не использует Torrnado/Twisted/Pyramid/Django у меня получаются только функции, которые выполняют определенную задачу(например, получают URI и кладут в очередь параметры для WSGI приложения), а потом уже дальше используется другой скрипт, который эту очередь парсит. Все читаемо без ООП.

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

Кстати, ты не задумывался, почему в основе всех перечисленных тобой фреймворков лежит ООП? Неужели их создатели настолько тупы, что в отличии от тебя не осознают явных преимуществ процедурщины перед ООП?

lech
()

man функционал vs функиональность

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

Если ты считаешь ООП панацеей то каша в твоей голове.

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

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

Кстати, ты не задумывался, почему в основе всех перечисленных тобой фреймворков лежит ООП? Неужели их создатели настолько тупы

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

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

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

Пруфы будут? А то я сомневаюсь.

Пока искал интервью Степанова, нашел тут в Вики http://en.wikipedia.org/wiki/Object-oriented_programming#Criticism :)

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

Про рефакторинг Степанов тоже не очень хорошо отзывался.

Кстати, ты не задумывался, почему в основе всех перечисленных тобой фреймворков лежит ООП? Неужели их создатели настолько тупы, что в отличии от тебя не осознают явных преимуществ процедурщины перед ООП?

Зачем задумываться? Если был бы готовый фреймворк вроде Pyramid на Си я бы его и использовал.

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

Пока искал интервью Степанова, нашел тут в Вики http://en.wikipedia.org/wiki/Object-oriented_programming#Criticism :)

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

Про рефакторинг Степанов тоже не очень хорошо отзывался.

А что он взамен предлагает делать с говнокодом? Бережно хранить и приумножать?

Зачем задумываться?

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

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

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

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

«Функционал» — это человек, которого «стёрли» из его привычной жизни и наделили определёнными сверхспособностями в пределах строго ограниченной площади, обычно не более 300—400 квадратных километров.

Поправлено.

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

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

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

Ты просил пруфов того, что без ООП можно обойтись. Плохо или хорошо тебе решать.

А что он взамен предлагает делать с говнокодом? Бережно хранить и приумножать?

«Я уверен, что ООП методологически неверна. Она начинает с построения классов. Это как если бы математики начинали бы с аксиом. Но реально никто не начинает с аксиом, все начинают с доказательств. Только когда найден набор подходящих доказательств, лишь тогда на этой основе выводится аксиома. Т.е. в математике вы заканчиваете аксиомой.

Тоже самое и с программированием: сначала вы должны начинать развивать алгоритмы, и только в конце этой работы приходите к тому, что вы в состоянии сформулировать четкие и непротиворечивые интерфейсы. Именно из-за этой неразберихи в ООП так популярен рефакторинг — из-за ущербности парадигмы вы просто обречены на переписывание программы, уже в тот самый момент, когда только задумали её спроектировать в ООП-стиле».

Ты видимо не прочел его слова про рефакторинг.

xpahos ★★★★★
()

Попробуй TinyMVC. Простейший фреймворк, с ЧПУ. регистрацию прикручивать будешь сам. Она там не предусмотрена. Зато предусмотрена работа с БД. Код очень простой. Почитай сырцы и крохотную доку, понравится.

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

Какой жирненький. Порублю тебя в мясной салат маленькими кусочками, и сделаю из тебя манты. ;)

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

Ты просил пруфов того, что без ООП можно обойтись.

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

Ты видимо не прочел его слова про рефакторинг.

Полным-полно программистов стоящих десяти твоих недоразвитых Степановых, поддерживающих ООП и не имеющих ничего против рефакторинга. Мартин Одерский, Алан Кей и т.д., их много. Ты выбрал себе плохого кумира.

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

Полным-полно программистов стоящих десяти твоих недоразвитых Степановых, поддерживающих ООП и не имеющих ничего против рефакторинга. Мартин Одерский, Алан Кей и т.д., их много. Ты выбрал себе плохого кумира.

лол, а ты случаем не на C++ пишешь? :)

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

Ты видимо не прочел его слова про рефакторинг.

Слишком утрировано. И не стоит путать математику и программирование. Мне кажется, он фанат ad-hoc кода, если он не может спроектировать интерфейсы перед написанием программы. Пусть прототипы пишет чтоли

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

Нет. Откуда такой странный вывод?

было бы забавно, если бы ты писал на C++ с STL, не зная кто его написал. В целом кумиров у меня нет, просто после прочтения пары книг по Java пришла мысль, что весь ООП это костыли и они мне не нужны. Да и про Дейкстру со Столлманом не слышал, чтобы они критиковали ООП до этого.

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

Слишком утрировано. И не стоит путать математику и программирование. Мне кажется, он фанат ad-hoc кода, если он не может спроектировать интерфейсы перед написанием программы. Пусть прототипы пишет чтоли

У меня тут наметились небольшие изменения, похоже времени не будет совсем скоро. Как освобожусь - попробую Clojure, расскажу тебе за кружечкой какао ;)

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

Про рефакторинг Степанов тоже не очень хорошо отзывался.

А чем известен в федо этот ваш Степанов? И что он предлагает вместо рефакторинга?

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

было бы забавно, если бы ты писал на C++ с STL, не зная кто его написал.

Дай угадаю, ты норкоман?

В целом кумиров у меня нет, просто после прочтения пары книг по Java пришла мысль, что весь ООП это костыли и они мне не нужны.

Нормального обоснования твоей мысли от тебя, конечно же, ждать не стоит?

Как освобожусь - попробую Clojure, расскажу тебе за кружечкой какао ;)

Удачи тебе с этим говном.

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

Дай угадаю, ты норкоман?

Почему наркоман? Все верно фазма сказал. Степанов для тебя никто, хотя он является автором STL, действительно было бы забавно, если бы ты писал на C++ c STL.

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

Нормального обоснования твоей мысли от тебя, конечно же, ждать не стоит?

Какой мысли? Что ООП это набор костылей?

Удачи тебе с этим говном.

Чем плох Clojure? CL я не использовал, а вот Scheme в примерах из SICP мне весьма понравился.

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