tokuhirom's blog.

'; DROP DATABASE database();

Sledge::Pages::Base における config の扱い

sledge

他のインターフェースに合わせると、こうなっているべきだと思う。

Index: Sledge/Pages/Base.pm
===================================================================
--- Sledge/Pages/Base.pm        (revision 855)
+++ Sledge/Pages/Base.pm        (working copy)
@@ -16,6 +16,7 @@
     'charset',                 # Sledge::Charset
     'tmpl',                    # Sledge::Template
     'fillin_form',             # Sledge::FillInForm
+    'config',                  # Sledge::Config
     'finished',                        # flag whether request is finished
     'page',                    # page name (arg to dispatch())
     'filters',                 # filter subs
@@ -70,6 +71,7 @@
     $self->authorizer($self->create_authorizer);
     $self->manager($self->create_manager);
     $self->charset($self->create_charset);
+    $self->config($self->create_config);
 }

 # this method is called from .cgi

ことあるごとに $pages->create_config 呼ぶのはダサい。$pages->config の方が良い。

こうなっていないのは、何か歴史的な経緯があるのでしょうか。

Catalyst の新しい Validator

catalyst

Sebastian Riedel 氏が HTML::Widget とかいうのを作ってるらしい、と宮川さんからの情報。

Catalyst の ML によれば、ほとんど出来上がってる様子。

subversion のリポジトリの様子が下記 URL から参照できる。
http://dev.catalyst.perl.org/repos/Catalyst/trunk/HTML-Widget/

結論からいうと、使うのは辛いかなぁ、という印象。

        use HTML::Widget;

        my $w = HTML::Widget->new( { method => 'GET', action => '/foo/action' } );
        $w->element( 'Textfield', 'age' )->label('Age')->size(3);
        $w->element( 'Textfield', 'name' )->label('Name')->size(60);
        $w->element( 'Submit', 'ok' )->value('OK');
        $w->constraint( 'Integer', 'age' )->message('No integer.');
        $w->constraint( 'Required', 'age', 'name' )->message('Missing value.');

という風に書いて、フォームを生成するタイプのヴァリデータなので、日本人には辛いかなぁ、と。

Sledge と Validator と

sledge validator

最近、Sledge のヴァリデータについて考えている。
Web Application におけるデータのヴァリデーションは、かなり重要なので、フレームワーク側でまかなうのが良いと思う。

Sledge で言えば、

package Project::Pages::Base;
use base qw(Sledge::Pages::Base);
sub create_validator {
  my $self = shift;
  return Project::Validator->new($self);
}

みたいに create_validator を定義するだけの価値があると思う。んで、$p->valid に create_validator の結果が入って良いと思う。

package Project::Validator;
use base qw(Sledge::Validator::Base);
use Module::Pluggable::Fast search => ['Project::Validator'];

1;

とかしといて、

package Project::Validator::Entry;
use base qw(Project::Validator);

sub add {
  my $self = shift;

  $self->check(
    title => [qw(NOT_NULL)],
    body  => [qw(NOT_NULL)],
  );
}

sub edit {
  my $self = shift;

  $self->add;
}

1;

とか定義しといて、

package Project::Pages::Entry;
use base qw(Project::Pages::Base);

sub valid_edit {
  my $self = shift;
  $self->valid->err_template('/entry/edit_form');
  $self->valid->blog->edit;
}
sub dispatch_edit {
  my $self = shift;
  # some operations ...
}

1;

こんな感じで使えると良いんじゃないかなぁ、と妄想中。

フレームワークにおいて、Vaidator は別クラスにすべきか

わざわざヴァリデーション条件を別個のクラスにするのか、というところは疑問に思う人もいるのではないかと思う。

「サインアップ」と「会員情報変更」は、普通違う Pages に置くが、ヴァリデーションの条件は共有したくなる。フォームのテンプレートは共有しているのにヴァリデータは共有しないってのもおかしな話だ。

他の Pages のヴァリデーション条件を呼びだす、というのはおかしな話だ。

モデルに置く、というやり方もあるが、編集時には空白では駄目だが登録時には空白でいい、という場合というケースも多い(パスワードなど)。このへんの事情は明らかに Controller の問題なので、Model が意識するべきではない。

というわけで、別個のクラスにしてみたんですけど、どうでしょうか。

Sledge::Plugin::Validator と POST

sledge validator

GET なら form を表示して、POST されたら処理を行う、というフローが Sledge::Plugin::Validator では不可能でした。

GET でも Validator 走ってしまってマズーでした。

post_dispatch_* が存在してて、POST request じゃない時には、何もしないで欲しいの！

っつーわけで、こんなパチーをあてるとよいかと。取込みおねがいします> id:takefumi

Index: Sledge/Plugin/Validator.pm
===================================================================
--- Sledge/Plugin/Validator.pm  (revision 855)
+++ Sledge/Plugin/Validator.pm  (working copy)
@@ -21,6 +25,11 @@
                        my $self = shift;

                        my $page = $self->{page};
+
+            if ($self->can("post_dispatch_$page") and !$self->is_post_request) {
+                return;
+            }
+
                        my $vali_page     = "valid_$page";
                        unless($self->can($vali_page)) {
                                return;

# 行数はオレオレパッチあてまくってるのでズレてるかも

CVS から SVN への移行に際する履歴の捨て方について

http://d.hatena.ne.jp/yyamano/comment?date=20051201

過去の変更履歴ってそんなに簡単に捨てれるんだろうか? 僕の感覚では捨てるべきものではないんだけど。普通、変更履歴はBTSなんかと連携してるだろうし、

複数のリリースバージョンを抱えていると履歴を捨ててインポートなんで現実的ではないんじゃないだろうか。

別に今迄の CVS のリポジトリを rm -rf CVSROOT しなくても良いわけで、必要になった時に cvs のリポジトリをのぞく、という程度で良いのではないかと思います。

弊社の場合、移行後も CVS のリポジトリは残してありますが、思ったより過去の履歴を見たくなるケースはほとんど無かった(経験者は語る)

BTS の連携に関しては確かにそうかもしれません。弊社では BTS と CVS を連携させていなかったので、考えてませんでした。

# あしかに CVS との連携機能は無いと思いますので、はてなの場合は問題ないと思います ;-)

まぁ、自分のところでやっているサービスと会社の態勢による、ということで。

Sledge で use 文ばっかにしない方法

Sledge

Catalyst だと、フレームワーク側でやってくれるんだけど、Sledge だと無いので、Project::Pages::Base で

use Module::Pluggable::Fast search => ['Project::Data'];

こんなん書いてる。

Catalyst だと、Cataslyst::SetUp あたりで

    eval {
                                                                              Module::Pluggable::Fast->import(
            name   => '_components',
            search => [                                                                         "$class\::Controller", "$class\::C",
                "$class\::Model",      "$class\::M",
                "$class\::View",       "$class\::V"
            ],
            callback => $callback                                                       );
    };

とかやってくれてる。

use 地獄から解法されるので良いなぁ。