Концепции современной CMS

antiportal · 18 Ноя 2004

Вот бы кто на русский перевел..

Я тоже над этим подумал, а потом испугался :cool:

2NetFly · 18 Ноя 2004

Читаю документацию по Typo3. Точнее, пытаюсь. Что-то они наворотили такого, что без 100 грамм не разберешься. СМ Библию закажу в бумажном варианте – с десктопа читать не люблю, а с КПК смотреть PDF документы неудобно.

Кстати, в вашей системе для работы с шаблонами использовали смарти, или что-то другое?

antiportal · 19 Ноя 2004

Что-то они наворотили такого, что без 100 грамм не разберешься.

Это точно ;-) Лучше просто почитать Bible...

Кстати, в вашей системе для работы с шаблонами использовали смарти, или что-то другое?

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

_RVK_ · 19 Ноя 2004

В таблице создавалось новое поле текстового типа, дополнительные поля сохранялись в ассоциативном массиве, кодировались и там сохранялись

А запросы типа ALTER TABLE... уже не модно? Как я понимаю, поля создаются раз и навсегда?

Вообще почитал я все это, и задумался, до каких же извр... сори... удивительных вещей можно додуматься под влиянием лени. Например логика вывода данных в шаблоне. Зачем тогда шаблон нужен? Почему бы не отказаться от ненужной прокладки в виде движка, и не использовать возможность PHP чередовать HTML и PHP код?
Вообще, это болезнь всех CMS, стремление к универсализации зачастую пораждают достаточно спорные решения.

Не хочу раздувать спор, просто высказал своё мнение, т.к. тема действительно интересная, просто пошла немного не в то русло, ИМХО.

2NetFly · 19 Ноя 2004

А запросы типа ALTER TABLE... уже не модно? Как я понимаю, поля создаются раз и навсегда?

Смысла добавлять новые поля нет. Дополнительные поля на то и дополнительные, чтоб хранить в них дополнительную информацию. Заведомо известно, что они не будут участвовать в запросах. У меня порядка десятка типов документов, для каждого из которых есть как минимум несколько дополнительных полей. Используй я ALTER пришлось бы раздуть таблицу до неприличных размеров %)

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

Хотя бы потому, что она нужна. Ведь приходится решать задачи связанные не только с выводом информации, но и с добавлением, удалением, обновлением, причем как из админской части, так и из пользовательской. И здесь мой подход не особо отличается от общепринятого. Класс CDE (Create/Delete/Edit), механизм регистрации обработчиков, механизм проверки параметров, автоматизация обработки и вывода ошибок. А вот от автоматической генерации форм я отказался, у меня на то свои причины.

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

Кстати, если присмотреться, мое решение – это просто способ избавиться от foreach. Например, используя смарти задача вывода списка пользователей решается так (проверку на пустой результат упускаем):

Код:

<table><tr><td>Login</td><td>Email</td></tr>
{foreach item=user from=$users}
   <tr><td>{user.login}</td><td>{user.email}</td></tr>
<{/foreach}>
</table>

Удобно. Но! Если я вывожу список пользователей в двух разных местах и мне захотелось перевести логин в апперкейз, мне придется править два шаблона. Проблема решаемая. А если мне захотелось вывести выше общего списка пользователей список последних трех зарегистрированных. Лезть в код? Мой верстальщик решает задачу так:

Код:

{# User::List("user_list"), undef, { OrderBy =>
[["user_createdate", "desc"]], Limit => [0, 3] } #}

