お久しぶりです。
※(注記)なぜかうまく表示されていない(Newもついていないし)のであらためてポストさせていただきました。
カレンダー(モジュール)絡みでいくつか質問があります。
ある団体のサイトを作っており、その中に「複数メンバーのプロフィールページと、それにリンクする勤務表」を作りたいと考えています。
具体的に、ある病院にドンピシャの例があります。
http://pediatrics-chiba-u.org/outpatient.html
ここにあるように、マンスリータイプのカレンダーのそれぞれの日付の担当者名をクリックすると、その担当者のプロフィールに飛ぶようにしたいわけです。
ここのサイトでは、プロフィールページは複数の人が1ページにまとまっていて、ページ内のアンカーリンクに飛ぶようになっていますが、今回、せっかく Drupal で作るのですから、プロフィールは「1名1ページ(ノード)」で作り、そこへのリンクが張られるようにしたいわけです。
サイト自体のメインの「プロフィール紹介ページ」は、その各自プロフィールノードを Views でまとめて、上の病院サイト同様に複数人の概要を1ページにまとめて表示しようと思っています。
ちなみに、ここと同様には担当者は各日あたり一人であり、それがカレンダー上でプルダウンメニューで選択できればベストです。
Views でまとめる云々に関してもまだおぼつかないのですが(それはまた別途)、カレンダーにこのような機能を持たせる方法がまったくわかりません。
実は個人的に、@kenppx さんにご相談していろいろ考えていただきまして、editablefield を使う方法など2種類ほど本当に近いところまで行ってるんですが、残念ながら微妙に求めているのと違うところがありまして。
時間がないこともありまして、ほかの皆様方のお知恵も拝借したいと考えたわけです。
どうぞよろしくお願いいたします。
Comments
プロフィールコンテンツタイプを作る。氏名他、必要なフィール
プロフィールコンテンツタイプを作る。氏名他、必要なフィールドを作成する。
プロフィールノードを一人に一つ作る。
勤務日コンテンツタイプを作る。フィールドは Date フィールド、また node reference 等の、プロフィールノードとのリレーションの定義に使えるフィールドを加える。Auto Nodetitle モジュールなどで、ノードタイトルの入力を不要にすると便利。
一日あたり一つの勤務日ノードを作り、日付を指定し、プロフィールと関連付ける
カレンダービューにて、勤務日ノードの日付フィールドに基づいてノードを引っ張ってくる。リレーションを定義して、勤務日ノードのタイトルではなく、プロフィールノードのスタッフ名を表示する。スタッフ名はリンクにし、クリックすると該当のプロフィールページが表示される。
1日に1ノード割り当てるのは無駄に見えますが、昨日の作成も、編集者にとっても楽だと思います。このノードのデータ量自体少ないので、数年分の勤務日ノードがあっても、それをストアするのに要するディスク領域は微々たるものでしょう。もし不要なノードを持つのが気分的に嫌なのであれば Views Bulk Operation 他で定期的に削除すれば良いと思います。
私の提案した二つの方法
dokumori様、いつもお世話になっております。kenppxです。
今回、私は二つの方法を提案させて頂きました。
作戦1auto nodetileとPrepopulateでその都度ノードを作っちゃうぞ作戦
Auto nodetitleとPrepopulateモジュールを使って、カレンダー上の追加ボタンを押すと自動的にその日付がノードのタイトルとして自動的に入力されるというシステムです。この場合、ノードはその都度作られます。prepopulateモジュールで追加ボタンのリンクを利用して日付情報をedit画面に自動入力する事ができるのでカレンダーモジュールのテンプレートを少し書き換える事で日付情報を拾ってくるシステムにしました。この方法はとりあえず、大まかには実現できました。この方法ですと、1日1ノードではないので、ノードがたくさん生成される事はありません。
作戦2予め1日1ノードを作っちゃう作戦
以前に出勤管理表を作れないかと私自身もこちらでご質問させて頂いた時に、前提として考えていた方法です。あらかじめ、ノードを作っておく訳ですのでeditable fieldなどのモジュールが使えてステキな方法だと思います。ただ、ノードの量が多くなるのでこの方法はアリなのかと私自身悩んでいた所でした。
今回、dokumoriさんのnode×ばつ10年=3650ノードが作られたとしてもさほど問題はありませんか?この辺、私自身も非常に知りたい所でした。不要なノードはvboで削除するという方法も理屈では考えていたのですが、vboとrulesを連携して自動的に削除できたら良いなぁと考えたりと妄想してる段階です。
ちなみに、今後10年分の3650ノードを一括で作るにはvbo等で一括で生成するにはrulesとの組み合わせで実現できるものでしょうか?さすがに手動は無理ですので...。
@kenppx
おお、先日来見せていただいていたの、こういうやり方だったんだ(わかってない^^;)
いずれにしろ、仕組みがイマイチわかっていない僕は、質問することで少しでも「同じようなことやりたい」と思ってる人の助けになればいいと思っていて、これで議論が進展するといいなと思います。
いろいろな方法があるのが Drupal のいいところ(で、難しいところ)なのかなと思ってもいたり。
作戦1、2ともに何とかなりました。
feedモジュールを使って10年分の出勤情報に相当する3600ノードを一気に作りまして、それをカレンダーに表示。出勤者フィールドだけをeditable fieldsで表示し、カレンダー上で編集可能にする事に成功しました。とりあえず、目的のものを作ることはできました。10年分作らなくても1年分(365日)分だけ作って、その後はrulesで1日、1ノードを自動で追加していく様な使用にしても問題なさそうです。dokumoriさんのアドバイスのお陰です。ありがとうございました。
かっこいい方法ですね。 とても参考になりました。ありがとう
かっこいい方法ですね。
とても参考になりました。ありがとうございます。
Rulesでの作成と削除を使うならNodeのままの方が良いと思いますが、
D7のCalendarは独自Entityにも対応しているのでいろいろ試せそうですね。
こんにちは
これ、よく意味がわからないのでよかったら教えて下さい>Rulesでの作成と削除を使うならNodeのままの方が良いと思いますが
消さなくてもいい、ってこと?
あと、最近知った entity という概念もよくわかりません。
本題とは脱線になりますが(ので)もしできたら、それのわかりやすい説明か何かがどこかにあれば、ご教示いただけるとうれしいです。
Calendar もすごく使いやすくなって気はしますが、まだまだぜんぜん使えません。最初の設定がイマイチわからず躓いています。
D7 CalendarのDocument
Shinさんは英語全然OKな方なので、プロジェクトページにあるリンクが一番まとまっていると思いますよ。
D7 Videos/Tutorialsのあたりです。
Calendar
私が見てわかりやすかったのは、Lullabotのページでした。作者のKarenSさんが説明してくれてます。
What's New in Date and Calendar for Drupal 7 | Lullabot
Entityについては、「Drupal7からページ生成に適した形式(Node)以外のデータの持ち方ができるようになった」くらいのざっくりとした理解でいいと思います。今の時点ではカスタムEntityを作る手順も統一されていないですしね。
Webサービスを考えた時、タイトルやボディ、日付、投稿者、リビジョン、NodeIDなどなどが全ての場面で必要なわけではないんです。ただ、これまではそういうデータを独自に作るとViewsなどでは簡単に再利用できないし、管理画面も自分で作る必要がありました。TaxonomyやUser、CommentなどもNode以外のデータなので、Viewsでは今ひとつ痒いところに手が届かない感があります。
Entityは様々なシチュエーションに最適化されたデータを例外扱いせずにDrupal上で扱いたいという要望に応えるための概念です。
RulesでカスタムEntityを操作する場合、ハマりどころがまだまだある気がしますのでNodeでいいじゃないかなという意味でした。
qchan、ありがとうございます!
おお、ここちゃんと見てなかった。もう一度一所懸命見ることにします>Calendar、ララボットのページ
あと、entity についてもありがとうございます。
なるほど、そんな感じでいいんですね。......って理解してない気もしますけど(特に、Views で再利用できない云々......)。
今後はノード以外のいろんなものが簡単に参照することができて、より柔軟な設計ができる(のに寄与する)くらいでいいんですかね、いまのところは。
また、これを機にいろいろ教えて下さい!(さっき dokumori さんにも申し上げましたが、やっと重い腰を......^^;)
逆に、なぜ消さなくてはならないのか?と問うてみてはいかがで
逆に、なぜ消さなくてはならないのか?と問うてみてはいかがでしょう。使われる予定がなく、サイズ的にも問題を引き起こさないのであれば、消さないというオプションもあるのでは。
もちろん、要らないデータは消すに越したことはないですが(特に容量が嵩むものであれば削除は必須になってきます)、消す手間とそのコストや、手違いによる不具合が生じる可能性他を考慮して、どちらがより良いアプローチかを検討するべきだと思います。
ありがとうございます!
意味のない(それ自身に)データを持っておくことは無意味(堂々巡りみたいですが)って単純に思い込んでました。
意味のないって書いたけど、それ自身は「直接は参照しない、閲覧しない」だけであって、作る必要があるんだから意味はあるんですよね。
コスト等を考えて「消さない」という考え方がありうるというのは、僕としては結構ショックだったです(笑)
あと、クライアントさんがどこまで興味を持って見る(見ちゃう)かわからないのですが、このデータの羅列を見て「なんだこれは?」といじっちゃわないかなという、ちょっとした不安があったことはあります(手違いという観点から言えば)。
脱線ですが、やっと重い腰が上がりましたが、dokumori さんから教わったことをほぼ忘れてしまっていて(申し訳ありません)四苦八苦しております。Views なんかは D7 になってかなり変わっちゃった(わかりやすくなった、とも言えるかもしれませんが)ですしね。
いろいろなアプローチがあるといえば、ひとつコンテンツタイプを作るにしても、選択肢はできるだけタクソノミーで作っといたらいいの?みたいなことから始まって、設計中にアプローチがありすぎて悶々としますね。そこが Drupal のいいところなのかもしれないですけど。
「この要素を作っておくと、あとでこんなカタチでデータが使い回しできる」というのが技術的に見えていると、もっとスムーズに行くんでしょうけどねぇ。作ってだいぶ経ってから「あぁ、こうしておけばよかったかも」と思う時がしばしばです。
とにかく今後ともよろしくお願いいたします。
まだ
自分のサイトで動かせていないのでナンですが(^^ゞ、うまく行ったようでよかったです!
おふたりとも本当にありがとうございます!
がんばって作りこみます。
×ばつ10年=3650ノードが作られたとしてもさほど問題
「問題になる」というのが具体的にどのようなことを指すのかにもよりますが、データの量で言えば、このようなシンプルなものであれば1ノード 1KB にもならないのでは、とおもいます。仮に1KB としても 3650 個で 4MB にも至りません。これが問題になるようなホスティング会社であれば、その会社のほうが問題になります。
あとは管理の問題ですが、 VBO 他いろいろな解決法があると思うので、これも問題は無いかと思います。
dokumori
dokumori さん、ありがとうございます!
正直、ちゃんと理解できたとは言えませんが(特に、リレーションを定義して......云々のところ)、いろいろ方法はあるということがわかってよかったし、なんとか調べてやってみようとおもいます。
機能を実現するためには、こういう(一見)無駄なノードやデータを作ることも必要なんですね。
これからもよろしくお願いいたします。
(なんでダブルんだ?^^; で、消せないのがなんとも)
(なんでダブルんだ?^^; で、消せないのがなんとも)