Please Sign In or Register

テーマ変数(node.tpl.php)

テンプレート内で動的な内容を表示するためには、変数を用いて <?php print $variable; ?> のように、PHP コードで記述する必要があります。
また、if 条件式などを使うことで、表示内容をコントロールすることも可能です。

node.tpl.php で使用可能な変数と返される内容は以下の通りです。

変数が返す値は、導入しているモジュールや適用している日本語翻ファイルなどの環境によって異なる場合もあるかもしれません。

コンテンツの設定内容や状況を表す変数

返された値をそのまま出力するのではなく、条件分岐のために使用します。

$page
現在のページが、ティーザーリストまたはコンテンツの単一ページのどちらであるかを判定します。
フロントページを含むティーザーリストページの場合、"$page == 0" となります。
$status
コンテンツの掲載状況を判定します。
掲載されている場合は "TRUE" を、そうでない場合は "FALSE" を返します。
$sticky
コンテンツの掲載状況を判定します。
掲載位置がリスト上部に固定されている場合は "TRUE" を、そうでない場合は "FALSE" を返します。

テンプレート内で内容を出力するために使用される変数

返された値はそのまま出力するだけではなく、条件分岐などにも使用できます。

$id
表示されているコンテンツに割り振られた番号を返します。
最初のコンテンツの番号は "1" で、その後 1 ずつ加算されます。
$zebra
表示されているコンテンツに割り振られた番号が奇数("odd")か偶数("even")かを返します。
$picture
[管理セクション] → [テーマ] → [設定] で投稿でのユーザアバターが有効になっている場合に、ユーザアバターの内容を返します。
<div class="picture">
  <img src="/files/picture/photo.jpg" alt="○○さんのユーザアバター" title="○○さんのユーザアバター"  />
</div>
$title
コンテンツのタイトルを返します。テキストのみでリンクはありません。
$node_url
コンテンツの URL を返します。
URL エイリアスが設定されている場合は、URL エイリアスを返します。
$content
コンテンツの内容を返します。
ティーザーリストページではティーザー部分を、コンテンツ単一ページではコンテンツのすべての内容を返します。
$name
コンテンツの投稿者名をリンクを含めて返します。
<a href="/user/1" title="ユーザプロフィールの表示">admin</a>
$date
コンテンツの投稿日時を返します。
$submitted
コンテンツの投稿者名および投稿日時を返します。
日付のフォーマットには、日付の表示形式(M) が適用されるようです。
投稿者: <a href="/user/1" title="ユーザプロフィールの表示">admin</a> 投稿日時: 2007-06-17 (日) 00:00
$terms
コンテンツが関連付けられているカテゴリの配列($taxonomy)をリストとして返します。
カテゴリにはそのカテゴリを示す class が設定され、さらに最初と最後のカテゴリには、それぞれ "first" "last" の class が割り当てられます。
また、 リンク先のパスに URL エイリアスが設定されている場合は、URL エイリアスがパスとして設定されます。
<ul class="links inline">
  <li class="first taxonomy_term_3"><a href="/taxonomy/term/3" rel="tag" title="" class="taxonomy_term_3">ニュース</a></li>
  <li class="taxonomy_term_11"><a href="/taxonomy/term/11" rel="tag" title="" class="taxonomy_term_11">備忘録</a></li>
  <li class="last taxonomy_term_17"><a href="/drupal" rel="tag" title="" class="taxonomy_term_17">Drupal</a></li>
</ul>
$taxonomy
コンテンツが関連付けられているカテゴリの配列を返します。
カテゴリに関連付けられているかの判定を行う場合には $terms ではなく $taxonomy を利用します。
$links
$node->links の配列の内容をリストとして返します。
それぞれのリストには、内容に応じた class が割り当てられ、さらに最初と最後の項目には、それぞれ "first" "last" の class が割り当てられます。
<ul class="links inline">
  <li class="first comment_add"><a href="/comment/reply/7#comment-form" title="このページに新規コメントを追加" class="comment_add">新しいコメントの追加</a></li>
  <li class="last node_read_more"><a href="/info/7" title="この投稿の全文を読む" class="node_read_more">続きを読む</a></li>
