弱小PHPerの憂鬱

6日目までのチュートリアルにはapp.ymlの書き方が見つからなかったので簡単に解説。
config_handler.ymlまでやり始めるとよくわからないのでとりあえずはパス。


まずapp.ymlが何かっていうと、自作プログラムでありがちなconfig.phpとかconst.phpみたいなものです。
動的に変更されることはあまりないけど、サイト全体で共有しておきたい設定なんかを格納しておきます。
YAML形式で書くことで、PHPで書くより素人にもわかりやすく、XMLみたいにタグがいっぱいでめんどくさいといったこともない簡単な設定ファイルにすることができます。


app.ymlを置ける場所は複数あります。
config/app.yml
apps/frontend/config/app.yml
前者がプロジェクト全体から呼び出せるもので、後者はアプリケーション単位の定義となります。
使用する際には両者がマージされ、両者で同じ名前がある場合は範囲の狭いアプリケーション単位のほうが優先されます。
後者が置けるのだから当然apps/frontend/modules/***/config/app.ymlでモジュール単位の設定もできるだろうと思ったら何故かできませんでした。


次にYAMLの書き方。
6日目のチュートリアルでは下記のようになっています。
 

1
2

all:
  active_days: 30

トップレベルにはall、prod、test、devの4種類を置くことができます。
allは全環境、prodは本番環境、devは開発環境でのみ設定される内容になります。
testはあんまり使わないのでまあいいや。

要素は半角スペース2つでインデントしたあとに記入します。
:のあとに半角スペースを最低1個置いたあと値を記入すると、それが要素の値となります。
上記の場合はactive_daysの値が30ということになります。

複数のトップレベルに同じ要素を記入した場合、範囲が狭い方が優先されます。
従って最終的な書き方は以下のようになります。
 

1
2
3
4
5
6
7

all:
  hoge: hoge_all
prod:
  name: 本番環境
dev:
  name: 開発環境
  hoge: hoge_dev

sfConfig::get()で実際に値を取得することができます。
app.ymlから内容を取得する場合は、引数のプレフィックスに必ず'app_'が付きます。

開発環境で実行した場合、
sfConfig::get('app_hoge')　　→　hoge_dev
sfConfig::get('app_name')　　→　開発環境
本番環境で実行した場合、
sfConfig::get('app_hoge')　　→　hoge_all
sfConfig::get('app_name')　　→　本番環境
というふうになります。

基本的には、allに全ての設定を記入し、prodで本番時のみ参照したいデータを記述するということになるでしょう。


さて、YAMLを階層構造にすることができます。
半角スペースを2つ増やすたびに一段階深くなります。
カテゴリ毎に情報を纏めたたりする場合に便利なのですが……ここにひとつ落とし穴があります。
 

1
2
3
4
5
6
7
8

all:
  data:       data_zero
  one:
    data:     data_one
    two:
      data:   data_two
      three:
        data: data_three

このようなYAMLがあるとして、階層構造のデータを取得するときは'_'で区切ることで次の階層に進むことができます。
'data_zero'を取得したいならsfConfig::get('app_data')です。
'data_one'を取得したい場合はsfConfig::get('app_one_data')となります。
ここまではいいのですが、では次の'data_two'を取得したければsfConfig::get('app_one_two_data')でいいかと思えば駄目です。
3段階目以降は何故か直接sfConfig::get()することができません。
sfConfig::get('app_one_two')とすることで、それ以下の階層が連想配列で入ってきます。
'data_three'は、$data_two=sfConfig::get('app_one_two');$data_three=$data_two['three']['data'];とする必要があります。

当初これに気がつかずに「値が取得できねー」とさんざっぱら悩みました。
リファレンスに微塵も書かれてないというのはどういうことなのだろうな。


Symfonyの記事一覧

まずDoctrineの検索条件から。
Doctrine::getTable('JobeetJob')->createQuery('a')->execute();
とするとjobeet_jobテーブルの内容が全て取得されます。

