Подтвердить что ты не робот

Почему 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"/>

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

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

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

edit: папка темы в приложении/дизайне/интерфейсе имеет две базы папок и по умолчанию, которые im думают, что каждый из этих интерфейсов представляет собой группу тем, которые я бы хотел использовать. Я изменил таблицу design_change db по умолчанию/по умолчанию на base/default (также на странице администратора, но мне больше нравится db). я видел, что была отображена другая страница. поэтому я решил, что могу просто вынуть базовую папку, потому что это лишняя путаница. когда я сделал, что сайт сломался. поэтому он выглядит так, как magento связал два тематических каталога в этом приложении. как будто они так же смущены, как и мы. я прав?

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

Спасибо.

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

4b9b3361

Ответ 1

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

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

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

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

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

"[W] hy [is] каталог 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, Views в Magento часто загружают свои собственные данные независимо от маршрута/действия.
  • Контроллеры - это классы PHP, которые находятся в приложении /code/ [codePool]/Namespace/ModuleName/controller/`.

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

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

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

Шаблоны тупые. Они бессмысленны без класса View, в котором они отображаются - буквально included() ed. Методы и данные, доступные для них, исходят из своего (часто) настроенного по макетам класса View. Пример конфигурации просмотра см. В разделе 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] В папке с темами theme/app/design/frontend есть две базы папок и по умолчанию, которые im думают, что каждый из них - это интерфейсы, например группа тем, которые я хотел бы использовать. Я изменил design_change db"

Хорошо, что вы расследуете эти вещи; подход исследователя будет полезен, когда вы изучите структуру. Темы в Magento определяются тремя компонентами: областью (frontend или 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 - все объекты темы будут храниться в их соответствующей директории модулей.

Ответ 2

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

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

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

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

Снова, держись в этом.. это, конечно, разочаровывает, но ты в конечном итоге подберешься по нюансам и почувствуешь себя более комфортно.