Почему magento использует xml-файлы для создания тем? [закрыто]

Question

Почему magento использует xml-файлы для создания тем? [закрыто]

Я новичок в Magento и изучаю его документацию. Извините меня, если я немного возражаю против этого, но я непредубежден. Я не понимаю, почему Magento использует XML для тематизации. В чем причина этого?

Я запускаю новейшую версию 1.6 из репозитория SVN и следую этому сайту.

Я прочитал, что мне нужно создать local.xml объявляя, что входит и выходит из темы. После того, как я сделал базовую структуру, затем добавил свой каталог тем через серверную часть. Я удалены элементы на переднем конце с помощью нескольких xml-элементов

Пример:

<remove name="right.poll"/>
<remove name="right.permanent.callout"/>
<remove name="left.permanent.callout"/>
<remove name="paypal.partner.right.logo"/>

~~Домашняя страница не меняется... почему это так? Есть ли другое место, которое нуждалось бы в модификации?~~
Я обнаружил, что мне нужно отключить все кэширование только для разработчиков.
(для тех, кто не знает его (страница администратора) - > система -> управление кэшем -> выбрать все и отключить)

Я также не понимаю, почему каталог CSS/JS/media полностью отделен от шаблона каталог. Не имеет смысла, зачем им это делать. Еще одна вещь, которую я не понимаю, - это почему существует миллион каталогов (сарказм), в которые мне нужно попасть, чтобы внести изменения. Я предполагаю, что они используют какую-то модель MVC, но это, безусловно, ничего из того, что я когда-либо видел. Если они пытаются создать красивые URL-адреса со всеми этими каталогами, я почти уверен, что они слышали о htaccess. (еще раз извините меня, если я кажусь невежественным, но я новичок).

PS., я просмотрел файлы phtml и большую часть они выглядят так, как будто они просто вызывают эти XML-элементы, можно ли использовать обычный старый HTML и PHP для создания темы? Или я вынужден использовать их методы XML?

Редактировать: папка темы в приложении/дизайне/интерфейсе имеет две папки: базовую и по умолчанию, которые, как я думаю, являются интерфейсами, например, группой тем, которые я хотел бы использовать. я изменил таблицу БД design_change с по умолчанию/по умолчанию на базовую/по умолчанию (также сделано на странице администратора, но мне больше нравится бд). я видел, что была отрисована другая страница. поэтому я решил, что могу просто удалить базовую папку, потому что это дополнительная путаница. когда я это сделал, сайт сломался. таким образом, похоже, что magento привязал два каталога тем к этому приложению. как будто они так же сбиты с толку, как и мы. я прав?

Пожалуйста, дайте мне знать о вашем вкладе.

Спасибо.

Ps: я узнал, что magento из фреймворка zend.

12

php xml magento

Author: Sarmen B., 2011-12-24

Source

2 answers

Только чтение сможет вам здесь сильно помочь. Как только вы освоитесь с этим, xml-макеты станут довольно удобными, просто трудно понять, как они работают.

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

Вашей лучшей ссылкой часто является сам код Magento. До тех пор, пока вы никогда ничего не трогаете внутри базы/по умолчанию, у вас всегда будет ссылка на то, как это "должно" работать.

Magento определенно является инструментом швейцарской армии. Вы можете добиться успеха многими способами, каждый из которых имеет свои плюсы и минусы. Иногда нужно жестко кодировать материалы в шаблоны/макеты... иногда вам нужно использовать статические блоки и CMS (например, если клиент хочет иметь возможность что-то редактировать).

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

3

Author: pspahn, 2011-12-24 00:30:18

score 37 · Accepted Answer

Ваши ответы, в свою очередь:

"Я не понимаю, почему Magento использует XML для тематизации".

Во многих системах MVC определение того, какое содержимое и данные доступны в представлении, означает обработку (создание и настройку) действий контроллера. XML-формат макета дает даже разработчикам интерфейсов возможность добавлять и удалять элементы представления и их данные ("Блоки" в Magento) на разных маршрутах без необходимости переписывать классы контроллеров действий.

"Я прочитал, что мне нужно создать local.xml объявляя, что входит и выходит из темы".

Не обязательно. Если у вас нет настроек XML макета, вам не понадобится local.xml файл. Более того, если у вас есть настройки XML макета ТОЛЬКО для домашней страницы, вы можете добавить свой XML обновления макета в данные страницы через администратора CMS.

"[W]hy [является] каталог CSS/JS/media полностью отделен от каталога шаблонов[?]"

Это просто функция безопасности. Все файлы в разделе ./skin могут быть доступны напрямую через браузер, а все файлы в разделе ./app невозможно получить доступ к через браузер, включая файлы, связанные с темой, в разделе ./app/design. Является ли это логичной, удобной для разработчиков стратегией? Вовсе нет, и Magento решает эту проблему в Magento 2, , который доступен на github.

"[Почему существует] миллион каталогов (сарказм), в которые мне нужно попасть, чтобы внести изменения[?] Я предполагаю, что они используя какую-то модель MVC, но это далеко не то, что я когда-либо видел"
.