getTableでテーブル名を指定し、createQueryでエイリアス名を指定します。
このエイリアス名は作成されるSQLにも出力を扱う際にも全く関係が無く、Doctrine内でカラムやテーブルを扱う際にのみ利用されます。
最後にexecuteで作成したクエリを実行し、取得します。
今回はWHERE句やLIMIT句等を使用していないため、jobeet_jobテーブルの内容が全件そのまま取得されます。

それでは今からクエリを書き換えていきますが、チュートリアルは丸ごと全部書き換えてしまっているのでいきなりハードルが高くてわかりにくいです。
とりあえずさっきのクエリにひとつ条件を書き足してみます。
Doctrine::getTable('JobeetJob')->createQuery('a')->where('a.id = ?',1)->execute();

whereは文字通りWHERE句を指定します。
第一引数に比較する内容、第二引数に具体的な値を記述します。
上記の場合'?'の部分が第二引数の1に相当します。

where('JobeetJob.id = ?',1)と書くとおかしな結果になります。
createQuery('a')で、以後JobeetJobを'a'として扱うと決めたので、その後最初のjobeet_jobテーブルを扱う際は'a'と書く必要があるのです。

上記の結果として、jobeet_job.id=1のカラムだけが取得されることになります。
今回は1ですが、ここにユーザ入力値を突っ込むことで自動的にSQLインジェクション対策になります。
固定値の場合であればプリペアドステートメントにする必要もないので、where('a.id = 1')と書くこともできます。

上記をチュートリアル形式に書き換えてみます。
  $q = Doctrine_Query::create()->from('JobeetJob a')->where('a.id = ?',1);
  $this->jobeet_job_list = $q->execute();

最初に呼び出すクラスがDoctrineクラスからDoctrine_Queryに変わっていますが、実行できることはあまり変わりません。
というか違いがよくわからん。
Doctrine_Query::fromではDoctrine::getTableとcreateQueryが行っていたテーブル名とエイリアス名の指定を一気に行います。
以後はwhereやexecuteを全く同じように書くことができます。

当然ですが$qを介さず、
$this->jobeet_job_list =Doctrine_Query::create()->from('JobeetJob j')->where('j.id = ?',1)->execute();
と一行で書くこともできます。
結局Doctrine_Query::create()とDoctrine::getTable()って何が違うんだ。

ようやくチュートリアルに追いついた。
30日以内に投稿された求人だけ拾ってみましょう。

apps/frontend/modules/job/actions/actions.class.php 

1
2
3
4

  $q = Doctrine_Query::create()
    ->from('JobeetJob j')
    ->where('j.created_at > ?', date('Y-m-d H:i:s', time() - 86400 * 30));
  $this->jobeet_job_list = $q->execute();

単にwhereメソッドが変わっただけですね。
idのときは=だけでしたが、不等号や関数を記述することもできます。

しかし、30日以内とかなら
$q->where('j.created_at > NOW()-INTERVAL 30 DAY ');
のほうが早い気が。

実際に実行されたSQLはブラウザ右上のドラム缶みたいなマークで確認することができますので、見てみるとよいでしょう。


次にモデルを変更してみます。
前slugifyとかを書いたJobeetJob.class.phpです。

lib/model/doctrine/JobeetJob.class.php

1
2
3
4
5
6
7

  public function save(Doctrine_Connection $conn = null){
    if ($this->isNew() && !$this->getExpiresAt()){
      $now = $this->getCreatedAt() ? strtotime($this->getCreatedAt()) : time();
      $this->setExpiresAt(date('Y-m-d H:i:s', $now + 86400 * 30));
    }
    return parent::save($conn);
  }

モデルクラスのsaveメソッドをオーバーライドすればセーブ時の動作を変化させることができるそうです。
そういった流れというか挙動は一体何処を調べればわかるのでしょうか？
あと、よくわからんのだが、シリアライズってこんなところで使う言葉なのか？

