Архив метки: Юпи!

Юпи! 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 разделение.

Предыдущие серии

1 Вступление

2 Yii, создаем свою CMS. База данных

Наверное в каждом веб-приложении возникает задача разделения, так называемой клиентской или public части – та часть веб-сайта или веб-приложения с которой работает пользователь и админ или back части –  часть сайта, с которой работают администраторы, контент-менеджеры и прочие пользователи, отвечающие за наполнение сайта. Сегодня я хочу поговорить о том как это сделать, при использовании фреймворка Yii и какой способ выбрал я при разработке Юпи!.

Критериями для выбора способа будут являться следующие:

  • простота реализации
  • необходимость выполнять дополнительные “тело движения” (править .htaccess, колдовать с роутингом и т.д.)

И так…

При использовании Yii можно поступить несколькими способами:

  1. Создать контроллер Admin или Back и всю логику админки реализовывать там;
  2. В каталоге Controllers создать подкаталог admin или back и все контроллеры и экшены для админки располагать там;
  3. Админка в виде отдельного модуля Yii;
  4. Создать два приложения – одно  для админской части, другое для клиентской;

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

Кратко рассмотрим достоинства и недостатки каждого из них.

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. База данных.

Краткое содержание предыдущих серий

1 Вступление

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

Когда я приступаю к разработке нового приложения или сайта, и уже более или менее понятно с какими сущностями придется работать и какие данные хранить, лично я, предпочитаю нарисовать схему базы данных, которая в будущем будет хранить всю информацию приложения. Такая схема позволит более наглядно представить все объекты, разрабатываемого приложения и взаимосвязи между ними. Для рисования таких схем, можно воспользоваться любым инструментом, начиная от листа бумаги и карандаша, заканчивая специализированным ПО, типа 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

Присоединяйтесь!