MySQL、オープンソース系、ウェブ系ネタ。MySQL、オープンソース系、ウェブ系ネタ。metacpan.orgMojolicious純正のフォームバリデーションを使う上で気を付ける点を書き留めておく。Mojolicious::Plugin::TagHelpersとも相性良いし(当たり前)、活用すべき。'trim')->like(qr/hoge2/);バリデーションrequired()又はoptional()から始める$validation->required('name')又は$validation->optional('name')から始める。メソッドチェーンでもいいし、都度バリデーションメソッドを呼んでも良い。requidedかoptionalを呼んだ時点でバリデーション対象のfieldが切り替わる。現在バリデーション対象になっているfieldは$validation->topicで取得できる。);DB等へ保存する値は$validation->outputの値を使う$c->req->paramsの値はリクエスト時の値なのでDB等に値を保存する場合には使用しない。filterを使う場合は注意が必要。filter適用後の値は$validation->outputに収納されている。formしてくれるけど、値にフィルターを適用する場合は注意が必要。バリデーション実行時に$c->param()でリクエストパラメータの値の書き換えが必要。タグヘルパーの値補完にはreq->paramの値が使われるバリデーションも同時に行っている場合バリデーションエラーがあるとvalidation->param()がundefを返すのでバリデーションエラーがない時だけ書き換える...としなくてはならない。branchを作成しておくって事をよくやる。してから再度branchを作成したりしていた。margeすると1コミット増えるし、branch削除→作成は面倒だし...と思っていたけど良い方法があるらしい。masterrebase使えば良かったとは。使ったこと無かった...。Gunma.webって?Webサイト制作に関わる人が集まる勉強・研究・交流の地域コミュニティです。Webサイト制作に関わるプログラマー、SE、HTMLコーダー、Webデザイナーさんなどが集まります。群馬で数少ないIT系勉強会の一つ。会場は高崎のあすなろカフェで、コーヒーを飲みながらまったりと行われます。覗いてみたりすると勉強会の雰囲気が分かるかもしれません。x3枠、ビギナーズLT(5min)数枠がまだまだ絶賛募集中です。いえば、ビギナーズLT枠というのは「ビギナー向けの内容のLT」枠なのか、はたまた「LTをする事がビギナー」向けの枠なのか、謎は深まりますがどっちもありとの見解です。今回はテーマ別発表枠があります。お題は「仮想DOM」。フロントエンド得意な方のトーク、お待ちしております。メンションすると反応します。参加するにはconnpassにて参加受付をしています。DBIx::Class(DBIC)に入門。使い始めてDBICの作法に翻弄されてる。timestamp的なカラム、例えばupdated_atカラムを自動更新させるのにハマったのでメモ。$self->next::method(@_);}1;上記のようなResultクラスのベースを継承してResultクラスを作っていくのだけど、ちょっとした問題に当たる。データを更新するには下記のようになる。});いずれのコードもis_publicカラムを1に更新する。updated_atカラムが現在の時刻に自動更新される...と思うのだけどそうならない場合がある。更新されるのはfind()を使っているその1の場合だけ。その2の場合は更新されない。この理由と対処方法は下記エントリーに書かれている。DBIx::Class(DBIC)で既存のメソッドを上書きしたい。使われるupdateメソッドは別のものって事。いうのを見つけたけど、こちらもfind()のようにrowオブジェクト取得してからupdateしないと効かないようだ...。単純に発行されるSQLが少ないから。keyが分かってて、かつ、その行のデータの取得は必要がない場面を想定している。場合はSELECT文が発行されず、UPDATE文のみが発行されるようだったので。通常はいきなりUPDATEを行うことは少ないかもしれない。解決策としてはfind()で更新するって方法とResultクラスではなくResultsetクラスのベースになるものにしてあげるって方法があると思う。find()で解決した場合の問題点find()を使う場合は必ずSELECTが発行される。先程の例で言うと発行されるSQLのイメージは下記のような感じ。xxx;必要がないSELECT文が実行されるのは避けたい。ResultSetクラスでの解決Resultクラスの共有部分を作るように、ResultSetクラスの共有で解決できそうだと思って試したら出来た。$self->next::method(@_);}1;このResultクラスを継承して各テーブルのResultクラスを作る。エントリーの例で言うと下記コードのような感じ。ここにテーブル定義1;もうちょっとスマートな方法があったら後で加筆する。(0)TweetMojoliciousでactionの前後に実行される独自のHookを作る。before_action、after_action編PerlのWebApplicationFrameworkであるMojoliciousでは様々なフックが用意されているのだけれど、actionの前後だけに実行したい場合は独自にフックポイントを追加しないといけない。実装方法その1一番単純な実装方法はaround_actionフックを使うのが良さそう。actionは$lastフラグが真の時に実行されるので前後に独自のフックをエミットする。);}このフックを使えば動的ページのみでフックを実行できる。session関連の操作とかに便利。実装方法その2上記のコードの場合は全てのactionに適用されてしまうので、フックを実行したくないcontrollerを作りたい場合はMojolicious::Controllerを継承したclassを作る事で実現できる。'MyApp::NoHookController';...before/after_actionフックを使う場合はMyApp::Controllerを継承したcontrollerを作り、使わない場合はMyApp::NoHookControllerを継承したcontrollerにする。DBIx::Class(DBIC)でtimestamp的なカラムの自動更新Mojoliciousでactionの前後に実行される独自のHookを作る。