Ранее был рассмотрен метод publish (), наследуемый классом WeblinksControllerWeblinks из класса JControllerAdmin. В этом методе был проанализирован следующий фрагмент кода:

// опубликовать элементы
if (!$model->publish($cid, $value)) {
JError::raiseWarning(500, $model->getError()) ; }

Именно здесь из модели вызывается метод publish (). Если он завершается успешно, то возвращается логическое значение true. В противном случае возвращается логическое значение false и предоставляются сведения о возникшей ошибке, которые могут быть извлечены методом getError ().

А теперь рассмотрим аналогичный метод publish () из модели, а по существу, из класса JModelAdmin. Он вызывается с двумя аргументами. Напомним, что первым его
аргументом является переменная $cid, содержащая массив идентификаторов веб-ссылок, проверенных по списку, а вторым аргументом — переменная $value, содержащая значение, которое требуется поместить в столбце state таблицы #weblinks.

Обратите внимание на то, что первый аргумент данного метода обозначается префиксом &. Это означает, что данный аргумент передается по ссылке. Так, если изменить значение переменной &$pks в теле вызываемого метода, внесенные изменения окажутся доступными в вызывающем методе из переменной $cid, использовавшейся в качестве аргумента при вызове метода publish (). Причины такого проектного решения будут пояснены несколько позже.

В следующих двух строках кода инициализируются объекты диспетчера и пользователя. Как пояснялось ранее, диспетчер используется для инициирования событий, обрабатываемых в подключаемых модулях. Далее создается табличный объект, для чего вызывается метод getTable (). Следует, однако, иметь в виду, что все это происходит в классе WeblinksModelWeblink, хотя метод publish () вызывался из класса JModel Admin. Но поскольку в классе WeblinksModelWeblink имеется метод getTable (), то именно он и используется. 

В этом коде объект класса WeblinksModelWeblink получается из папки tables. В этом классе предоставляются методы, используемые для чтения и записи информации в созданную таким образом таблицу базы данных.

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

Далее следуют комментарий и последняя строка из первой части метода publish ():

// включить подключаемые модули содержимого, чтобы изменить событие состояния JPluginHelper::importPlugin('content');

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

В этом фрагменте кода организуется циклическое обращение к каждому элементу по его идентификатору и проверяются полномочия пользователя на изменение состояния "опубликовано" каждого такого элемента. Сначала исходные по умолчанию значения устанавливаются в столбцах таблицы с помощью метода reset (), а затем по идентификатору каждого элемента вызывается метод $table->load(). Этот метод считывает строку из таблицы базы данных и загружает ее в табличный объект $ table. Если этот метод завершится успешно, то возвращается логическое значение true, а затем, как в данном случае, вызывается метод $this->canEditState (). Из этого метода возвращается логическое значение true, если пользователю разрешено изменять состояние данного элемента веб-ссылки. А если у него нет таких полономочий, то возвращается логическое значение false.

Таким образом, если пользователь наделен соответствующими полномочиями, следующий далее кодовый блок условного оператора if пропускается и выполнение рассматриваемого здесь метода продолжается дальше. А если у пользователя нет таких полномочий, то выполняются следующие действия. Во-первых, элемент удаляется по своему идентификатору из массива $pks с помощью команды unset языка РНР. Во-вторых, выводится сообщение, предупреждающее пользователя о том, что у него нет надлежащих полномочий. И в-третьих, происходит возврат из рассматриваемого здесь метода по команде return false. Следует заметить, что где бы команда return ни использовалась в теле вызываемого метода, его выполнение немедленно завершается и происходит возврат в вызывающий метод.

Напомним, что при передаче в качестве первого аргумента методу publish () переменная $pks была обозначена префиксом &, т.е. она передавалась по ссылке. Следовательно, при удалении элемента из массива, хранящегося в этой переменной, по команде unset изменения в массиве окажутся доступными в вызывающем методе. Иными словами, изменение переменной $pks в теле метода publish () отразится на состоянии переменной $cid в том контроллере, где этот метод вызывался.

Напомним также, что метод publish () вызывался из модели в теле метода publish {) из класса JControllerAdmin следующим образом:

if (!$model->publish($cid, $value)) {

а затем количество опубликованных веб-ссылок было включено в сообщение так, как показано ниже.

$this->setMessage(JText::plural($ntext, count($cid)));

Если пользователь попытается удалить в корзину три веб-ссылки, но одна из них относится к той категории, где у него нет полномочий выполнять действие core. edit. state, то в конечном итоге в корзину попадут лишь две веб-ссылки. Но поскольку необработанный элемент все равно удаляется по команде unset из массива $pks, передаваемого данному методу по ссылке &, то изменения в массиве $pks отразятся на состоянии переменной $cid в вызывающем методе publish () текущего контроллера. Таким образом, переменная $cid в данном примере будет содержать лишь два элемента, а в сообщении будет правильно извещено об удалении в корзину двух, а не трех веб-ссылок.

Рассмотрим далее метод canEditState () из класса WeblinksModelWeblink. Ниже приведен его исходный код.

protected function canEditState($record) { $user = JFactory::getUser() ;
if (!empty($record->catid)) {
return $user->authorise('core.edit.state', *b 'com_weblinks.category.'. (int) $record->catid); } else {
return parent::canEditState($record); } }

Обратите внимание на то, что этот метод объявляется с модификатором доступа protected, а следовательно, он может использоваться только в текущем классе или расширяющем его классе. Это означает, что данный метод предназначен для поддержки метода публикации, но не может быть использован за пределами своего класса.

В систему безопасности ACL (списков контроля доступа), внедренную в версии Joomla 1.6, введены специальные полномочия на изменение состояния "опубликовано" конкретного элемента. Для компонента Weblinks эти полномочия могут быть установлены как на уровне самого компонента, так и на уровне его категории. Поэтому в методе canEditState () проверяется, имеется ли категория у текущей записи. (Впрочем, у компонента Weblinks всегда должна быть какая-то категория, а следовательно, подобная проверка оказывается ненужной.) И если такая категория имеется, то вызывается метод authorise () из класса JUser для проверки полномочий текущего пользователя на изменение состояния "опубликовано" веб-ссылки в данной категории. (Обратите внимание на британский вариант написания метода authorise (), поскольку британский английский принят в качестве официального языка для Joomla.) В качестве аргументов метода authorise () указываются выполняемое действие и наименование ресурса. Для категорий наименование ресурса составляется по следующему образцу:

<имя компонента> +   .category.   +  идентификатор категории>

Если у текущей записи отсутствует категория, из родительского класса JModelAdmin вызывается метод canEditState (), который содержит следующую строку кода:

return $user->authorise('core.edit.state', $this->option);

В этой строке кода проверяются полномочия на уровне компонента. Поле $this-> option содержит имя компонента (в данном случае com_weblinks).

Ранее в этой главе упоминался файл access .xml, который содержит действия ACL, выполняемые на уровне компонента и на уровне категории данного компонента. Кроме того, в этом файле определяются элементы разметки action с атрибутом name="core.edit.state" для обозначения компонентов и категорий по частям. Файл access.xml позволяет отредактировать установленные полномочия для компонентов и категорий. А в коде рассматриваемого здесь метода эти полномочия проверяются.

Если пользователю разрешено выполнить указанное действие, из метода authorise () возвращается логическое значение true, в противном случае — логическое значение false. Полученное в итоге значение возвращается далее из метода canEditState ().

Ниже приведен следующий фрагмент кода из метода publish () класса JModel Admin.

// попытаться изменить  состояние  записей
(!$table->publish($pks,   $value,   $user->get('id')))   {
$this->setError($table->getError());
false; }

В этом фрагменте кода, по существу, изменяется значение в базе данных. Для этого вызывается метод publish () из табличного объекта $table, возвращающий логическое значение true или false для обозначения своего успешного или неудачного завершения соответственно. Если этот метод завершится неудачно, из него будет выведено сообщение об ошибке и возвращено логическое значение false, указывающее вызывающему методу на возникшую ошибку.

В следующем фрагменте кода из метода publish (), определяемого в классе JModelAdmin, вызываются подключаемые модули для обработки события onContentChangeState, как показано ниже.

Сначала в этом фрагменте кода задается контекст, чтобы подключаемые модули могли проверить его по мере надобности. Затем созданный ранее объект $dispatcher используется для инициирования упомянутого выше события. В поле $this->event_change_ state конструктором класса JModelAdmin было установлено исходное по умолчанию значение onContentChangeState.

Метод trigger () возвращает массив результатов обработки в каждом подключаемом модуле. Если обработка в любом из подключаемых модулей завершится неудачно, из таблицы будет снова выдано сообщение об ошибке и возвращено логическое значение false. Это очень важное свойство данной модели. Ведь оно позволяет разработчику специально настроить последовательность операций для публикации элементов. Так, если написать специальный подключаемый модуль для обработки события onContentChangeState, то в нем можно предусмотреть контроль над успешным или неудачным выполнением задачи публикации. В частности, можно потребовать от администратора веб-сайта дать согласие на публикацию пользователем конкретного элемента содержимого. И такой подключаемый модуль может управлять этим процессом.

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

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