言語を使用する際のベストプラクティスは何ですか?


51

このフォームを使用して、モジュール内のデータにアクセスし始めています。(コメント#1を参照してください。)

$node->field_test[$node->language][0]['value']

私はそれがかなり良い解決策のように見えると思ったが、さらに同じ質問の下で私はこれを見つけ

「und」が言語のないエンティティのフィールド用であると仮定しないでください。また、翻訳可能ではなく、すべてのフィールドであるエンティティ翻訳モジュールのないフィールド用です。さらに、Drupalのさまざまな7.xバージョン間でこれに違いがあります。データが保存されている言語コードの下であなたのために整理する関数
を使用する方が良いfield_get_items()

そして今、私が使用しているものが道を壊すことができるかどうかはわかりません。

回答:


39

Entity APIモジュールを使用すると非常に役立ち、コードが読みやすくなります。上記のコードは、ノードの言語とフィールドの言語が異なる場合があるため、常に機能するとは限りません。

エンティティAPIモジュールとそのラッパーを使用すると、次のコードを使用できます。

 $node_wrapper = entity_metadata_wrapper('node', $node);
 $field_val = $node_wrapper->field_test->value();

これは防弾でなければなりません。エンティティモジュールの使用に関する1つのことは、存在しないフィールドにアクセスしようとすると、通知や間違った動作の代わりに、厄介なエラーと例外がスローされることです。

これを回避するには、次のように試す/キャッチすることができます

try {
  $field_val = $node_wrapper->field_doesnt_exist->value();
} catch (EntityMetadataWrapperException $e) {
  $field_val = 'default/fallback value';
}

または、内部でisset()どのEntityMetadataWrapperハンドルを使用することもできます:

$field_val = 'default/fallback value';
if (isset($node_wrapper->field_doesnt_exist)) {
  $field_val = $node_wrapper->field_doesnt_exist->value();
}

この機能はentity_metadata_wrapper()廃止されましたか?私は自分のモジュールでこれを呼び出してみましたが、Fatal error: Call to undefined function entity_metadata_wrapper()DreamweaverのDrupal 7.12インストールでソース検索を行い、コードの他の場所で0の結果を出しました!
アディティアMP

1
aditya-これはEntity APIモジュールにあり、コアにはありません。
lazysoundsystem

1
@adityamenon怠け者が言っているように、これはコアではない...とはいえ、おそらくDrupal 8向けでしょう。エンティティAPIは少なくとも大幅に改善されるでしょう。本当に、Drupal 7のエンティティシステムに必要なすべてのAPIを作成する時間はなかったので、それがエンティティAPIモジュールが達成しようとするものです。
googletorp

どうもありがとう、私は答えをきちんと読んで、Entity APIプロジェクトページへのリンクをたどらないのは愚かだった:)
Aditya MP

1
entity_metadata_wrapperのソースコードを確認し、フィールド操作を簡単にするためにインスタンス化および拡張されたすべてのクラスを通してウサギトレイルをたどると、それだけの価値があるのだろうかと思います。別の3k +行のコードをブートストラップに追加し、すべての変数の割り当てを処理するためにより多くのメモリを使用します...もっと軽量なものはありますか?それ$node->field_name[LANGUAGE_NONE][0]['value'] = 'foo';が本当に最も効率的な方法だと思われます。
チャーリーシュリーサー

19

読み取りには、常にfield_get_items()を使用できる必要があります。これにより、適切な言語が選択され、フィールドに値があるかどうかも確認されます。

残念ながら、フィールドAPIは7.xで非常に制限されており、たとえば最初のフィールドアイテムを取得する方法はありません。1回の関数呼び出しで値を取得することを敢えて求めないでください...そしてfield_set_items( )カウンターパート。

そのため、エンティティAPIモジュール、かなりのオーバーヘッドを伴うという欠点を持つ優れたAPIを提供します(基本的に、すべての単一の値を、多数のネストされたプロパティ情報配列が付加されたラッパーオブジェクトに変換します)。エンティティラッパーをダンプしようとすると、通常は何も得られないか、読み取り不可能な配列の壁ができます。


1
Drupal 8でこの種のことが改善される可能性があるというあなたの意見から私は印象を受けますか?もしそうなら、これらの種類のものがどのように進んでいるかを知るにはどうすればいいですか?モジュールページを除けば、Doは私にとって迷路のようなものです。:)
クライブ

1
まあ、常に希望があります:)そして、Drupal 8で何が起こっているのかを高レベルで概観することさえ困難です。1つの方法はイニシアチブに従うことです。ただし、これは既存のディレクティブの直接のターゲットではありません。エンティティAPIモジュールの一部がコアに移動/移動されています(現在Entityクラスがあり、既存のエンティティは新しいシステムに変換されます)。そのため、たとえばフィールドを処理するためにそれらのクラスでメソッドを直接取得する可能性があります。コミットされた変更の場合、適切なリソースは新しい変更記録システムです。drupal.org/list-changes/drupalを参照してください。
ベルディール

素晴らしい、それはまさに私が探していた種類のおかげです。:)サイトの話題になっていないという質問を気にしないでください...私はコアに貢献したいのですが、オープンソースに実際に関与したことはありません少し手ごわい...開始するのに良い場所があるのはいいことだ:)
クライヴ

Clive:drupalofficehours.orgをチェックしてください -これは、人々が貢献を始めるのを正確に支援するためのものです。さらなるリソース。また、頻繁にコア開発者が参加するユーザーグループや、コア開発者が1人または2人いるDrupalCampに参加することをお勧めします。groups.drupal.orgでローカルグループを検索すると、解決できるはずです。drupical.orgも役立ちます。
wizonesolutions

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.