"контекст" на друпальной странице
Этот вопрос является общим, и я уже разместил его версию здесь. Я надеюсь, однако, что у меня будет больше шансов получить ответ и быть полезным для большего количества людей, задавая вопросы на этом форуме.
Объединять контент вместе, когда он загружается на друпал-страничку, довольно сложно. В drupal каждая страница, независимо от сайта, в основном одна и та же: у вас основное содержимое посередине (представление, узел или несколько узлов) с блоками, окружающими этот центральный контент. Чтобы блоки каким-то образом знали о том, что находится посередине (гораздо менее осведомлены друг о друге), вы либо должны сделать какую-то очень интересную работу в своем собственном пользовательском модуле, либо вы должны сделать "аргументы" доступными в URL.
Я изучал набор модулей space / context / features / purl, предоставленных developmentseed, а также изучил модули Panels / Ctools, созданные Эрлом Майлсом (парнем, который писал представления). Хотя оба предоставляют инструменты, облегчающие мою работу, мое понимание каждого из них заключается в том, что мне по-прежнему необходимо размещать "аргументы" в URL, если я хочу, чтобы содержимое моих блоков определялось моим "контекстом" (я использую это в общем смысл, а не в определенном смысле, подразумеваемом либо модулем контекста, либо понятием контекста в Ctools).
Я что-то упустил, или это то, где мы находимся с Drupal?
Наконец, я должен сказать в заключение, что я знаю о других модулях, которые помогают с такими вещами в ограниченном, индивидуальном порядке. Например, модуль присоединения Views и модуль ссылочных представлений Node стараются решить эту проблему для очень конкретного случая использования. Они оба хорошие модули, и есть другие подобные им, но я бы очень хотел найти решение этой проблемы в целом.
2 ответа
Думаю, я не совсем понимаю, к чему вы стремитесь, но тем не менее попробую:
Для каждого нестатического веб-сайта, будь то на основе Drupal или чего-либо еще, есть две основные вещи, обеспечивающие "контекст" для принятия решения о том, какой контент доставлять для данного запроса.
Первым и самым важным, очевидно, является сам запрос. Это единственная информация, которая всегда будет там. В большинстве случаев это будет просто запрос GET, и в этом случае URL-адрес неявно является основным источником доступного "контекста". POST-запросы могут предоставить немного больше "контекста" помимо URL, но по вашему вопросу можно утверждать, что они являются просто более сложным вариантом GET-запроса, предоставляя еще несколько "аргументов", помимо аргументов из URL (и в в большинстве случаев можно превратить запрос POST в запрос GET с более сложным URL-адресом в любом случае).
Вторая вещь, "обеспечивающая контекст" - это сеанс. Независимо от того, на каком механизме обработки сеансов базируется (в настоящее время, в основном, куки), цель всегда одна и та же, а именно - передать некоторую информацию о состоянии через границу запросов без сохранения состояния. Это делается путем привязки данного запроса к информации из предыдущих запросов, хранящейся на стороне сервера. Это позволяет "обогащать" информацию, которая доступна для принятия решения о том, какой контент доставлять по запросу. По сути, это можно рассматривать как способ добавления дополнительных "аргументов" к запросу.
И это все. Любая другая информация, необходимая для сборки ответа, должна как-то быть получена из информации, указанной в запросе (и можно сказать, что обработка сеанса уже является основным процессом, добавляя "контекст" на основе файла cookie или некоторого другого идентификатора). идет с просьбой).
Drupal довольно хорошо отражает этот процесс, IMHO, поскольку он сначала собирает "основное" содержимое для ответа на основе URL с дополнительной информацией (например, о пользователе), "прикрепленной" в сеансе. Только после того, как основной контент собран через звонки $return = menu_execute_active_handler() в index.php, что другие элементы ответа добавляются (например, блоки, меню и т. д.), вызывая theme('page', $return);,
Таким образом, какой бы "контекст" ни был, что вы хотите "передать" этим другим элементам, вы должны либо "извлечь" его из информации, уже использованной для сборки основного контента (URL, сеанс), либо вы должны временно сохранить ее во время генерации основного контекста. Вы можете сделать это разными способами, например, добавив его к информации, уже сохраненной в сеансе, используя статическое кэширование в некоторых функциях, задав глобальные переменные (не;), передавая данные через базу данных и т. Д.,
Опять же, я не понимаю, к чему вы стремитесь. Чего вам здесь не хватает?
Хороший ответ от Хенрика, но я хотел бы добавить, что в запросе может содержаться довольно много информации, кроме сохранения состояния с помощью файлов cookie. Подумайте о важных заголовках HTTP, таких как accept, language или даже X-REQUESTED-WITH. Большинство веб-фреймворков объединяют эту информацию в одну удобную структуру данных. К сожалению, из приведенных ответов я должен сделать вывод, что drupal нет.