今年の夏は、エジプトでダイブマスターを取って、いつでもダイビングインストラクターで働けるようにしようと思っていたのですが、いろいろあって、ハワイのハワイ島に来ています。

多くの人と話していると、「いいなー、ハワイ。リラックスできて。」と言われますが、まったく持ってリラックスなんてできないです。なんつーか、ブルーワーカー状態です。そして、ボランティアに積極的に関わっています。そのために、来たわけではないので、本業もしっかりしないといけない。。。さて、実際に、ボランティアをしなかったら、引き篭もりになって、あまり人と話さないんだろうけど、おかげさまで、いろんな人に会う機会をいただいています。しかし、リラックスだけなら、京都にいたときの方がリラックスしていたと思います。

最近はいろいろ頼まれごとが多く、肉体労働も兼ねたお手伝いをしています。こうやってボランティアで社会に、コミュニティに、いいことをしていると、なぜかいろいろな人に助けてもらうことができることに気づきました。

昔は私もおせっかいで、いろいろ人を助けるのが好きだったのですが（美化しすぎ）、ここ8年ほどフリーライダーに近い状態になり、「自分さえ良ければ、いいや」と思うようになっていました。必死に長時間労働することが、「スマートではないし、自分は無理だなぁ」、なんて思っていたりしました。今でも、「雇われて働くことに関してのみ」、その思いは変わりません。雇用関係にあるのならば、仕事は仕事として、より効率良く、ビジネスライクに付き合うのがいいと思っています。基本的に、啓蒙本は生理的に受け付けなくて嫌いなのですが、最近の仕事啓蒙本なんかは、どんどんドラスティックに仕事をしていこう、という流れがあるように思えます。いや、普通の仕事に関しては、それで私も同意ですし、納得しています。私も、ホワイトカラーな仕事で自己実現なんて、ほとんどの人にはできない、と考えています。（昔、どこかの人事部長を引退をした人の講義を取って、その講義の中で、彼が仕事と自己実現を結びつけることを延々と語ることに、激しく嫌悪感を持ったことを思い出します。）

しかし、雇用関係ではなく、好意として働くこと（ボランティアとか）に関しては、自分の道徳に従い、「義理、人情、難波節」で働くことが、よい人生につながるように感じるようになりました。そして、よきことをしていると、いつの間にか、いろんな人が助けてくれる、ということをハワイで実感しています。

最近の風潮では、いろいろと他の人でもできることは、どんどんアウトーソーシングするのが、いいと言われているなか、このようなボランティアでは、どんどんDIYで解決していきます。そして、彼らが住んでいる社会にとって、コミュニティにとって、役に立つことがあれば、どんどんと助けにいきます。まぁ、何人かの人は、すでに引退した人だから時間を持て余している、とも思うのですが、この行動力はずば抜けています。

そして、彼らは、よき人のネットワークを持っています。よき人には、よき人を紹介して、さらに気持ちのいい活動をすることが出きるような社会を無自覚に作り上げています。アメリカでは、人のネットワークがとても大事だと言われています。会社に仕事を頼んでも、イマイチなものしか返ってこなかったり、全然反応がなかったりなんて日常茶飯事です。個人の裁量が大きいのですね。その代わり、素晴らしい人を知っていれば、それだけで取引コストと機会コストを最低まで落とすことができます。会社よりも、人なんですね。

最初は、表面的なお手伝いをしようと思っていた私も、こちらで、よきことをしている人を手伝うようになっています。そうすると、自分の気持ちも幸せになるばかりか、いろいろ私のために助けてくれるようにしてくれる人がおり、結果的にプラスの方向へ動いているような気がします。そこで、「よき人たれ」というのは、すごく重要なんだな、と気づきました。もちろん、「よきこと」とは、自分の中にある道徳に関してであって、100%皆が同じものを「よきこと」と思っているわけではないと思います。適当だけど、80%くらいかなぁ。

先日、ボランティアのつながりで、ヒロにあるライオンズクラブの人たちの晩ご飯と会合にお呼ばれしたのですが、なかなか興味深かったです。若者はいなくて、半分以上が引退した人たちばかりなのですが、善意で集まった昔の学級組織のような感じでした。いい年こいたオッサンらが、いい関係を築いていている学級組織です。変な表現ですが、懐かしくて、うれしかったです。というか、半分以上が日系人で、名字は、馴染み深いものばかりでした。三世までなると、日本語を話せる人があまりいないですね。

ここ二日通っているベトナム料理のレストランの眼鏡っ子ウェイトレスがかわいくて、通おうかなーと思ってる私は、いろんな人に助けれながらハワイ島のヒロに滞在しています。ぜんぜん関係ないですが、今日は相撲の土俵の屋根の解体作業を手伝いました。きつい肉体労働で疲れました。。。

さて、パート１では、sfGuardPluginのsfGuardUserProfileとsfGuardUserを1対1のテーブル関係でリレーションがあった際に、アドミンジェネレータで一つのモデルをCRUDしているかのように扱う方法を説明しました。