</ul>
$node
$node オブジェクトの内容を返します。
そのまま使用するのではなく、以下のような形式で、必要な内容を取り出して使います。
  • $node->nid --- コンテンツ ID
  • $node->type --- コンテンツタイプ
  • $node->created --- コンテンツの投稿日時

改定履歴

[ 2007-06-18 ]
$id および $zebra の 2つの変数を追加しました。

トラックバック

トラックバックは承認後に表示されます。

URLから "-nospam" を削除してトラックバックを送信してください。

コメント

ありがとうございます

いつも重宝させていただいています<(_ _)>

$tabsがnode.tpl.phpで使えると、判りやすくていいんですけど・・・。
そうすれば、今抱えている悩みがスッキリ解決するのになぁ・・・。
もしかしたら、使えたりして(^_^;)

デフォルトでは使えそうにないかも…です。

themes/engines/phptemplate/phptemplate.engine ファイルの、
function phptemplate_page() で定義してあるものが page.tpl.php で使える変数で、
function phptemplate_node() で定義してあるものが node.tpl.php で使える変数となるのだと思いますから、デフォルトで使えるのは(たぶん)上記のものだけだと… 他にも見逃しているものがあるかもしれませんが…
デフォルト定義されていない変数は、自分のテーマの template.php に定義するということになるのですが、$tabs を定義したとして、上手く動作するかどうかは未確認です。

デフォルトでは使えませんでした

デフォルトでは使えませんでしたね。
実のところ、試しにやってみたりしたのですがなにも吐き出されませんでした。

page.tpl.phpで、個別ページのタイトルと$tabsを記述するのがややこしい元ですね。
システム的な流れとしては、その方が合理的なのかなとも思いますけど・・・。
抜粋版のリストはコンテンツの一定条件下での抽出部分の繰り返し表示ですから、この部分を切り離す方が遙かにスッキリしますからね。
でも、その分、とらえ方が難しくなります(T.T)
最初、どうも、この考え方が納得いかなくて苦労しました(笑)
node.tpl.phpを抜粋版のために使い回すにしても、抜粋版用と個別ページ用を振り分ける条件分岐を記述することは可能なのですから、$titleや$tabsもnode.tpl.phpで記述した方が判りやすさという意味でもシステムの流し方的に見ても合理的なような気がしてます。
ただ単に、過去の負の遺産を引き継いでいるだけなのかもしれませんけどね・・・。

管理ページの取り扱い

$title と $tabs は、管理ページ以下でも使用されているものなので、node が存在しない場合のことを考慮して page.tpl.php で使用されるものとされているのではないかなと思っていたのですが、どうなんでしょうね?
管理ページもそれぞれが node として扱われるのであれば、node.tpl.php で記述できた方が確かに便利っぽいですよね。

実際には試してないので出来るかどうかはわかりませんが、$title と $tabs を node.tpl.php でコントロールすると考えると、こんな感じのイメージになりました。

  • template.php で node.tpl.php で $tabs 変数が使えるように設定する。
  • page.tpl.php では $title と $tabs は使わず、node.tpl.php に記述する。
  • page-admin.tpl.php で、管理ページ用に $title と $tabs を利用したテンプレートを作成する。

合理的なシステムだとすれば

$title と $tabs は、管理ページ以下でも使用されているものなので、node が存在しない場合のことを考慮して page.tpl.php で使用されるものとされているのではないかなと思っていたのですが、どうなんでしょうね?