Magento действительно является платформой MVC, и при этом надежной. Это, как вы заметили, довольно отчетливо, особенно в области фреймворков PHP.

Модели - это классы PHP под app/code/[codePool]/Namespace/ModuleName/. По соглашению, они находятся в каталоге Model. Они бывают трех основных типов: модели данных, которые обычно находятся непосредственно в каталоге Model/, и модели ресурсов и ресурсы коллекции, которые обычно находятся под Model/Resource начиная с Magento 1.6.
Представления - это классы PHP, которые обычно находятся под app/code/[codePool]/Namespace/ModuleName/Block/. Они могут отображаться или не отображаться вместе с файлами шаблонов (.phtml). В отличие от многих фреймворков MVC, представления в Magento часто загружают свои собственные данные независимо от маршрута/действия.
Контроллеры - это классы PHP, которые находятся в разделе app/code/[Кодовый пул]/Пространство имен/Имя модуля/контроллеры/`.

"Если они пытаются сделать красивые URL-адреса со всеми этими каталогами, я почти уверен, что они слышали о htaccess"
.

Вовсе нет. Единственное, что связывает URL-адреса с контроллерами действий, - это конфигурация (это относится ко всем классам MVC за пределами пространства имен Mage). URL-адреса SEF достижимы с помощью конфигурации несколькими способами, а также с помощью перезаписи базы данных, которую можно найти в таблице core_url_rewrite. Magento использует файл .htaccess только как средство маршрутизации соответствующих запросов к точке входа в систему, index.php.

"Я заглянул в файлы phtml, и большинство из них выглядят так, как будто они просто вызывают эти XML-элементы, можно ли использовать обычный старый HTML и PHP для создания темы? Или я вынужден использовать их методы XML?"

Шаблоны тупые. Они бессмысленны без класса представления, в котором они отображаются - буквально included()ред. Доступные им методы и данные поступают из их (часто) настроенного на макет класса представления. Пример конфигурации представления см. в разделе app/design/frontend/base/default/layout/cms.xml: строка <block type="core/template" name="page_content_heading" template="cms/content_heading.phtml"/> объявляет экземпляр Mage_Core_Block_Template с шаблоном cms/content_heading.phtml из темы интерфейса.

"[T]папка темы в приложении/дизайне/интерфейсе имеет две папки: базовую и по умолчанию, которые, как я думаю, являются интерфейсами, например, группой тем, которые я хотел бы использовать. я изменил базу данных design_change"

Хорошо, что вы исследуете эти вещи; подход исследователя будет будьте полезны, когда вы изучаете структуру. Темы в Magento определяются тремя компонентами: областью (интерфейс или adminhtml), именем пакета и фактическим именем темы. Как вы заметили, в файловой системе эти параметры отображаются в двух местах. Это ./app/design/AREA/PACKAGE/THEME/ и ./skin/AREA/PACKAGE/THEME/. В Magento есть еще два аспекта тематизации: тип ресурса темы и резервный вариант.

Существует четыре типа ресурсов темы: макет, шаблон, перевод и обложка. Путь, который система использует для поиска данного ресурса темы, является на основе конфигурации, а также некоторых жестко закодированных путей. Абсолютной резервной точкой для ресурсов темы является тема базового пакета по умолчанию. В соответствующей конфигурации Magento вы сначала объявляете пакет (например, "my_package" в разделе Система > Конфигурация > Дизайн. Если настройки темы не объявлены, система просто будет искать ресурсы в теме по умолчанию; это будет соответствовать app/design/frontend/my_package/default/template/. Если бы вы объявили тему "Шаблоны" в конфигурации дизайна (например, "my_templates", система сначала посмотрит там, а затем посмотрит в теме по умолчанию. Существует также параметр конфигурации "По умолчанию", который, если он установлен, будет использоваться для всех типов ресурсов темы (например, "my_default"). Все это происходит в Mage_Core_Model_Design_Package и выглядит следующим образом; мы будем использовать наши настройки примера и параметр "cms/content_heading.phtml" сверху:

app/design/frontend/my_package/my_templates/template/cms/content_heading.phtml (если найдете, используйте этот, больше нигде не ищите)
app/design/frontend/my_package/my_default/template/cms/content_heading.phtml (если найден, используйте этот, не смотри больше никуда)
app/design/frontend/my_package/default/template/cms/content_heading.phtml (если найдете, используйте этот, больше нигде не ищите)
app/design/frontend/base/default/template/cms/content_heading.phtml (если здесь не найдено, кто-то облажался, и исключение будет зарегистрировано в системном журнале по адресу ./var/log/system.log)

Этот резервный вариант дизайна используется по двум причинам: позволяет разработчикам хранить ресурсы темы в надежных местах (база/по умолчанию) и позволяет многократно использовать и переопределять ресурсы темы.

Тем не менее, это не идеальная архитектура, и как как уже упоминалось, это исчезает в Magento 2 - все ресурсы темы будут храниться в каталоге соответствующего модуля.