Юпи! возвращение =)
Последнее время вернулся к разработке свой маленькой CMS-ки на Yii.
Рабочее название осталось прежним — Юпи! =)
Основные новости:
- код переехал на github https://github.com/yupe/yupe
- стараюсь вести список актуальных задачек
- создал и постепенно наполняю Вики
- предложены варианты дизайна основного сайта
Присоединяйтесь к разработке!
Основной сайт Юпи! — http://yupe.ru
Исходный код — https://github.com/yupe/yupe
Присоединяйтесь!
Юпи! 0.0.1
Юпи! 0.0.1
Выход первой версии моего движка задерживается! Навалилось много работы — на все про все не хватает времени!
Тем не менее, определил список основных задач, которые должны быть решены до выхода версии 0.0.1, с ними можно ознакомиться здесь http://code.google.com/p/xomaprojects/issues/list (задачи помечены меткой Release0.0.1). Так же выложил первую сырую, но рабочую версию пробуем и сообщаем об ошибках!
p.s. Хотелось бы еще раз поблагодарить Ozzy, за проведенное им маленькое тестирование!читать в jj
Основной сайт Юпи! — http://yupe.ru
Исходный код — https://github.com/yupe/yupe
Присоединяйтесь!
Движок блога на Yii. Front и back разделение.
Предыдущие серии
2 Yii, создаем свою CMS. База данных
Наверное в каждом веб-приложении возникает задача разделения, так называемой клиентской или public части — та часть веб-сайта или веб-приложения с которой работает пользователь и админ или back части - часть сайта, с которой работают администраторы, контент-менеджеры и прочие пользователи, отвечающие за наполнение сайта. Сегодня я хочу поговорить о том как это сделать, при использовании фреймворка Yii и какой способ выбрал я при разработке Юпи!.
Критериями для выбора способа будут являться следующие:
- простота реализации
- необходимость выполнять дополнительные «тело движения» (править .htaccess, колдовать с роутингом и т.д.)
И так…
При использовании Yii можно поступить несколькими способами:
- Создать контроллер Admin или Back и всю логику админки реализовывать там;
- В каталоге Controllers создать подкаталог admin или back и все контроллеры и экшены для админки располагать там;
- Админка в виде отдельного модуля Yii;
- Создать два приложения — одно для админской части, другое для клиентской;
Все четыре способа упорядочены по сложности их реализации и по необходимости выполнять дополнительные действия — т.е. писать код!
Кратко рассмотрим достоинства и недостатки каждого из них.
1 Создать контроллер Admin или Back и всю логику админки реализовывать там — наверное самый простой способ.
Достоинтва:
- простота реализации;
- модели используются всем приложением;
Недостатки:
- если админка будет очень большая (с большим функционалом), наш контроллер «раздуется» до огромных размеров, что затруднит сопровождение проекта (эту проблему, отчасти может решить вынесение экшенов в отдельные классы);
- нет отделения админки от остальных частей проекта;
2 В каталоге Controllers создать подкаталог admin или back и все контроллеры и экшены для админки располагать там — второй по сложности реализации способ, забегая вперед, скажу, что я выбрал именно его.
Достоинства:
- админка физически (на уровне каталога файловой системы) отделена от остальных частей проекта, причем это отделение касается не только каталога Controllers, но и каталога View;
- модели используются всем приложением;
Недостатки:
я пока их не нашел
3 Админка в виде отдельного модуля Yii — по правде говоря, кода я начал разрабатывать Юпи! и столкнулся с проблемой разделения на back и front части — тогда еще не было поддержки модулей в Yii (она появилась в версии 1.0.3), поэтому данный способ я не рассматривал. Если кто-то пытался поступить таким образом — прошу рассказать о своем опыте в комментариях.
4 Создать два приложения — одно для админской части, другое для клиентской — как мне кажется, самый трудоемкий способ.
Достоинства они же, от части, являются и недостатками:
- части системы полностью изолированы друг от друга, из этого следует что без «пляски с бубнами» и дополнительных опций в конфиге не получится использовать модели и библиотеки одного приложения в другом, а отсюда вытекает дублирование кода и все что с ним связано.
Для себя я выбрал способ №2, он, как мне кажется, наиболее удовлетворяет всем моим требованиям.
Таким образом мы имеем следующую структуру проекта.
Вопрос разделения приложения на 2 части поднимался на официальном форуме Yii, почитать можно тут.
Кроме такого вот разделения приложения на две части, для каждой из них я сделал свой базовый контроллер, таким образом все контроллеры клиентской части наследуются от YFrontMainController, а контроллеры админской части от YBackMainController. Введение новых базовых контроллеров позволяет:
- реализовать функционал, специфичный для каждой части приложения, в одном месте, что облегчает повторное использование и сопровождение;
- как правило, для клиентской и адмиской частей используются разные лайауты (layouts), разделение контроллеров позволяет реализовать это очень просто (для этого достаточно переопределить свойство layout);
Например, для всех контроллеров админки, я применяю фильтр, проверяющий авторизацию пользователя, не имея базового контроллера, мне бы пришлось прописывать его во всех контроллерах админки. Так же применяется xss-фильтр, для всех данных, отправляемых из панели администрирования.
Скорее всего, выбранное мной решение, не является идеальным и имеет скрытые (пока!) от меня недостатки, если Вы о таковых знаете — прошу высказываться в комментариях.
Удачного yii-кодинга, друзья!
Основной сайт Юпи! — http://yupe.ru
Исходный код — https://github.com/yupe/yupe
Присоединяйтесь!
Yii, создаем свою CMS. База данных.
Краткое содержание предыдущих серий
И так, имея скромный набор требований, описанный в первой статье, перейдем непосредственно к разработке.
Когда я приступаю к разработке нового приложения или сайта, и уже более или менее понятно с какими сущностями придется работать и какие данные хранить, лично я, предпочитаю нарисовать схему базы данных, которая в будущем будет хранить всю информацию приложения. Такая схема позволит более наглядно представить все объекты, разрабатываемого приложения и взаимосвязи между ними. Для рисования таких схем, можно воспользоваться любым инструментом, начиная от листа бумаги и карандаша, заканчивая специализированным ПО, типа MS VISIO. Однако, я предпочитаю программное обеспечение, специально предназначенное для этих целей. Довольно давно, я пользуюсь Mysql Workbench, для проектирования баз данных Mysql, подробнее узнать про эту программу и скачать ее, можно тут.
Примерно за 40 минут работы, у меня получилась вот такая вот схема БД.
Сейчас постараюсь подробно рассказать про назначение каждой таблицы и каждого столбца.
И так поехали!
User — предназначена для хранения данных о зарегистрированных пользователях (на первом этапе разработки, наша цмска будет однопользовательской — т.е. добавлять контент сможет любой пользователь прошедший авторизацию, в связи с этим, на первом этапе не будет возможности регистрироваться новым пользователям).
- userId — идентификатор пользователя;
- name — имя пользователя;
- email — email пользователя;
- password — пароль пользователя;
- creationDate — дата регистрации пользователя (пока система однопользовательская — особого смысла в этом поле нет);
- status — 0 — пользователь активен 1 - пользователь заблокирован;
- accessLevel — 0 — простой пользователь 1 — администратор (может управлять контентом и совершать административные действия)
System - таблица для хранения всех системных параметров.
- systemId — идентификатор записи
- siteUrl - основной url сайта
- siteInfo- информация о сайте
- siteDescription — описание сайта
- ownerInfo — информация о владельце
- ownerEmail — email администратора сайта
- userId — пользователь создавший настройку (в однопользовательской работе на учитывается)
Content - данная таблица будет содержать все записи (посты), страницы и все остальное наполнение нашего движка.
- contentId — идентификатор записи
- title - заголовок записи
- alias — строка Url данного записи
- content — содержимое поста
- status — 0 — черновик, 1 — опубликовано
- keywords - ключевые слова для записи (meta)
- description — описание записи (meta)
- createdBy - идентификатор пользователя создавшего запись
- creationDate — дата создания
- active — признак того что эта запись является самой последней (актуальной)
- canComment — разрешены ли комментарии для данной записи
- isPrivate - пост доступен только авторизованным пользователям (в версии 1 нашего движка это работать не будет)
- publishDate - дата публикации
- revision - номер версии записи
- contentParentId - идентификатор, изначально созданной записи
- revisionParentId - идентификатор, предыдущей ревизии
- contentType — тип контента 2 — запись (пост) 1 — страница
- modifyDate — дата изменения
- modifyBy — кем изменено
- commentCnt — количество комментариев
Comment - таблица хранит комментарии к постам и страницам (?).
- commentId — идентификатор комментария
- parentId — родительский комментарий (в первой версии движка мы его использовать скорее всего не будем)
- postId — идентификатор поста, к которому относится комментарий
- comment - текст комментария
- creationDate — дата создания комментария
- userName — имя пользователя, создавшего комментарий
- userEmail - email пользователя, создавшего комментарий
- userUrl — url пользователя, создавшего комментарий
- userIp - ip-адрес пользователя оставившего комментарий
- status — 0 — комментарий не подтвержден, 1 — комментарий одобрен, 2 — спам
Tag - таблица хранит тэги.
- tagId — идентификатор тэга
- tag — название тэга
TagContent- таблица предназначена для хранения отношения тегов и постов
- tagContentId — идентификатор контента
- contentId - идентификатор записи
- tagId - идентификатор тэга
Я думаю, что в процессе разработки, придется корректировать и дополнять эту схему, но для начала работы она вполне подойдет.
Если есть какие-то замечание или предложения — прошу высказываться в комментариях.
p.s. Названия движка, пока так и не выбрано — любые варианты приветствуются!
Основной сайт Юпи! — http://yupe.ru
Исходный код — https://github.com/yupe/yupe
Присоединяйтесь!
Yii создаем свою мега CMS !!!
В любом деле — главное ПРАКТИКА!
Вдоволь начитавшись документации и рассмотрев демо-примеры фреймворка Yii, я решил написать что-нибудь «более» функциональное чeм «testDrive». А что должен сделать любой web-программист в своей жизни???? Правильно!!! Написать свою супер-цмс!!!Ну если не цмс, то хотя бы что-то похожее.
И так…Начиная с этой статьи и на протяжении еще примерно 5-8 (ну как максимум 10), я буду рассказывать о процессе написания простенькой ЦМС, с использованием замечательного фреймворка Yii. Многое, что здесь будет написано, так или иначе пересекается с руководством Yii по созданию блога.
Для начала определимся с основными требованиями:
- администратор может управлять контентом двух основных типов:
- страницы
- посты
- администратор может удалять или одобрять комментарии к постам;
- посты могут сопровождаться произвольным количеством тэгов;
- пользователи могу просматривать посты и страницы и оставлять комментарии к ним;
- движок должен позволять менять темы оформления;
Конечно, это не полный список требований, и в процессе разработки он будет обновляться и корректироваться, но для начала этого вполне достаточно.
Определимся с технической стороной вопроса.
Писать все это мы будем на PHP, с использованием фреймворка Yii, в качестве БД будет использоваться MySQL. На клиенской стороне я буду использовать jquery и jquery UI.
И так с вступлением закончено, начиная со следующей статьи будет больше технических моментов и вопросов, решать которые, я предлагаю сообща, так что в случае любых замечаний и предложений, прошу не стесняться (:-)) и высказываться в комментариях.
Приступим!!!
p.s. А вот и первое «домашнее задание»: предлагаю придумать название для будущего творения, обязательное условие - в название должна присутствовать буква «Y» (Yii всетаки!!!).
p.s.s Названия типа YACS (yet another cms system) или YaBe! (yet another blog engine) — которые я хотел было «прикрутить» к этому творению — уже заняты!!! Так что, если есть какие то идеи и предложения — добро пожаловать в комментарии!
Основной сайт Юпи! — http://yupe.ru
Исходный код — https://github.com/yupe/yupe
Присоединяйтесь!