$this->isNew()は一度も保存されていないときにtrueを返すと思われます。
Doctrineの各モデルクラスはsfDoctrineRecordを継承しており、sfDoctrineRecord::isNew()に実体があります。
>(boolean) isNew ()
>Function require by symfony >= 1.2 admin generators
どういう意味だ。
こういうのの存在ってチュートリアルが無ければ気付きようが無い気がするんだがどうしてるんだろう？

全体としては、現在のオブジェクトが、一度もセーブしたことが無く、expires_atが定義されていない場合、expires_atを指定して親のsaveメソッドを呼ぶということになります。
2回目以降のセーブ、もしくは既にexpires_atが入っている場合はそのまま親のsaveメソッドが呼ばれます。

せっかくexpires_atを登録できるようにしたので、呼び出す場合もexpires_atを利用するようにしましょう。

apps/frontend/modules/job/actions/actions.class.php

1
2
3
4

  $q = Doctrine_Query::create()
    ->from('JobeetJob j')
    ->where('j.expires_at > ?', date('Y-m-d H:i:s', time()));
  $this->jobeet_job_list = $q->execute();

expires_atが現在より先のものだけ拾ってくるようになります。

これもやっぱり
$q->where('j.expires_at > NOW()');
のほうが早いんですがね。


このDQL変更によって、expires_atがNULLであるレコードは拾えなくなってしまいます。
新たなデータを例によってフィクスチャを利用して登録してみます。

しかし正直、どうもこの機能が便利とはとても思えないんですが。
データベースをいじって最初に投入したデータを変更していた場合、このチュートリアル通りにするとそこらへんの変更が全部消え去ってしまいます。

data/fixtures/jobs.ymlに、該当のYAMLのexpired_job:を追加します。
そしてコマンドを実行。
>php symfony doctrine:data-load

今回追加するこのexpired_job:にはexpires_atが指定されていないため、本来ならconfig/doctrine/schema.ymlの
JobeetJob:expires_at:   { type: timestamp, notnull: true }
条件に引っかかってしまいます。

ところが上でJobeetJob.class.phpでsaveメソッドをオーバーライドしているため、expires_atに何も入れない場合、自動的にexpires_atを設定した上でセーブしてくれます。
expired_job.expires_atは、JobeetJob::save()メソッドに従いcreated_atの30日後に設定された上で保存されていました。
ついでに元あったデータは、直接DBをいじくって変更していたものがあったりした場合でも全削除されます。
このコマンドが効くのは開発用データベースだけではあるのですが、それでもテスト用データがたくさん詰まった状態なんかでうっかりコマンドを打ってしまうと大惨事。
現在のデータベースの内容をYAMLに書き出すコマンドは無いのか？


カスタムコンフィギュレーションは単にapp.ymlに設定を分離するというだけの話です。
apps/frontend/config/app.ymlにチュートリアルをコピペ。

この後コントローラからでもモデルからでもビューからでも、
sfConfig::get('app_active_days')
でapp.ymlに書かれている値を引っ張ってくることができるようになります。

JobeetJob::saveメソッドの該当部分を以下のように書き換えます。
    $this->setExpiresAt(date('Y-m-d H:i:s', $now + 86400 * sfConfig::get('app_active_days')));

やっぱり掲載から60日は表示されるようにしたい、といったときに直接ロジックを書き換えることなく、設定ファイルを書き換えるだけで済むようになります。


最後にリファクタリング。
これまでDoctrine_Query::where('j.expires_at > NOW()')とかのロジックをコントローラに書いていました。
expires_atみたいなデータベースに直接関連する内容はコントローラに書かずに、全てモデルに押しやってしまいます。
コントローラを書き換えます。

apps/frontend/modules/job/actions/actions.class.php

1
2
3

  public function executeIndex(sfWebRequest $request){
    $this->jobeet_job_list = Doctrine::getTable('JobeetJob')->getActiveJobs();
  }

1
2
3
4
5

  public function getActiveJobs(){
    $q = $this->createQuery('j')
         ->where('j.expires_at > ?', date('Y-m-d H:i:s', time()));
    return $q->execute();
  }