ワタシはたぶん、逆に個別ページと同じインターフェースを使って管理ページを作っているのではないか?と思っています。
xoops(最新版は判りませんが2.1xあたりは)をいじってみたことが有れば違いがわかるとは思うのですが、xoopsは管理ページは独自のインターフェースを採用していて、テーマデザインの影響をほぼ受けません。
それに対してDrupalは管理ページと言えどもテーマデザインの影響を受けています。あまつさえ、最近のDrupalでは管理ページに使うテーマすら別に設定できるようになっています。
そう考えたときに、個別ページを表示するインターフェースと同じ仕組みを用いているのではないか?と推測しています。
また、システム的には、同じインターフェースを使った方が合理的で効率的なコーディングが出来ると考えられるので、この可能性の方が高いような気がします。
ま、ソースコードを読んでも理解できないので実際のトコロは判りませんが(笑)

page-admin.tpl.phpはたぶん、無くても大丈夫ではないかと思います。思っているだけですが(^_^;)
必須だったら、ワタシが思っているほど合理的・効率的なシステムにはなりきってないと言うことなんだと思います。
ま、何でも合理化・効率化すればいいというモノでもないのでアレですけど(笑)

page.tpl.php と node.tpl.php

ワタシはたぶん、逆に個別ページと同じインターフェースを使って管理ページを作っているのではないか?と思っています。

Drupal のインタフェースは、page.tpl.php + node.tpl.php の両方を使用していますが、管理ページで出力される内容は各モジュールに記述されているものを吐き出しているだけ(これがネックで、管理ページのレイアウトが崩れやすいのが悩みの種なんです。)なので、やっぱり node.tpl.php は使用されていないのでは…と、試してみました。

方法としては、node.tpl.php の適当な部分に適当な文字列を記述して、管理ページで表示されるかどうかという程度の判定ですが、やはり各コンテンツには表示されるけれど、管理ページでは表示されないので、管理ページは node.tpl.php ではコントロールできない = node として扱われていないということだと思います。

ということで、$title と $tabs を node.tpl.php に記述して page.tpl.php には記述しないという場合には、管理ページでタイトルやタブが非表示になってしまうので、page-admin.tpl.php を別途作成するところまでのすべての手順が必要な気がします。(それで上手くいくかどうかは未確認ですが…)

あー、失態(^_^;)

検証までしていただいて、ありがとうございます。

正直に言いますと、先週の金曜日にお返事を書き入れた(?)のですが、どうやら、プレビューまでやっといて、送信してなかった模様です(苦w)
土日の段階で気がついたのですが、仕事場と違い、蒸し暑い我が家ではもう、なにもする気が起きず(ヲイ)に、あー、行動しなきゃなーという気持ちだけで終わってしまいました。ごめんなさい。

話がそれてしまいますが、手前のサイトにdiykitの仕組みなどというメモ書きを勝手に作らせていただきました。これもpage.tpl.phpの$titleと$tabsの説明も変更した方がよいですね。
それと、上記の内容に、このサイトのdiykitのページでの0829さんの説明をそのまま転記した部分が多々あります。
まずいようでしたらその旨言ってください。自分の言葉と差し替えます。

ということで、$title と $tabs を node.tpl.php に記述して page.tpl.php には記述しないという場合には、管理ページでタイトルやタブが非表示になってしまうので、page-admin.tpl.php を別途作成するところまでのすべての手順が必要な気がします。(それで上手くいくかどうかは未確認ですが…)

これはきっと、最初にpage.tpl.phpがあって、そこから発展したんでしょうね。歴史的な互換性の維持をしてきた結果なんですかね。
もしも、page-admin.tpl.phpを別途作ることで上手くいくのであれば、逆に言うと、スッキリとした形になるような気がしますね。テンプレートが判りやすくなるような気がします。
ちょっと、バテているようで、試すまで気力があるかどうか未知数ですが(^_^;)

お疲れ様でした。

暑いというよりは熱いという方がピッタリという気温ですからね、今年は。
あまり無理をなさらないよう、ご自愛ください。

diykitの仕組みなどというメモ書きを勝手に作らせていただきました。

