СЕО дружественная CMS

[valu0808]

boric, у меня cms тоже построена на объектной модели, рад что есть единомышленники.

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

В чем преимущество?
1. Для управления ЛЮБЫМ контентом, с ЛЮБОЙ структурой служит один и тот же модуль.
2. Гибкость на самом высоком уровне.
3. Расширяемость фактически безгранична.

boric, респект.

Добавлено через 9 минут

Сообщение от PlaDima

P.S. Сайт системки не встречайте "по одежке", сразу смотрите на ум..

Да, по одежке встречать там нечего, тут надо на сам продукт смотреть, еще раз спасибо.

[boric]

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

1. Для управления ЛЮБЫМ контентом, с ЛЮБОЙ структурой служит один и тот же модуль.

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

2. Гибкость на самом высоком уровне.

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

3. Расширяемость фактически безгранична.

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

[valu0808]

Сообщение от boric

Так зачем плодить лишние сущности?

Вот и я про тоже.

[Psihadelic]

Сообщение от valu0808

По второму пункту только не очень понятно.

Сообщение от valu0808

2) управлять тайтлом как я сам захочу

К примеру тайтл написан так: название сайта - каталог файлов - Антивирус касперского.
А я хочу так: Антивирус касперского - каталог файлов.

Добавлено через 2 минуты

Сообщение от valu0808

Вот спасибо, буквально список TODO получился. Больше всего идея с перелинковкой понравилась. Реализовать ее на самом деле не так уж и трудно.

Кстати его список не читал. Или о чем это...

Сообщение от LSN

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

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

Добавлено через 3 минуты
Ещё к своему списку добавлю:
В CMS должна быть реализована оптимизация картинок и ссылок:
1) Картинки. При добавлении картинки в альбом либо в статью нужно сделать так чтобы я мог прописать ей тайтл и ALT.
2) Ссылки. Понятно что ссылкам в тексте всё это прописать можно, но вот не у всех движков есть доступ к ссылкам из меню. Нужно сделать так, чтобы и в меню ссылкам можно было прописывать тайтл и альт.

[valu0808]

Сообщение от Psihadelic

Кстати его список не читал. Или о чем это...

To Do - "для выполнения" (англ.)

Сообщение от Psihadelic

К примеру тайтл написан так: название сайта - каталог файлов - Антивирус касперского.
А я хочу так: Антивирус касперского - каталог файлов.

Теперь понятно.

[Psihadelic]

А когда нам теперь ждать идеальную CMS ?))

[alex063]

p.s. Не в тему может быть - мучал недавно CMS Ufaweb'а, и правда нужно очень хорошее знание PHP, но почему-то, начал выставлять права на папки, вообще упала, установка тоже не помогла, снёс, нашёл СантФокс сейчас уже сайтик сверстал, довольно удобная, осталось пару "модулей" написать и усё)))

[Alexey]

Сообщение от valu0808

3. Расширяемость фактически безгранична.

Это хорошо до тех пор, пока в системе есть только вертикальные зависимости. Т.е. пока либо модули вообще не зависят друг от друга, общаясь только с ядром, либо зависят иерархично, например A->B->C.

Но такую связь красиво реализуют многие ЦМС. Ужас начинается, когда появляется зависимость горизонтальная.

Пример: есть компонент (контент-модуль/модуль/как он там у вас зовется) каталога товаров со своими табличками в БД, шаблонами и прочими сервисными вещами. И есть компонент видеогалереи, в которой тоже свои таблички в БД и шаблоны.

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

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

[boric]

Alexey

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

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

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

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

[Alexey]

boric, именно... Но проблемы мы получаем в обоих случаях.

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

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