しかし、実はこのアドミンジェネレータの方法は、symfony1.1的には、フォームの使い方が古いんですね。symfony1.1からは、sfFormクラスを使ってフォームを作るように、方法が変わったのです。なので、form_tagとかのヘルパー関数を使うのではなく、sfFormクラスの拡張クラスを使うことになります。また、Propelを使用している際には、うまく同期をとってくれるsfFormPropelの拡張クラスを使用することになりますね。例によって、ジェネレータで、ベースクラスと実際の処理を書く空クラスが作られ、それを上書きしていくという方法で実装するようになります。

さて、前提条件をここでおさらいするのは面倒なので、前回のパート１のまま、進めてみます。つまり、schema.ymlにsf_guard_user_profileを用意して、build-allをした状態とします。パート１では、backendとしましたが、今回は、frontendとしてみます。

今回のフォーム作成においては、CRUDのCreationのフォームとその値のデータベースへの登録についてを説明します。

パート１と同じように1対1の関連を持つ二つのテーブルを同時に登録する際の使い方について書きます。モジュール名はなんでもいいのですが、ベタにuserとしておきます。

さて、環境が整いました。ここでフォームの入力可能なフィールドを何とするか決めます。パート１との続きということで、メールアドレス、パスワード、名前、生年月日とします。また、パート１と同じくsf_guard_userのusernameは、メールアドレスを入れる項目とします。パート１では、propel:build-allなどで、モデルを作成した際に、ついでにフォームクラスの雛形も生成されます。lib/form/sfGuardUserProfileForm.class.phpがすでにあると思います。そのクラスsfGuardUserProfileFomの空のメソッドconfigureに、フォームで使用するフィールドを選択したり、そのフィールドのラベルを変更したり、バリデターをつけたりしましょう。

つまり、大きく分けて、次の3つを行います。

1. フォームで使用するフィールドを選択する
2. ラベルを日本語化する
3. バリデーションを追加する

フォームで使用するフィールドを選択する

さきほど、どのフィールドを入力可能とするか、決めました。メールアドレス、パスワード、名前、生年月日ですね。では、さっそく、それをセットしましょう。

誕生日の年の項目は、17歳から60歳の人を対象としてみます。それより若い人、老いた人を対象にしたい場合は、適当に修正してください。

そして、作成したモジュールuserのactions.class.phpにexecuteRegisterメソッドを追加して、Viewファイル、registerSuccess.phpもuserモジュールのtemplates以下に追加しましょう。
actions.class.php

registerSuccess.php

これで、簡単な登録フォームができました。デザイナーの方とフォームのデザインなどを協調的に作業する際には、この$formをこうやって単にechoするのではなく、詳細に書いていくことができるようですが、面倒ですので、ここではしません。

ラベルを日本語化する

さて、パート１のアドミンジェネレータのときと同じく、ラベルがまだ英語になっていますので、日本語に書き換えましょう。sfGuardUserProfileFormクラスのconfigureメソッドの先ほど書いた後あたりに、に次の行を加えて、ラベルをセットします。

バリデーションを追加する

これで、フォームができました。次は、バリデーションです。メールアドレスの項目は、必須で、メールアドレスのフォーマットチェック、ユニークチェックをしましょう。パスワードは、必須項目とするだけにします。nameも必須項目とするだけにします。実際に使用する際には、文字数チェックなども、そのアプリの仕様に基づいて変更してください。そして、ラベルをセットした後あたりに、次の行を加えて、バリデーションをセットします。

最後のsetNameFormatは、パラメータのネームスペースのようなものです。フォームの値がuserというキーの連想配列に入るようにしています。つまり、user[password]とか、user[birthday][year]とかになって、サーバにパラメータが送られてくるようになります。

さて、あとは、actionクラスを修正して、ちゃんとバリデーションが通った際には、保存できるようにしましょう。さきほどは、formという変数をレンダーしているだけでしたので、ロジックを書きます。

ところで、

とあるのですが、それは、まだ実装していませんね。なぜこんなことをするかというと、デフォルトのsfGuardUserのis_activeの値は、trueなのです。なので、セットせずに、保存してしまうとここで登録したユーザがそのままログインができるようになってしまうのですね。確認メールを送信するなどして、ちゃんと有効なメールアドレスを登録しているユーザだけを有効にしたい場合が多くあると思いますので、sfGuardUserProfileFormクラスにsetIsActiveメソッドを追加しておきましょう。確認メールの送り方などは、力尽きましたので、ここでは書きません。

というわけで、sfGuardUserProfileFormクラスは最終的に以下のようになりました。

もう一息です。toArrayとfromArrayを上書きする必要があるのを忘れていました。
sfGuardUserProfile.phpにtoArrayとfromArrayを上書きしてみます。

これで、とりあえず完了です。パート１で使用したアクセサやsaveメソッドは、そのまま使用することで、sf_guard_userとsf_guard_user_profileという二つのテーブルに保存することができるようになります。

ふー。疲れました。

間違いがありましたら、いろいろ教えてください。