拝見させていただきました。
お手数をおかけしまして申し訳なかったです。本当はこちらで用意しなきゃ…なモノでしたね。
本当は公開する時に作成しようかと考えていたんですが、ボリュームが多くなりそうだったので、どうしたものかなと思っただけで終わっていました。
内容には責任が持てないということをご了承いただいた上であれば、転載とか引用などは自由にしていただいて構いませんので、全く問題ありません。
というか、物書きではないので、問題となるような内容(参照させていただいているものは別ですが…)があるわけでもないですしね。

page-admin.tpl.phpを別途作ることで上手くいくのであれば、逆に言うと、スッキリとした形になるような気がしますね。
テンプレートが判りやすくなるような気がします。

個人的には、page-admin.tpl.php は管理者だけが関わるページなので、あった方が、自分本位でレイアウトできて便利な気がします。
ま、それでも一長一短があるのでしょうけど…

nodeなので・・・?

いつも、ワタシの戯れ言におつきあいいただきまして、ありがとうございます。

手前のサイトでアドバイスいただいたdiykitのカスタムブロックの件、適用してみました。
まだ、ワタシだけが適用できるようにして、裏でテストしてますが、大丈夫なのようですね。ありがとうございます。
ちなみに、templete.phpに追記するのはやはり、nodeだから?pageに追記する分には必要ないのかな?
さらに、ちなみに、ここ(のbookのページ)で表示されている「関連のあるドキュメント」って、オプショナルモジュールですか?標準添付モジュールですか?
この手の奴って、全然気にしてなかったので情報不足です(T.T)良かったら教えてください。

diykitのメモ書きの件、ありがとうございます。ま、問題にならなければワタシとしては言うことはございませんので・・・(^_^;)
実際には描いたイメージは全然違うのですが、HTMLで表現しなければいけない、しかもDrupalのコンテンツの中でとなると・・・と悩んだ結果、あのような形で一段落してしまいました。どの行がどのような動きをしているのか・・・は確かに必要だなとは思ったんですけど、それとは別に、別れているファイルはどのようなタイミングで読み込まれるのか・・・ってのを伝えたかったんですよね。本当は。
ワタシが理解するのに一番苦しんだのは例えば、node.tpl.phpがどこで読み込まれるのか、block.tpl.phpがどこで読み込まれるのか・・・と言うことでしたが、それを知るためには例の$titleと$tabsがpage.tpl.phpとnode.tpl.phpに存在する意味を知らなければならなかったことです。
このへんは、0829さんのおかげでなんとか峠を越えることが出来たのです。
おそらく、diykitを理解しよう(diykitに限らずDrupalのphptempleteエンジンを?)するときには、必ず壁になりそうな気がしたので、これから触ろうって言う人のためにもなにか残しておければなーってのが始まりでしたから。
ま、流れの方はコメント文を各行に入れて掴んだので手間だけはかかってしまいましたけど、それが判って、$titleと$tabsも理解できるようになったし。
ま、苦労した分の実りもあったので良しとしてます。

個人的には、page-admin.tpl.php は管理者だけが関わるページなので、あった方が、自分本位でレイアウトできて便利な気がします。
ま、それでも一長一短があるのでしょうけど…

page-admin.tpl.phpは、存在した方が頭の切り替えが出来て良さそうな気はしますよね(使えればの話ですけど)。
page-admin.tpl.phpだけ、2ブロックとかを前提に作ってもいいのだし。
そう言うコンテンツで吐き出される内容に影響を受けにくい仕組みに作ることは可能になりますからね。
ま、すべてのモノを満足させることは永遠に不可能でしょうから、とりあえず、最大公約数的に・・・と言うことを目標にするしかないですよ。

追伸:手前の体の心配までしていただいて、申し訳ありません<(_ _)>昔から気温の変化に弱いのです(T.T)まだ、風邪を引いたような状態になっていないのがせめてもの救いですが、一日おきに変わったりするとちょっと、悲鳴を上げそうです(^_^;)

node なので、です。

ちなみに、templete.phpに追記するのはやはり、nodeだから?pageに追記する分には必要ないのかな?