{# User::List("user_list") #}

Шаблон (тройной) user_list:

Код:

<table><tr><td>Login</td><td>Email</td></tr>
---
   <tr><td>{user.login}</td><td>{user.email}</td></tr>
---
</table>

Пример простой. А вот в музыкальной энциклопедии верстальщик при помощи Artist::List и разных шаблонов строил десятки различных списков без моего участия. Разве не удобно?

-~{}~ 19.11.04 12:44:

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

Шаблон главной страницы:
{# Artist::List("artist_list", undef, Limit => [0,5] ) #}

Шаблон artist_list:
---
Исполнитель: <b>{# artist.title #}</b>
{# Album::List("album_list", { artist_id => {# artist_id #} }) #}
---

Шаблон album_list:
<ul>
---
{# album.title #}
---
</ul>

На выходе имеем:
Blutengel
*Angel Dust
*Child Of Glass
*Demon Kiss
Camouflage
*Sensor

И т.д.

Конечно, с точки зрения производительности не лучшее решение и если бы мне пришло выводить список не 5, а 500 исполнителей оно бы не подошло. Но есть и другие задачи, где описанная техника очень выручает.

_RVK_ · 19 Ноя 2004

2NetFly
Ну есле на перле, тогда простительно. Было бы на пхп, то эта логика в шаблонах явно лишняя. По сути изобретение своего языка. Кстати Parser напоминает, не находишь?

Смысла добавлять новые поля нет. Дополнительные поля на то и дополнительные, чтоб хранить в них дополнительную информацию

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

Хотя, все же, наиболее оптимально это один прайс=одна таблица.

2NetFly · 19 Ноя 2004

Ну есле на перле, тогда простительно. Было бы на пхп, то эта логика в шаблонах явно лишняя. По сути изобретение своего языка. Кстати Parser напоминает, не находишь?

Кстати, если говорить о сматри, то мне кажется, существование сего пакета под перл было бы более оправдано =) Ведь по сути разумное использование php в шаблонах – это практически то же, что использование смарти.

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

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

но я решил это отдельной таблицей для хранения данных:
| fk_price_id | fk_record_id |field_name | field_value |

Такое решение разве не усложняет sql запросы?

Постскриптум. Дополнил свой предыдущий пост. Перечитайте =)

_RVK_ · 19 Ноя 2004

Постскриптум. Дополнил свой предыдущий пост. Перечитайте

Да, перечитал.

Такое решение разве не усложняет sql запросы

Усложняет. Но объединение 2х таблиц, не слишком ресурсоемкая операция, если есть нужные индксы. Да и работать с такими данными гораздо проще. И индексы ускаряют выборку, а тебе выборку по твоим дополнительным полям только LIKE делать. А еще, я очень быстро могу получить список всех прайсов, тк это таблица с двумя полями id и name. Т.е. с дополнительными данными я работаю только при выводе конкретного прайса.
Еще один недостаток, поле field_value фиксированного размера, а часто нужно хранить в нем один байт или наоборот много. Можно использовать несколько таблиц для разных типов данных.

Но повторяю, это не слишком хорошее решение, лучше по таблице на документ.

Кстати, если много документов сложных форматов, то может лучше использовать XML?

2NetFly · 19 Ноя 2004

Кстати, если много документов сложных форматов, то может лучше использовать XML?

К этому все и пришло %) Как всегда это бывает, не оценишь решения, пока сам не столкнешься с проблемой, которое оно решает.

Что скажешь по поводу приведенных мной примеров? Тривиальные (да и не тривиальные) задачи решаются просто, кода становится совсем мало. Я все это к чему, может есть недостатки в моем методе, которые я просто не замечаю? Или может возможно так же просто решать подобные задачи _правильными_ методами?

_RVK_ · 19 Ноя 2004

Что скажешь по поводу приведенных мной примеров? Тривиальные (да и не тривиальные) задачи решаются просто, кода становится совсем мало. Я все это к чему, может есть недостатки в моем методе, которые я просто не замечаю? Или может возможно так же просто решать подобные задачи _правильными_ методами?

Ну на php все это можно решать с помощю смарти или xslt. Но я тебе не советчик, тк. не то не другое не использую. Лично я противник размещать логику в шаблонах, хотя есть и много сторонников. Хотя спорить не буду, кода меньше... кстати, тут паралельно идет похожая тема: http://phpclub.ru/talk/showthread.php?threadid=55126&goto=newpost

2NetFly · 19 Ноя 2004

При помощи XSLT можно решать и в перле =) Думаю, это следующее, к чему я приду.

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

>> Но я тебе не советчик, тк. не то не другое не использую.
А что используешь, если не секрет?

>>Лично я противник размещать логику в шаблонах, хотя есть и много сторонников.
Почему? Мне именно это больше всего интересно. Какие плюсы такого подхода?

Тему уже читаю =)

