Magento Demande - Frontend ou Backend?

Si vous êtes en mesure d'utiliser un observateur, vous pouvez limiter la 'adminhtml événement de la zone.

<config>
...
  <adminhtml>
    <events>
      <core_block_abstract_prepare_layout_after>
        <observers>
          <mynamespace_mymodule_html_before>
            <type>singleton</type>
            <class>mynamespace_mymodule/observer</class>
            <method>adminPrepareLayoutBefore</method>
          </mynamespace_mymodule_html_before>
        </observers>
      </core_block_abstract_prepare_layout_after>
    </events>
  </adminhtml>
</config>

J'aime bip logique de réponse - il de sens que dans le contexte d'observateurs. J'aime aussi Alan point qu'il n'y a aucun moyen de connaître l'état d'administration dans tous les contextes, qui est une fonction de "l'admin" un état, qui est entré après l'application et avant de contrôleur sont initialisés.

Magento administration de l'état est effectivement créée à partir du contrôle de l'envoi à un admin contrôleur d'action; voir Mage_Adminhtml_Controller_Action::preDispatch(). C'est la méthode qui déclenche l' adminhtml_controller_action_predispatch_start événement, qui est consommé par Mage_Adminhtml_Model_Observer::bindStore(), qui est l'endroit où l'admin de la boutique est d'abord "set". En fait, l'observateur de configuration de zones (adminhtml vs frontend) "œuvres" en raison de l'action principale de la classe contrôleur - voir Mage_Core_Controller_Varien_Action::preDispatch(), spécifiquement Mage::app()->loadArea($this->getLayout()->getArea()); - il suffit de noter que l'objet de mise en page a son information sur les alentours situé dans le adminhtml predispatch.

Peu importe comment vous le trancher, l'admin comportement sur lesquelles nous nous appuyons dans de nombreux contextes - même quelque chose de plus haut niveau comme l'observateur d'événements système s'appuie sur la commande de la structure de contrôle.

<config>
  <!-- ... -->
  <adminhtml>
    <events>
      <core_block_abstract_prepare_layout_after>
        <observers>
          <mynamespace_mymodule_html_after>
            <type>singleton</type>
            <class>mynamespace_mymodule/observer</class>
            <method>adminPrepareLayoutAfter</method>
          </mynamespace_mymodule_html_after>
        </observers>
      </core_block_abstract_prepare_layout_after>
    </events>
  </adminhtml>
  <frontend>
    <events>
      <core_block_abstract_prepare_layout_after>
        <observers>
          <mynamespace_mymodule_html_after>
            <type>singleton</type>
            <class>mynamespace_mymodule/observer</class>
            <method>frontendPrepareLayoutAfter</method>
          </mynamespace_mymodule_html_after>
        </observers>
      </core_block_abstract_prepare_layout_after>
    </events>
  </frontend>
</config>

Dans votre observateur définition:

class Mynamepace_Mymodule_Model_Observer
{
    public function adminPrepareLayoutAfter()
    {
        $this->_prepareLayoutAfter('admin');
    }

    public function frontendPrepareLayoutAfter()
    {
        $this->_prepareLayoutAfter('frontend');
    }

    protected function _prepareLayoutAfter($area)
    {
        switch($area){
           case 'admin':
               //do admin things
               break;

           case 'frontend':
               //do frontend things
               break;

           default:
               //i'm a moron
        }
    }
}

tl;dr: Utilisation d'un observateur, même utiliser le même observateur modèle, mais passe dans le contexte en spécifiant un autre appel de méthode.

HTH.

modifier: ajout d'un exemple de code utilisant bip logique de config comme un point de départ