phptemplate.engine ファイルの 108~119 行目くらいに、page.tpl.php でブロックを表示するための変数が定義されている(と思われる)ので、case 'node': 部分に記述するだけで大丈夫なはず…です。一応、動作確認もしましたし。

「関連のあるドキュメント」って、オプショナルモジュールですか?標準添付モジュールですか?

ちょっと前に紹介させていただいたのですが、Similar By Terms というモジュールを利用しています。
モジュールを紹介した手前、このサイトでも実際に使用させていただいているのですが、Views モジュールが導入されているのであれば、「 関連性 = コンテンツタイプ+カテゴリが一致するもの 」 というような、より詳細な設定を行えますので、(本当は)そちらの方がオススメです。

「関連のあるドキュメント」ブロック

なにもやる気が起きない不届きモノです(苦w)

phptemplate.engine ファイルの 108~119 行目くらいに、page.tpl.php でブロックを表示するための変数が定義されている(と思われる)ので、case 'node': 部分に記述するだけで大丈夫なはず…です。一応、動作確認もしましたし。

ワタシには仕組みが理解できていないのでなんですが、とりあえず、動いているようですから、良しとしましょうか(^_^;)

ちょっと前に紹介させていただいたのですが、Similar By Terms というモジュールを利用しています。

アレは確か、termで括る奴でしたよね?
viewsの方は高機能な分、未だに理解できないのでワタシには高嶺の花という感じです(T.T)
related linksもSimilar By Termsと同様なモノですが、ちょっと高機能(?)かな?
日本語化に手を出しておいて途中で放置してあるのでもう、どんな機能だったか忘れてますけど(^_^;)
何はともあれ、あんな感じのリンクが欲しい今日この頃ですね。

Views…

やっていることを表に出せていない無精モノです…

アレは確か、termで括る奴でしたよね?

そうです、そうです。term が一致すもののうち最新の何件かを表示してくれます。

viewsの方は高機能な分、未だに理解できないのでワタシには高嶺の花という感じです(T.T)

確かにちょっと難しいですよね。私も正直よくわからない部分がありますし。
でも、Views を使えば、コンテンツタイプで括るタイプやカテゴリ区分で括るタイプのモジュールでできる大抵のことができるはずですから、Views でできることを他のモジュールにさせてしまうのは、リソースの無駄遣いっぽい気もしてしまいます。
ま、そんな大した問題ではないのでしょうけどね。

いつか、このサイトで紹介しているモジュールと、それを Views で実現できるかどうかの一覧表のようなものを作りたいなとか思ったりしてるんですけどね。
もちろん、じゃあどうやるの?も含めて、の予定ですが、いつになるかはかなり未定です。

せめて解説文献が欲しいところです・・・。

確かにちょっと難しいですよね。私も正直よくわからない部分がありますし。

できる!views・・・みたいな書籍が必要な気がしないでもないですが(^_^;)
ま、たぶん、用語の問題なんだと思いますけど。
技術者向けと言った感が否めなくもないですけどね。アーギュメントとか、一般のユーザーにはなんのことやら判らない単語です。そう言う部分もあるんだろうとは思います。
viewsが導入されていれば大抵のことは出来てしまう。
で、似たような機能を持つモジュールをインストールするのはリソースの無駄である・・・。
確かに、そうなんですが、見方を変えるとちっとも理解できずに試行錯誤を繰り返すことになるviewsにチャレンジしていると時間というリソースが無駄になるという見方も出来ます。
特に、実現したいことが明確で、それに満足できる他のモジュールが存在した場合はなおさらです。
昔、PCのことを「パソコン、ソフトなければただの箱」なんて言われていた時代がありましたが、まさにviewsも同じようなモノで高機能でなんでも出来るんだけど、その分、使いやすくするためのUIが用意されないとまさに、この言葉と同じ状況になりかねない。そんな気がしてます。
出来ることならばviewsのUIが進化してくれるのが理想ですが、それはトレードオフの部分が必ずありますから、せめてviewsの解説や入門のような文献が生まれるのがいいのではないか?と感じます。