まあ見ての通り、これまでコントローラに書いてあった処理をJobeetJobTableモデルに持っていっただけです。
$thisになっていますが、別に
    return Doctrine_Query::create()->from('JobeetJob j')
      ->where('j.expires_at > ?', date('Y-m-d H:i:s', time()))->execute();
とか書いても動きます。

コントローラでDoctrine::getTable('JobeetJob')を実行した場合、内部ではJobeetJobTableクラスが呼ばれています。
これまでのようにコントローラに検索ロジックを書いていた場合、複数の箇所で使用したくなったらその都度同じ処理を書かねばなりませんでした。
JobeetJobTableクラスにメソッドを記述することで、全てのプロジェクトからこのメソッドを使用できるようになります。

Symfonyの記事一覧

前回の続き。

ここまではリンクの書き方とrouting.ymlで完結していました。
ここまでは単にURLとルーティングをマッチングさせているだけなのでまあわからないこともないです。

この後突然ルートクラスという単語が登場し、全然意味がわからなくなってしまいます。
個人的には、下記のように一カ所を変更したいと思う度に至る所を修正しなければならない作りが正しいとはとても思えないんですがどうなんですかね。

まずsfRequestRoute。
こちらは通常ルーティングで使われるはずのsfRouteに、リクエストメソッドによる分岐機能を追加したものになります。
同じURLにリクエストが来た場合でも、<a>や<form method="GET">で飛んできた場合はsf_method:[get]に合致し、<form method="POST">で飛んできた場合はsf_method:[post]に合致する、というふうに分岐を行うことができます。

routing.ymlのjob_show_user:url:を変更。
 

1
2
3
4
5
6
7

job_show_user:
  url:   /job/:company/:location/:id/:position
  class: sfRequestRoute
  param: { module: job, action: show }
  requirements:
    id: \d+
    sf_method: [get]

class: sfRequestRouteとrequirements:sf_method: [get]が増えました。
これで
http://symfony.localhost/frontend_dev.php/job/sensio-labs/paris-france/1/web-developer
というURLに対し、リクエストメソッドがGETである場合のみにjob_show_userにマッチするようになります。
<form method="POST">で来た場合はルートが見つからないためエラーになります。
こちらは比較的わかりやすい。


次にsfDoctrineRoute。
routing.ymlのjob_show_user:url:をsfRequestRouteからsfDoctrineRouteに変更。
 

1
2
3
4
5
6
7
8

job_show_user:
  url:     /job/:company/:location/:id/:position
  class:   sfDoctrineRoute
  options: { model: JobeetJob, type: object }
  param:   { module: job, action: show }
  requirements:
    id: \d+
    sf_method: [get]

apps/frontend/modules/job/templates/indexSuccess.phpを変更。
    url_for(array('sf_route' => 'job_show_user', 'sf_subject' => $job))

class:sfDoctrineRouteでルーティングにsfDoctrineRouteを指定し、model:JobeetJobでルートに関係するモデルクラスを指定し、type:objectでこのルートに関係するオブジェクトを定義します。

何を言ってるんだこいつは？
全く全然さっぱりちっとも意味がわかりませんが、何故かリンクは表示されました。
/frontend_dev.php/job/Sensio+Labs/Paris%2C+France/1/Web+Developer
というようなURLになります。
なんで？
どこがどう繋がってこんなことになってるの？


さらにカスタマイズします。
URLに+とか%2Cといった文字が出てくるのはあまりよろしくないのでURLをslugifyします。slugifyって何よ？

lib/model/doctrine/JobeetJob.class.phpにgetSlug系メソッドを追加。

// lib/model/doctrine/JobeetJob.class.php

1
2
3
4
5
6
7
8
9

public function getCompanySlug(){
      return Jobeet::slugify($this->getCompany());
    }
    public function getPositionSlug(){
      return Jobeet::slugify($this->getPosition());
    }
    public function getLocationSlug(){
      return Jobeet::slugify($this->getLocation());
    }