_RVK_ · 19 Ноя 2004

Тему уже читаю

Это надолго

А что используешь, если не секрет?

Самописный движок. В той теме, что я дал ссылку, в конце пример.

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

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

Romantik · 19 Ноя 2004

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

antiportal · 19 Ноя 2004

Diesel

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

Может тогда вообще технический прогресс отменим?

Нафиг нам RADы и прочие "извращения"? Да и в шаблонизации особой необходимости нет...

Тут не столько неприязнь к логике в шаблонах, сколько... как бы сказать... не созрел я еще.

Не бойся, с тобой тысячи девелоперов по всему свету =) Социальный опыт -- тоже опыт.
(на самом деле я завидую, что тебе это не очень нужно

)

tp · 2 Дек 2004

Мои мысли по поводу cms

Я тоже пытался писать cms.
Она основана на упоминавшемся здесь дереве документов (если я правильно понял)
Основные сущности - папка, документ, юзер и шаблон.
Изначально в системе нет ни новостей, ни комментариев, ни прочего, для того, чтобы создать, например, сущность новость - создается шаблон новость для него задаются необходимые поля, для каждого поля задается его тип (типов не так много, например строка, текст, картинка, дата и тп)
После того как шаблон создан по нему генерируется таблица mysql в соответствии с заданными полями и smarty-шаблон для ввода информации (при редактировании шаблона alter table и перегенерации smarty-шаблона)
Для привязки документов создается дерево папок (дерево организовано на nested sets), при создании папки указывается документы какого типа шаблона будут в ней хранится.
При создании документа (после сохранения) запускается обработчик, на входе которого данные, введенные пользователем + шаблон документа, этот обработчик обрабатывает поля шаблона, в соответствии с шаблоном (напр, текстовые данные записывает в базу, картинки записывает в файловую систему, их параметры в базу и тд)
Кроме того, есть понятие юзера, в каждой папке юзеру можно назначить роль модератора или редактора.

Вот вкратце такие мысли, если кому-то интересно или появятся идеи - буду рад подискутировать.

Wingely Dog · 2 Дек 2004

смотрю никто из вас ИМХО писать не умеет 8/

_RVK_ · 2 Дек 2004

смотрю никто из вас ИМХО писать не умеет 8

Научи, а то мы тут все ламеры... куда нам до тебя! Это я к тому что никто не мешает тебе вступить в дискусию и предложить свои идеи.

Wingely Dog · 2 Дек 2004

[offtopic]
учу.
----------------------------------
на самом деле бла бла бла делается как бла бла бла ( ИМХО )
-----------------------------------
8)

вступать в дискуссию пока не хочу,
вы так умно разговариваете, а я с рождения туповатый.
[/offtopic]

_RVK_ · 2 Дек 2004

Господа модераторы, удалите, плиз, последние 4 сообщения.

Wingely Dog · 2 Дек 2004

съел?

по теме:
может сначала определиться что есть CMS старого толка, а что есть CMS современная?
попунктно, технические и прочие требования

(ИМХО канешна же)

Концепции современной CMS

antiportal

Guest

-

antiportal

Guest

Новичок

-

Новичок

-

Новичок

-

Новичок

-

Новичок

TeaM PHPClub

antiportal

Guest

tp

Guest

Wingely Dog

Guest

Новичок

Wingely Dog

Guest

Новичок

Wingely Dog

Guest