確かにそうですね。

アーギュメントとか、一般のユーザーにはなんのことやら判らない単語です。

引数とかパラメータとか他の単語にすればよかったですかね?って、きっとそういう問題ではないですね…

viewsにチャレンジしていると時間というリソースが無駄になるという見方も出来ます。

目的を達成するための過程が、その結果によって還元されるかどうかは重要な問題ですからね。
結果だけを求めるのか、作業過程で得られるものも考慮に入れるのかでリソースの見方は大きく異なると思いますが、「モジュールを追加すれば重たくなる = Drupal は使えない」 と思わないためにも、冗長となるモジュールは外せることを知っておくということが大切かな…という、そんな気持ちです。
知っていて敢えて行なうのは全く問題ないと思っています。現に私もそうしている部分が多々ありますし…

出来ることならばviewsのUIが進化してくれるのが理想ですが、

データベースとか嫌いではなかったのでそこまで抵抗はないのですが、Views の UI を進化させるとなると、AJAX を取り入れて MS Access のような UI にするというようなことができれば、使用経験のあるユーザも多い(だろう)のでわかりやすくなるかもしれないですね。
MS Access であれあば、アーギュメントは抽出フィルタに近いイメージになるかな…

views・・・うーん

引数とかパラメータとか他の単語にすればよかったですかね?って、きっとそういう問題ではないですね…

用語の問題も無いわけではないと思いますが・・・

データベースとか嫌いではなかったのでそこまで抵抗はないのですが、Views の UI を進化させるとなると、AJAX を取り入れて MS Access のような UI にするというようなことができれば、使用経験のあるユーザも多い(だろう)のでわかりやすくなるかもしれないですね。

ワタシの場合は仕事柄、DBを使うこともありましたが、おそらくはDBの用途が違うので使っているアプリケーションもまるで違うモノだと思います。
ワタシの場合は、データ処理よりも印刷出力のためのDBという使い方なので、アプリケーションにはMS ACCESSは使いませんでした。いや、正直に言うと使い物になりませんでした。
MS ACCESSは印刷出力のための処理が大味であったと言うことと、いくつものステップが必要で、仕事内容(ワンタイムの仕事が多い)の割には手間が多くなりがちなので不向きという判断です。
で、私が使っていたようなDBアプリケーションとMS ACCESSのようなDBアプリでは正反対と言っていいほど仕組みや造りが違うモノでした。
この辺が、ワタシがviewsを理解できない最大の理由かもしれません。
後は、やはり、説明や、事例が殆どないのでviewsで設定に使う設定値や項目が理解できないことでしょうか。
この辺は、おそらく技術系に明るくない人には共通して有ると思います。
だから、用語云々もあるでしょうけど、それ以上にやはり、説明・解説やサンプルと言った事例のなさが最大の要因なのだろうと思います。
理解するためのヒントすらない・・・と言ったトコロかもしれません。

「モジュールを追加すれば重たくなる = Drupal は使えない」

はっきり言っちゃうと、Drupalは軽快です。ま、某xoopsと比較したらですけど。
Drupalで重くなったと言っても、しょせんはたかがしれます。某xoopsは平均的に重いですから。
Drupalが使えないと言われる要因があるとしたら、やはり日本語の情報、フロントページの好み。そんなところだろうと思います。
それ以外はそれほど違いが大きいとは思えません。運用する側の嗜好でどうにでも変わるモノですから。
あー、後は、運用環境のスペックと言うところですかね。D6xになればもしかしたらホスト環境(MySQLのバージョン)の変更によって"使えない"ということもあるかもしれませんね。

その間に relatedviews というモジュールがリリースされていたようですね。

viewsそのものですら理解できていないワタシにはこのモジュールがどういった役に立つモジュールなのかいまいちピンと来ませんが、term括りをviewsで実現させるためのアドインフィルターと言うことなのでしょうか?
落として使ってみればいいのでしょうけどviewsそのものが理解できていないので、果たして理解できるのかどうか・・・。
何となく、viewsがトラウマになりそうな・・・(T.T)