1
2
3
4
5
6
7
8
9

class Jobeet{
      static public function slugify($text){
        // 文字ではないもしくは数値ではないものすべてを-に置き換える
        $text = preg_replace('/\W+/', '-', $text);
        // トリムして小文字に変換する
        $text = strtolower(trim($text, '-'));
        return $text;
      }
    }

routing.ymlのjob_show_user:url:を変更。
  url:     /job/:company_slug/:location_slug/:id/:position_slug

jobActions::executeShowを変更。
    $this->job = $this->getRoute()->getObject();


http://symfony.localhost/frontend_dev.php/job/sensio-labs/paris-france/1/web-developer
リンクが正しくなりました。めでたしめでたし。

JobeetJob::getCompanySlugは何処からどうやって呼ばれてるんだ？
lib/Jobeet.class.phpはいったい何処で此処に置くことを決定しているんだ？
getRouteって何？getObjectって何？
全然わかりません。

なんでリンクするだけのためにこんな馬鹿みたいなことをしないといけないのでしょうか。
あと日本語は文字化けします。


ルートコレクションという機能もあります。
基本的なフォームの閲覧から作成、編集までのひとまとまりのルーティングを纏めてキャッチしてくれます。
apps/frontend/config/routing.ymlに以下を追加します。
 

1
2
3

job:
  class:   sfDoctrineRouteCollection
  options: { model: JobeetJob }

なんか色々なルートを纏めて作成できるそうです。
皆さんわかりましたか？
私にはさっぱりわかりません。


最後にデフォルトルートを削除します。
デフォルトルートを削除した場合、定義したルート以外には辿り着けなくなります。
変なURLによるアクセスを簡単に排除することが出来ます。
逆に、今後モジュールを追加したとしても、routing.ymlを編集しない限りアクセスできなくなります。

Symfonyの記事一覧

http://symfony.localhost/frontend_dev.php/job/show/id/3
というURLで何故frontendアプリケーションのjobActions::executeShow()が実行されるのか、というお話。

まずテンプレート上で
url_for('a/b?c=d&e=f')
と書くと、url_for関数が勝手に
<a href="frontend_dev.php/a/b/c/d/e/f">といったふうにリンクを書き換えます。
indexという文字が現れたときとかの例外はありますが、今のところは特に気にする必要はありません。

リンク先をクリックした場合、まず第一引数であるaというモジュールを探し、その中のaActions::executeB()を実行しようとします。
三番目以降の引数はリクエストパラメータとなります。

まあこれが基本なのですが、そのルーティングの設定はapps/frontend/config/routing.ymlというファイルで決定されています。
これを変更することで、一部のリクエストだけ特別な処理を行ったりすることができます。
先にマッチしたルートが実行されるので、設定の順番は狭い順にします。

とりあえずデフォルトの設定を見てみます。
最初の段落、
 

1
2
3

homepage:
  url:   /
  param: { module: default, action: index }

/はindex.phpとかfrontend_dev.php/といった、引数が一個もない状態で来た場合にマッチします。
この場合、defaultモジュールのindexアクションが実行されます。
defaultモジュールは作成していませんが、Symfonyで最初から用意されているモジュールで、index以外にもerror404やdisabled、secureといった基本的なページが用意されています。
前回あったforward404Unless()は、内部的にdefaultモジュールのerror404アクションを呼び出しています。

homepage:は単なるラベルなので適当に変更してもかまいません。
ただ後述の@のためにわかりやすい名前にしておきましょう。

二段落目は
 

1
2
3

default_index:
  url:   /:module
  param: { action: index }

1
2

