4

私はMagentoを初めて使用します。システムを探索するときに気まずいことのひとつは、生成された（X）HTMLページの特定の要素をそれを作成したブロックの名前に結び付けることです。[システム]->[構成]->[テンプレートパスのヒント]を知っています。ただし、これは非常に醜く、ページ上の要素のレイアウトを変更することがあり、すべてのブロックが表示されるわけではありません（テンプレートブロックのみをカバーしていると思います）。

私が試したアプローチはtoHtml()、Mage_Core_Block_Abstractのメソッドを変更して、コンテンツの前後に空の要素を追加することです。

<blockStart xmlns="http://some/url" name="the_block_name"/>
<!-- the block's contents -->
<blockEnd/>

（コアファイルを変更せずにこれを行う方法があるかもしれませんが、これは私自身の使用のためだけなので、今のところこのアプローチは気にしません。ただし、どんなアイデアでも歓迎します。）

.nextUntil()これらの要素は、ブラウザ側でjQueryの関数を使用してdata-magento-blockname、blockStart要素とblockEnd要素の間の要素に属性を追加するのに十分な情報をドキュメントに提供します。次に、これらの属性を使用して、ポインターの下のコンテンツへの完全なブロック名「パス」を含むツールチップをいつでも表示できます。

このアプローチの問題は、Magentoが厳密なDOCTYPEを使用してXHTMLを生成するにもかかわらず、Content-Typeを「text / html」に設定するようにハードコーディングされていることです（app/code/core/Mage/Core/Model/App.php1246行目を参照）。これは、XMLがブラウザによってHTMLの「タグスープ」として解釈され、奇妙なことが起こることを意味します。私のタグの多くは、完全に消えたり、間違った場所に表示されたり、すぐに閉じられなかったりして、他のコンテンツが含まれています。また、ドキュメント内のすべてのHTML要素がDOMに表示されるわけではありません。

App.phpを変更してContent-Typeをapplication/xhtml + xmlに変更しようとしましたが、これによりメカニズムが正常に機能します。ただし、いくつかの重大な欠点があります。

  1. 有効なXHTMLを生成しないアドイン、特にCommerceBugを無効にする必要がありました。Commerce Bugの喪失は、アドインの動作中にそのページとパッケージのXML表示機能に本当にアクセスしたいので、かなりひどいものです。
  2. Magentoに含まれているjavascriptの多くはdocument.write（）を利用していますが、これはXHTMLでは機能しないため、javascriptの例外が発生し、おそらく一部の機能が機能しません。

私のアプローチでこれらの問題の解決策を知っている人はいますか、または出力内のHTML要素をそれらを生成するMagentoブロックにリンクする簡単な方法を知っていますか？

4

2 に答える 2

2

テンプレートパスヒントを使用する場合、要素を調べてから、ChromeDevToolsまたはFirebugで調べてリストされている関連するテンプレートファイルを見つける必要がある場合があります（これは、多数のインラインスタイルを持つ親要素になります）。

私はgrepを頻繁に使用して物事を見つけます。探していると思われる最も高いフォルダに移動するだけです（何千もの無関係なフォルダ/ファイルをトラバースする必要がないようにするため）。

したがって、ブロック名がわかっていて、そのブロックを使用しているテンプレートファイルを見つけたい場合は、/ app / design / frontend / base / default / layoutに移動して、次のようにします。

grep "catalog/category" -r -l .

そして、そのブロックをロードしているいくつかのファイル名を取得し、それらの宣言ノードを見つけて、どのテンプレートファイルがロードされているかを確認できるはずです。

echo get_class($this)

役立つこともあります。

于 2012-10-05T00:28:54.490 に答える
1

更新しばらく時間がかかりましたが、最後にBlockSpyを提供します：http：//omnicognate.wordpress.com/2012/11/13/blockspy-my-first-magento-extension/

アップデート作業する時間はあまりありませんでしたが、サーバー側の部分が動作するようになりました。イベントハンドラーにblockStart/blockEndマーカーを追加することcore_block_abstract_to_html_afterで、コアファイルを変更せずにそれを実行でき、コメントにそれらを追加することで、HTMLTidyを無秩序に通過させることができます。SAXパーサービットが機能しています。やるべきjavascriptクライアントビットがあります。これは簡単なはずです。アイデアは、CSS XRAYブックマークレット（http://westciv.com/xray/）のスタイルで何かを行うことです。

私はそれがどのように機能するかについての記事にリンクし、それが終わったらこの答えを更新して受け入れます-もちろん、他の誰かが以前にもっと良い解決策を思い付いていなかった場合。

私はこれに対する解決策に近づいていると思います。問題は本当に3つのことに要約されるようです：

  1. Magentoは、信頼できる有効なXHTMLを実際には生成しません。たとえば、JavascriptにCDATAセクションを使用することにはいくつかの矛盾があります。私はいくつかの無効なページに遭遇しました、そして間違いなくもっとたくさんあります。
  2. ページの生成は、純粋にテキスト形式で行われます。サーバーはDOMではなく文字列を操作しているため、サーバー側にマークアップを確実に挿入することは容易ではありません。また、AFAIKは、ブロックのtoHtml()メソッドが常に要素全体のコレクションを生成するという保証はありません。たとえば、テキストを生成するブロックを作成して親ブロックの属性値に埋め込むことや、親ブロックでXHTML要素を開いて子で閉じることを妨げるものは何もありません（ただし、厳しい）。
  3. Content-TypeをXHTMLに切り替えると、サーバーが適切に有効なマークアップを生成するように説得されたとしても、サイトのjavascriptが完全に壊れてしまい、XHTMLで動作するようにすべてを更新する準備ができていません。

次のアプローチでこれらの問題に対処できると思います。

  1. サーバー側で使用PHP::Tidyして、サーバーに有効なXHTMLを生成させます。ハンドラーで実行tidy_parse_string()してこれを試してみましたが、機能しているようです。controller_front_send_response_before
  2. Blockクラスが挿入するblockStart/blockEndマーカーをクライアント側で処理する代わりに、サーバー側でSAX XMLパーサーを使用して、応答を送信する前に処理します。マーカー間のサブストリングを実行し、各サブストリングをSAXパーサーに渡すことができます（マーカーを省略します）。これにより、SAXパーサーが生成するイベントに応じて、状態を維持し、出力XML文字列を構築できるようになります。その後、サーバー側でdata- *属性を安全に（ゆっくりと）挿入できます。
  3. Content-Typeはtext/htmlのままにします。これにより、javascriptが機能し、必要に応じて、data- *属性がクライアント側で無視されます。

少し面倒ですが、私のすべての拡張機能で機能し、JavaScriptを壊さないようにし、ブロックが生成する出力の種類について推測しないようにする必要があるようです。私はステップ1を試しただけです-トリッキーなビットに亀裂が入ったら更新します:-)

于 2012-10-05T17:13:19.687 に答える