無理に使う必要もないと思いますけど…

MS Access は、なんとなくユーザが多そう…という単純な理由から例に挙げただけですので、MS Access を理解している = Views が理解できるというわけでもないような気がします。
ただ、どんなものにしろ、データベースを使用したアプリケーションの中身に触れたことがあれば Views もイメージしやすいかな…という、そんな風には思っています。

はっきり言っちゃうと、Drupalは軽快です。ま、某xoopsと比較したらですけど。
Drupalで重くなったと言っても、しょせんはたかがしれます。某xoopsは平均的に重いですから。

私も、軽快だと感じてはいます。
それでもモジュールを多く導入するとホワイトスクリーンになりやすくなったり(このサイトのことです)して、memorylimit を増やさなければ快適とは言い難かったりしましたから、そうならないためにも、重複する機能を持つモジュールは併用せずになるべくシンプルに使えたらいいなと、そういうことですから…
Drupal が使えないと思われる理由についてではなく、より快適に動作させるためにはという意図でした。

何となく、viewsがトラウマになりそうな・・・(T.T)

私は特に、Views をオススメとしているのではなく、単一のモジュールでできることの多くが Views でもできそうだと感じているので、大きな選択肢として、1) Views で設定していくという方法と 2) 単独の機能を持つモジュールをたくさん組み合わせて使うという方法との 2通りがあるのではないでしょうか?ということと、そうであれば(そうであると思っているので)、重複したモジュールを組み合わせて使っているよりは、シンプルに設定できている方がなんとなくいい感じがしませんか?ということを書きたかっただけで、わかりにくいモジュールをわざわざ使う必要はないと思っています。
そのために同じような機能を持ったモジュールがたくさん存在しているのでしょうから。

Similar By Terms よりは Views で詳細設定した方がより自由度が高いということでオススメとさせていただきましたが、これは、他に同等の機能のモジュールを知りませんでしたので、モジュールとしてではなく、表示される内容としてより期待される内容を表示できるのではないかという意味です。

本音と建て前(苦し言い訳と言います)

MS Access を理解している = Views が理解できるというわけでもないような気がします。

スミマセン。おっしゃるとおり、イコールではありません。
ワタシは逆に、MS ACCESSが判れば、viewsも判りやすいのかな?と。
事実、ワタシは国産の某桐とか、DBProというRDBを使っていましたが(過去形なのは、今はその業務をしていないからです)、MS ACCESSとはまるで違うので、それらを使っている分にはviewsは理解しづらいかな…と思った次第です。
だから、クエリーという概念を持ったDBMSでないと、viewsは理解できないかな…と思った次第です。

ホワイトスクリーンになりやすくなったり(このサイトのことです)

でも、不思議なんですよね。
ワタシは、おそらく、このサイトではかなりログを汚している方だと思うんですけど、過去に数えるくらいしかホワイトスクリーンには遭遇したことがないんですよね。
たまたま運がいいだけなのか、アクセス経路によって影響を受けるのか?判りませんが。

わかりにくいモジュールをわざわざ使う必要はないと思っています。

ごもっともです。
アレですよ、きっと。
トラウマになりそうとか言っている割には、まだあきらめてないんですよ、心のどこかでは。
だから、「もう、おらにはわかんねーだ!」とかのたまわってる割には、「なんとかつかえねーかなー、あれ」みたいな気持ちなんだと思います。
ま、言い方変えれば「往生際が悪い」とでも言いますかね(笑)
もっと別の言い方をすると「0829さん、viewsの入門テキストでも書いてくれないかなー」ですね(^_^;)
声に出しては言いませんけど(言ってないだけで書いてちゃ意味がない)