default:
  url:   /:module/:action/*

モジュール名とアクション名が入っていれば、その後どのようなパラメータが入っていてもこの段落に当てはまります。
具体的な指定は何もありませんが、すなわちモジュール名とアクション名をそのまま何も変更しないということです。

ではルートをカスタマイズしてみましょう。
まずはチュートリアルの通りに

 

1
2
3

homepage:
  url:   /
  param: { module: job, action: index }

と上書きします。
これで、引数が無い場合にはjobモジュールのindexアクションが実行されるということになり、
http://symfony.localhost/frontend_dev.php
http://symfony.localhost/frontend_dev.php/job/index
この両者が同じになります。

更にルーティングを追加。
 

1
2
3
4

job_show_user:
  url:   /job/:company/:location/:id/:position
  param: { module: job, action: show }
  requirements: {id: \d+ }

default:の/:module/:action/*が先に来るとそちらに引っかかってしまうので、default:より先に記述する必要があります。

そして以下のURLでアクセスします。
http://symfony.localhost/frontend_dev.php/job/sensio-labs/paris-france/1/web-developer

urlに:が付く場合は該当するパラメータの内容を表し、付かない場合はURLそのものを表します。
  url:   /job/:company/:location/:id/:position
の場合、
/job/はそのものが必須であり、
http://symfony.localhost/frontend_dev.php/job/sensio-labs/paris-france/1/web-developer
のようなURLには引っかかりますが、
http://symfony.localhost/frontend_dev.php/jobs/sensio-labs/paris-france/1/web-developer
などのURLにはひっかからないということを示します。
/:companyは、その位置に該当するパラメータということで、今回の場合は"sensio-labs"を表します。
このパラメータは、アクション内で$request->getParameter('company')として受け取ることができます。

どのような場合に使うかというと、URLをわかりやすくすることができます。
とりあえず今思いついたものとしては静的ページを配置する場合などに使えるかもしれません。
 

1
2
3

static_page:
  url:   /static/:name
  param: { module: index, action: static }

としてindexActions::executeStaticで$this->setTemplate($request->getParameter('name'))とか。

requirementsエントリはリクエストパラメータの絞り込みです。
id: \d+なので、:idの位置に来る値が数値であることを要求します。
当てはまらなかった場合はstatic_page:のルーティングには該当しないということになります。


@を使用したリンクを作成してみます。
url_for('@job_show_user?id=1&position=pos&company=comp&location=loc');
とすると、URLの形式がjob_show_user:のURL形式である、/job/:company/:location/:id/:positionに合致するように変形されます。

@を使わない形式ではurl_forに配列を渡せるのに@を使用するとできないのは何故なんだろう。

長くなったので続きは後日。
これ一時間とか絶対無理だよな。
 
Symfonyの記事一覧

一日目にfrontendアプリケーションを作成しましたが、このアプリケーションの具体的な実装はapps/frontendディレクトリに書いていくことになります。

まずapps/frontend/templates/layout.phpを見てみます。
このファイルは、index.phpおよびfrontend_dev.phpを呼び出したときに必ず呼び出されるテンプレートになります。
全体的なレイアウトをここで設定し、後ほど書いていく個別テンプレートは全部$sf_contentに入る、という形になります。

チュートリアルのfrontend/templates/layout.phpをコピペします。
また、CSSと画像ファイルをそれぞれweb/css/とweb/images/に設置します。
http://symfony.localhost/frontend_dev.php/job
を開いてみると、いきなりグラフィカルな画面になっています。
なに？解説が手抜き？気にするな。


さて、ここからようやくSymfonyの気持ち悪い機能を繙いていくことになります。
テンプレの各所にinclude_stylesheets()とかurl_for('job/index')といった見慣れない関数が鎮座しています。
これらはSymfonyで定義される色々な機能を呼び出すヘルパーです。
で、最初にも書きましたがSymfonyにはこういった機能の一覧/検索がないんですよね。
おかげで延々パッケージやチュートリアル、リファレンスを探し回される羽目になります。

include_stylesheets()はapps/frontend/config/view.ymlからstylesheetsハッシュを拾ってきて<link rel>タグにして表示します。
include_javascripts()は同様にjavascriptsハッシュを<script>タグで表示します。
上書きする前に存在したinclude_http_metas()やinclude_title()等を含め、これらのインクルード関数はAssetヘルパーに属しているのですが、そのことを先に知っていないとAPIリファンレンスで調べることができないという。

apps/frontend/config/view.ymlはフロントエンドを経由する全てのテンプレートに適用されますが、一部のモジュールのみ、一部のビューのみに設定を行うこともできます。
apps/frontend/modules/job/config/view.ymlを設定することでjobモジュールに、さらにその中でindexSuccess:とビューを指定することでビュー単位に指定できます。


アクションを触ってみます。
http://symfony.localhost/frontend_dev.php/job
はhttp://symfony.localhost/frontend_dev.php/job/indexと解釈されます。
そしてweb/frontend_dev.phpからapps/frontend/modules/job/actions/actions.class.phpが呼び出され、その中のexecuteIndexアクションが実行されることになります。
アクションで実行されている内容は実質わずか一行です。
$this->jobeet_job_list = Doctrine::getTable('JobeetJob')->createQuery('a')->execute();

簡単に言うとDoctrineを使用してJobeetJobを呼び出し、全レコードを取得して$this->jobeet_job_listに投入する、という内容です。


さて、executeIndex()はテンプレートへの変数のセットとかテンプレートの呼び出しといったことを一切行っていません。
どうなっているのでしょうか。

何も書かなかった場合、アクション名と同じテンプレートが自動的に呼び出されます。
今回のexecuteIndex()の場合は、テンプレートとしてapps/frontend/modules/job/templates/indexSuccess.phpが適用されます。
さらにその結果がapps/frontend/templates/layout.phpの$sf_contentに入ります。

で、apps/frontend/modules/job/templates/indexSuccess.phpを見てみると、いきなり
foreach ($jobeet_job_list as $jobeet_job)
とか書いてあります。
実は、アクションで$this->hogeに入れた内容はテンプレートからいきなり$hogeで呼ぶことができるのです。
なんとなく怖い。

$jobeet_job_listにはDoctrineの巨大なオブジェクトが入っていますが、イテレータを実装しているので配列として扱うことができます。
各行を表す$jobeet_jobに対し、$jobeet_job->getId()または$jobeet_job->idでjobeet_job.idを取得することができます。
Doctrineの便利なところは$jobeet_job->JobeetCategory->getName()とリレーションを辿っていけるところですが今回はそれは無いようです。

現在はどう見ても不要なカラムまで全部表示しているので、必要な部分だけを表示するようにします。
まあ例によってチュートリアルのapps/frontend/modules/job/templates/indexSuccess.phpをコピペするだけですが。


詳細画面に移動するとURLが次のようになります。
http://symfony.localhost/frontend_dev.php/job/show/id/2
jobアクションのexecuteShowが実行されます。
$request->getParameter('id')で/id/2の値、即ち2が取得されます。
Doctrine::getTable('JobeetJob')->find(2);
とすると主キーが2であるカラムを一件拾ってきます。
非常にわかりにくいので、
Doctrine::getTable('JobeetJob')->findOneById(2);
と引いてくるカラムと件数を明記した方がいいでしょう。
返ってくる値はどちらも同じです。
このfindBy系のメソッドは例によってスキーマから自動作成されており、findByEmailでjobeet_job.emailが一致したのを全件検索、findOneByTypeでjobeet_job.typeが一致する先頭一件を取得といった書き方ができます。


executeShowアクションから使用されるテンプレートはapps/frontend/modules/job/templates/showSuccess.phpです。
デフォルトでは全てのカラムが表示されていますので、これまたチュートリアルをコピペしましょう。
何故かテンプレート内のjobeet_jobオブジェクト名が$jobに変わっているので、アクションもそちらに合わせて変更します。

テンプレートの頭にuse_helper('Text')というのが入っていますが、これを記述することでヘルパーの一種であるTextHelperが使用できるようになります。
AssetHelperは何も書かずに使えたのに何故？
さあ？

use_helperを書かずに使用できるのはAssetHelper、CacheHelper、EscapingHelper、HelperHelper、PartialHelper、TagHelper、UrlHelperです。
何この不平等。
ていうかここらへんのことAPIリファレンスの何処にも書かれていないように見えるんですが。


次にスロットの説明が出てきます。
スロットはPartialHelperに含まれるのでuse_helper宣言をせずにいきなり使用できます。
スロットは出力制御みたいなもので、単に変数に値を代入するものです。
 

1
2
3

slot('title');
  print('あいうえお');

end_slot();

とすると、slot()からend_slot()までで挟まれた部分が全て変数titleに入ります。
 

1

include_slot('title');

>本日のチュートリアルの最初の方でview.ymlとテンプレートの両方でスタイルシートやJavaScriptを管理するやり方を見ました。
>結局2つのテクニックともレスポンスオブジェクトのaddStylesheet()とaddJavascript()メソッドを使います。

CakePHP1.2.5のフォームヘルパーの全メソッドと引数を解説。

Paginatorと違いヘルプが充実しているので要らないような気もしますが、と思ったら未完なところが多かった。

Formヘルパーというものがあるので検索フォームを簡単に作成できます。
cake_sample/formに作成してみます。

formアクションはとりあえず何もしない。

app/controllers/cake_sample_controller.php 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

<?php
    
    /*
        CakeSampleコントローラ
    */
    class CakeSampleController extends AppController{
        
        //自分の名前
            var $name = 'CakeSample';
        
        //CakeSample/form
            public function form() {
                //入れる
                    $this->set('cake_sample', $this->paginate('CakeSample'));
            }
    }

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

