2009-08-03 3 views
0

Я создаю CMS и использую сериализацию для обработки публикации и отката, которая, кажется, работает нормально. В принципе, обычные таблицы сайтов - это то, что отображается, а все, что не отображается, сериализуется в отдельной таблице. Однако проблема заключается в том, что функции «Preview» работают.Откат и предварительный просмотр в CMS

Поскольку внешний интерфейс создается с использованием обычных вызовов SQL, а все предварительно опубликованные/откатные данные находятся в отдельной таблице, это означает обновление каждого оператора sql с помощью какого-либо причудливого кода, чтобы вывести версию на предварительный просмотр. Это также будет особенно проблематичным с такими вещами, как ограничения и т. Д., И это будет кошмар для передней части.

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

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

ответ

-3

Если вы разделите Model, View и Controller, это не должно быть проблемой: вы просто берете модель из другого места в контроллере и передаете ее в представление.

+0

Извините, но какое это имеет отношение к чему-либо? – Meep3D

0

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

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

Рассмотрим следующий пример:

//in the controller: 
$previewPage->setTitle("foo"); 
... 
//in the view(when previewing): 
$previewPage->getTitle(); // returns whatever you stored beforehand 

//in the view(regular viewing): 
$livePage->getTitle(); // queries the database and returns the result 

Чтобы узнать больше о шаблоне Model-View-Controller вы можете захотеть, чтобы проверить this статью.

Я надеюсь, что это поможет.

+0

Я довольно знаком с MVC. Проблема в том, что это в основном запретит любому, кто когда-либо использовал SQL когда-либо, читать или записывать. Модули CMS, как ожидается, будут обрабатывать себя, и я хотел бы, чтобы весь процесс был прозрачным для них, чтобы все было просто. – Meep3D

1

Я не уверен, что сохранение ваших данных контента в более чем 1 таблице в зависимости от ее состояния - это путь.

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

Я использовал этот метод для различных приложений и всегда был доволен тем, насколько легко было выполнять откаты, предварительные просмотры и еще более сложные вещи (cvs-подобные псевдо-ветви, ...).

Смежные вопросы