で、ふと思ったんですけど。
ここって、[node.tpl.php]についてのコメント欄なんですけど、すっかりviewsのコメントばっかりにしてしまってるんですが…ご迷惑おかけしてます<(_ _)>
comment_mover-5.x-1.x-dev.tarって言う(モジュール)ので、コメント移動できますので差し障りがあったら移動しちゃってください<(_ _)>

問題ないですよ。

サポート板などであれば「別スレッドで…」ということになるのでしょうが、コメント=話が脱線しても OK と考えていますので、気にしないでください。

と、データベースと一言で言ってもなかなか範囲が広いですからね。
Views の場合は MySQL なので RDBMS のことが多少は理解できていないと難しいのかもしれませんね。どこまで…というのはこれまた難しい問題なのでよくわかりませんが…
なんとなくわかってくれば、リレーションを気にせず(というかそこまで複雑な構造ではないのでアレなのですが…)作業できることや SQL 文を記述する必要がないということは、それだけでもなかなか便利だと、きっと感じられると思います。

「0829さん、viewsの入門テキストでも書いてくれないかなー」

あ、やっぱりでしたか。
うすうすそんなことを思われているのではないかと感じてはいましたが、図解にしないと難しそうなのでそーっと触れずに来てしまいました。
あまりトラウマになってもいけませんし、Views については他のことも含めて整理しなきゃなとは思っていますので、なるべく近いうちに一歩踏み出したいと思います。

やりたいことがたくさんあるし、実際やってたりもするんですけど、表に出さなきゃ意味ないですからね。
もうちょっと気合入れて頑張ります。明日から涼しくなるそうですし…

本当に、スミマセン

本当に、スミマセン

おねだり野郎になりたくないので安易におねだりせずに、極力自助努力でと思って頑張っていますが、やはり限度はありまして、多少なりとでも理解している方にすがりたくなってしまいます。
そう言った意味では、もう、何度となくわがままを聞いていただいているので本当に申し訳ないです。

図解にしないと難しそうなので

別な話ですが、ワタシが手前のサイトでさせていただいたdiykitのメモ書き。
アレ作っているときに、実は同じ事を思っていたのですよ。自分が本当に「ここ、大事だよ」って、思っていたのが、

  • どこでそれぞれのtpl.phpファイルが読み込まれているのか?
  • どの状況の時に、どこが出力されているのか?

っていうことでした。その辺はここでも色々0829さんとあーでもないこーでもないって、やらせていただいたくらい、ぱっと見ただけでは判らない部分でしたからね。
それから、Geeklogをかじったときに思ったのが、テーマデザインが分割されているのって、どの状態の時にどのファイルの部分が、どこで読み込まれているのかが判らないって言うことでした。
Drupalもテーマデザインが分割されているので、流れを把握することが課題になるはずなんです。
本当はこの辺がメインにメモ書きしたかったんですけど、文字だけだと・・・なぁ。
って、思ってました。だから、どうした物かな・・・と。
やっぱり、文字だけでは限界がありますね。
件のコンテンツも図解入りにしないといけないかもですね。

明日から涼しくなるそうですし…

とりあえず、今日は暑いです(T.T)
よるがなかなか寝付けません・・・。

いえいえ。

いえいえ、あまりお節介なのもどうかと、ちょっとだけ思ったりしていただけですから。
いつかは作成しようと思っていたものですしね。気にしないでください。

テーマについても、どの部分がどこに読み込まれるのかなどは、やっぱり図解でないと…というのはかなり前から思っていました。が、図解ってちょっと面倒なのでスルーしてました。
スクリーンショットもそのままではなくて、ちょっと何かを書き添えた方がわかりやすいとか…本当はわかってるんですけどね。
なかなか気持ちについていけていません。

ちょっと期待していたんですが、そんなに涼しくはないですね、今日も。

追記。

昨日一日、No インターネットの生活を送っていたのですが、その間に relatedviews というモジュールがリリースされていたようですね。

コメントの表示オプション

お好みの表示方法を選択し、「設定の保存」をクリックすると、表示方法を変更することができます。