<?php
    //フォームオプション
        $options=array();
        $options['action']='form';
        $options['type']='text';
    
    //フォーム作成
        $a=array();
        $a[]=$form->create($options);
        $a[]=$form->input('id',$options);
        $a[]=$form->input('title',$options);
        $a[]=$form->end('検索');
    
        foreach($a as $val){
            print($val);
        }
 
    //検索結果表示
        if(isset($cake_sample)){
            var_dump($cake_sample);
        }

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

<?php
    
    /*
        CakeSampleコントローラ
    */
    class CakeSampleController extends AppController{
        
        //自分の名前
            var $name = 'CakeSample';
        
        //CakeSample/form
            public function form() {
                
                //引数があれば検索条件に入れる
                    $params=array();
                    if($this->data['CakeSample']['id']){
                        $params['conditions']['CakeSample.id']
                           =$this->data['CakeSample']['id'];
                    }
                    if($this->data['CakeSample']['title']){
                        $params['conditions']['CakeSample.title LIKE']
                           = '%'.$this->data['CakeSample']['title'].'%';
                    }
                    //念のためlimit
                    $params['limit']=10;
                
                //検索
                    $ret=$this->CakeSample->find('all',$params);
                
                //表示
                    $this->set('cake_sample', $ret);
            }
    }

CakePHP1.2.4.8284のページャーの全メソッドと引数を解説。

公式マニュアルには$paginatorの解説が全く載っていません。
マニュアルでは「$paginator->numbersで前後10件ずつ表示したい」「1ページ目にリンクしたい」すら解決できません。
他に解説しているところもほとんど見あたりませんでした。

仕方ないのでソースから解読。
よくわかんないところは想像で適当に補っています。
特に$optionsの中身とかはさっぱりわからないので間違っている可能性大。

びっくりするほど使い辛いなDoctrine。

とりあえず
 

SELECT 
  a.id AS id
  ,(
    select count(*) from b
    where b.a_id=a.id
    group by a.id 
  ) AS count
FROM a

1
2
3
4
5
6
7
8
9
10
11
12
13

<?php
    
    //DBコネクション
        $q=Doctrine::getConnectionByTableName('a');
    
    //任意のSQL
        $sql='SHOW TABLES';
    
    //実行
        $statement=$q->execute($sql);
    
    //取得
        $ret=$statement->fetchAll(PDO::FETCH_ASSOC);