Index: docs/perldoc/Catalyst/Manual/ExtendingCatalyst.pod
===================================================================
--- docs/perldoc/Catalyst/Manual/ExtendingCatalyst.pod (revision 13183)
+++ docs/perldoc/Catalyst/Manual/ExtendingCatalyst.pod (revision 13183)
@@ -0,0 +1,759 @@
+=head1 名前(NAME)
+
+Catalyst::Manual::ExtendingCatalyst - フレームワークを拡張する
+
+=head1 概要(DESCRIPTION)
+
+This document will provide you with access points, techniques and best
+practices to extend the L<Catalyst> framework, or to find more elegant
+ways to abstract and use your own code.
+
+このドキュメントでは Catalyst を拡張する方法やどうやってエレガントにあなたのコー
+ドを抽象化するかについて論じます。
+
+The design of Catalyst is such that the framework itself should not
+get in your way. There are many entry points to alter or extend
+Catalyst's behaviour, and this can be confusing. This document is
+written to help you understand the possibilities, current practices
+and their consequences.
+
+Catalyst はいろんな方法で拡張できるので、あなたは混乱しているかもしれません。この
+ドキュメントではそのあたりの詳細を論じます。
+
+Please read the L<BEST PRACTICES> section before deciding on a design,
+especially if you plan to release your code to CPAN. The Catalyst
+developer and user communities, which B<you are part of>, will benefit
+most if we all work together and coordinate.
+
+あなたのコードを CPAN にうpするまえに、とりあえず L<BEST PRACTICES> の章をよみま
+しょう。 Catalyst の開発者とユーザコミュニティはあなたとともにあります。
+
+If you are unsure on an implementation or have an idea you would like
+to have RFC'ed, it surely is a good idea to send your questions and
+suggestions to the Catalyst mailing list (See L<Catalyst/SUPPORT>)
+and/or come to the C<#catalyst> channel on the C<irc.perl.org>
+network. You might also want to refer to those places for research to
+see if a module doing what you're trying to implement already
+exists. This might give you a solution to your problem or a basis for
+starting.
+
+あなたがなにか実装にまつわるアイディアをもっているのであれば、Catalyst の ML,
+IRC などで話しかけてください。
+
+=head1 ベストプラクティス(BEST PRACTICES)
+
+During Catalyst's early days, it was common to write plugins to
+provide functionality application wide. Since then, Catalyst has
+become a lot more flexible and powerful. It soon became a best
+practice to use some other form of abstraction or interface, to keep
+the scope of its influence as close as possible to where it belongs.
+
+Catalyst が若かりしころ、複数アプリにまたがる機能はプラグインにするのがよいとされ
+えいましたが、現在ではもっとフレキシブルでパワフルな方法があります。
+
+For those in a hurry, here's a quick checklist of some fundamental
+points. If you are going to read the whole thing anyway, you can jump
+forward to L</Namespaces>.
+
+もし君がめっちゃいそいでいるのなら、以下に必須のポイントに関するクイックチェック
+リストを容易したからそれだけでもよんでいきたまえ。もし君がまったりとこの文書を全
+部読むつもりなら L</Namespaces> に進む。
+
+=head2 3分間チェックリスト(Quick Checklist)
+
+=over
+
+=item C<CatalystX::*> というネームスペースをつかいましょう(Use the C<CatalystX::*> namespace if you can!)
+
+If your extension isn't a Model, View, Controller, Plugin, or Engine,
+it's best to leave it out of the C<Catalyst::> namespace.  Use
+<CatalystX::> instead.
+
+もしあなたの拡張が Model でも View でも Controller でも Plugin でも Engine でもな
+ければ、それは C<Catalyst::> というネームスペースにおくべきではありません。
+C<CatalystX::> をかわりにつかってください。
+
+=item プラグインはつくらない(どうしてもつくらなきゃいけない場合をのぞいて)!(Don't make it a plugin unless you have to!)
+
+A plugin should be careful since it's overriding Catalyst internals.
+If your plugin doesn't really need to muck with the internals, make it a
+base Controller or Model.
+
+プラギンは Catalyst の内部をうわがきしちゃうので、注意してね!もしチミのプラグイン
+が、内部を上書きしたいんでなければ、Controller か Model にしてね!
+
+=item コミュニティがあるから利用しちゃおう!(There's a community. Use it!)
+
+There are many experienced developers in the Catalyst community,
+there's always the IRC channel and the mailing list to discuss things.
+
+Catalyst には IRC も ML もあるから、どんどん利用しちゃおう!
+
+=item テストとドキュメンテーションはしっかりね!(Add tests and documentation!)
+
+This gives a stable basis for contribution, and even more importantly,
+builds trust. The easiest way is a test application. See
+L<Catalyst::Manual::Tutorial::Testing> for more information.
+
+あたりまえのことだけど、テストとドキュメンテーションをしない人はお尻ペンペンだよ!
+
+=back
+
+=head2 ネームスペース(Namespaces)
+
+While some core extensions (engines, plugins, etc.) have to be placed
+in the C<Catalyst::*> namespace, the Catalyst core would like to ask
+developers to use the C<CatalystX::*> namespace if possible.
+
+コアの拡張(engine や plugin とか)は、C<Catalyst::*> におくべきだけど、そういうの
+つくるときは開発者に相談してからにしよう。できることなら C<CatalystX::*> におこう。
+
+(訳注: CPAN にアップロードする場合、相談してからやらないと mst に痛烈に DIS られます)
+
+When you try to put a base class for a C<Model>, C<View> or
+C<Controller> directly under your C<MyApp> directory as, for example,
+C<MyApp::Controller::Foo>, you will have the problem that Catalyst
+will try to load that base class as a component of your
+application. The solution is simple: Use another namespace. Common
+ones are C<MyApp::Base::Controller::*> or C<MyApp::ControllerBase::*>
+as examples.
+
+もしC<Model>, C<View>, C<Controller>のベースクラスをC<MyApp>の下、たとえばC<MyApp::Controller::Foo>、に置くとCatalystがそれをロードしようとするのでちょっとトラぶっちゃうと思います。解決方法は簡単で、C<MyApp::Base::Controller::*>::やC<MyApp::ControllerBase::*>なんかのネームスペースを使うといいでしょう。
+
+=head2 それをシンプルなモジュールにすることはできませんか?(Can it be a simple module?)
+
+Sometimes you want to use functionality in your application that
+doesn't require the framework at all. Remember that Catalyst is just
+Perl and you always can just C<use> a module. If you have application
+specific code that doesn't need the framework, there is no problem in
+putting it in your C<MyApp::*> namespace. Just don't put it in
+C<Model>, C<Controller> or C<View>, because that would make Catalyst
+try to load them as components.
+
+Catalyst はたんなる Perl であることを思いだしてください。C<use> でいつでもモジュー
+ルをつかえるんですよ。フレームワークと連携することが必要ないアプリケーション専用
+のコードであれば、C<MyApp::*> というネームスペースをつかってください。C<Model>,
+C<Controller>, C<View> というネームスペースにはおかないでください。このネームスペー
+スにおくと Catalyst がコンポーネントとしてロードしちゃいまっせ。
+
+Writing a generic component that only works with Catalyst is wasteful
+of your time.  Try writing a plain perl module, and then a small bit
+of glue that integrates it with Catalyst.  See
+L<Catalyst::Model::DBIC::Schema|Catalyst::Model::DBIC::Schema> for a
+module that takes the approach.  The advantage here is that your
+"Catalyst" DBIC schema works perfectly outside of Catalyst, making
+testing (and command-line scripts) a breeze.  The actual Catalyst
+Model is just a few lines of glue that makes working with the schema
+convenient.
+
+Catalyst に依存した一般的なコンポーネントをつくることは、あなたの時間を無駄に浪費
+させます。素の Perl モジュールを書くことを検討してください。そして、Catalyst とは
+ほんのちょっとの連携コードで連携させてください。このような方法論でつくられたモ
+ジュールの代表例は Catalyst::Model::DBIC::Schema ですので参考にしてください。この
+方法のよさは、DBIC のスキーマが完全に Catalyst の外でうごいているということです。
+こうすることによって、テストが楽になり、コマンドラインスクリプトも簡単に書けます。
+現実の Catalyst の Model は、ほんとにちょっとの連携コードで便利につかえるようにつ
+なぎこまれてるのだ。
+
+If you want the thinnest interface possible, take a look at
+L<Catalyst::Model::Adaptor|Catalyst::Model::Adaptor>.
+
+もし、薄いインターフェースで連携できるんなら Catalyst::Model::Adaptor でつなぎこ
+むのがよいです。
+
+=head2 継承とメソッドのうわがき。(Inheritance and overriding methods)
+
+While Catalyst itself is still based on L<NEXT> (for multiple
+inheritance), extension developers are encouraged to use L<Class::C3>,
+which is what Catalyst will be switching to in some point in the
+future.
+
+CatalystはまだNEXTベースだけど拡張モジュールを作る人はClass::C3を使うといいよ。Catalystもそのうちそうなるから。
+
+When overriding a method, keep in mind that some day additionally
+arguments may be provided to the method, if the last parameter is not
+a flat list. It is thus better to override a method by shifting the
+invocant off of C<@_> and assign the rest of the used arguments, so
+you can pass your complete arguments to the original method via C<@_>:
+
+メソッドをオーバーライドする場合は将来引数が追加されることを考慮して以下のようにするといい。
+
+  use Class::C3; ...
+
+  sub foo { my $self = shift;
+            my ($bar, $baz) = @_; # ...  return
+            $self->next::method(@_); }
+
+If you would do the common
+
+  my ($self, $foo, $bar) = @_;
+
+you'd have to use a much uglier construct to ensure that all arguments
+will be passed along and the method is future proof:
+
+  $self->next::method(@_[ 1 .. $#_ ]);
+
+=head2 テストとドキュメンテーション(Tests and documentation)
+
+When you release your module to the CPAN, proper documentation and at
+least a basic test suite (which means more than pod or even just
+C<use_ok>, sorry) gives people a good base to contribute to the
+module.  It also shows that you care for your users. If you would like
+your module to become a recommended addition, these things will prove
+invaluable.
+
+CPAN にモジュールをリリースするにあたっては、きちんとしたドキュメンテーションと、
+テストスィーツ(use_ok してりゃいいってもんじゃないよ)を提供してくださいな。
+
+If you're just getting started, try using
+L<CatalystX::Starter|CatalystX::Starter> to generate some example
+tests for your module.
+
+もし君が、あたらしくつくりはじめるんなら CatalystX::Starter をつかってみてくださ
+いな。テストの例がはいっているよ。
+
+=head2 メンテナンス(Maintenance)
+
+In planning to release a module to the community (Catalyst or CPAN and
+Perl), you should consider if you have the resources to keep it up to
+date, including fixing bugs and accepting contributions.
+
+If you're not sure about this, you can always ask in the proper
+Catalyst or Perl channels if someone else might be interested in the
+project, and would jump in as co-maintainer.
+
+A public repository can further ease interaction with the
+community. Even read only access enables people to provide you with
+patches to your current development version. subversion, SVN and SVK,
+are broadly preferred in the Catalyst community.
+
+If you're developing a Catalyst extension, please consider asking the
+core team for space in Catalyst's own subversion repository. You can
+get in touch about this via IRC or the Catalyst developers mailing
+list.
+
+リリースしたモジュールをアップデートしたり、バグフィックスしたりしてね。
+
+みんながパッチを送れるように開発中のリポジトリを公開しておくのもいいね。
+
+とか。
+
+=head2 コンテキストオブジェクト(The context object)
+
+Sometimes you want to get a hold of the context object in a component
+that was created on startup time, where no context existed yet. Often
+this is about the model reading something out of the stash or other
+context information (current language, for example).
+
+起動時に作成されたコンポーネントの中でコンテキストオブジェクトを使いたい場合もあります。
+
+If you use the context object in your component you have tied it to an
+existing request.  This means that you might get into problems when
+you try to use the component (e.g. the model - the most common case)
+outside of Catalyst, for example in cronjobs.
+
+しかし、コンポーネントの中でコンテキストオブジェクトを使うということはリクエストとコンポーネントを結びつけるという意味であり、Catalystの外でそのコンポーネントを使おうとした場合に問題となります。
+
+A stable solution to this problem is to design the Catalyst model
+separately from the underlying model logic. Let's take
+L<Catalyst::Model::DBIC::Schema> as an example. You can create a
+schema outside of Catalyst that knows nothing about the web. This kind
+of design ensures encapsulation and makes development and maintenance
+a whole lot easier. The you use the aforementioned model to tie your
+schema to your application. This gives you a C<MyApp::DBIC> (the name
+is of course just an example) model as well as
+C<MyApp::DBIC::TableName> models to access your result sources
+directly.
+
+解決方法はCatalystのモデルはモデルロジックとは切り離して設計することです。たとえばL<Catalyst::Model::DBIC::Schema>を見るといいでしょう。スキーマはCatalystとは切り離されてます。このような設計はカプセル化を促進し、メンテナンス性もよくなります。
+
+By creating such a thin layer between the actual model and the
+Catalyst application, the schema itself is not at all tied to any
+application and the layer in-between can access the model's API using
+information from the context object.
+
+このように薄いレイヤーを実際のモデルとCatalystの間に用意することで、モデル自身はアプリケーションに結び付けず、レイヤーの部分はコンテキストオブジェクトからの情報を使ってモデルAPIにアクセスできるようになります。
+
+A Catalyst component accesses the context object at request time with
+L<Catalyst::Component/"ACCEPT_CONTEXT($c, @args)">.
+
+CatalystのコンポーネントはL<Catalyst::Component/"ACCEPT_CONTEXT($c, @args)">を使うことでリクエスト時にコンテキストオブジェクトにアクセスできます。
+
+=head1 設定(CONFIGURATION)
+
+The application has to interact with the extension with some
+configuration. There is of course again more than one way to do it.
+
+アプリケーションはいくつかの設定によって拡張モジュールと協調します。もちろん、やり方は複数あります。
+
+=head2 アトリビュート(Attributes)
+
+You can specify any valid Perl attribute on Catalyst actions you like.
+(See L<attributes/"Syntax of Attribute Lists"> for a description of
+what is valid.) These will be available on the C<Catalyst::Action>
+instance via its C<attributes> accessor. To give an example, this
+action:
+
+Perlで使える属性がすべて使えます。属性はC<Catalyst::Action>のインスタンスでC<attributes>アクセサを介して使用できます。
+
+  sub foo : Local Bar('Baz') {
+      my ($self, $c) = @_;
+      my $attributes =
+      $self->action_for('foo')->attributes;
+      $c->res->body($attributes->{Bar}[0] );
+  }
+
+will set the response body to C<Baz>. The values always come in an
+array reference. As you can see, you can use attributes to configure
+your actions. You can specify or alter these attributes via
+L</"Component Configuration">, or even react on them as soon as
+Catalyst encounters them by providing your own L<component base
+class|/"Component Base Classes">.
+
+これはレスポンスボディにBazをセットします。値は常に配列のリファレンスです。
+
+=head2 カスタムアクセサをつくる(Creating custom accessors)
+
+L<Catalyst::Component> uses L<Class::Accessor::Fast> for accessor
+creation. Please refer to the modules documentation for usage
+information.
+
+L<Catalyst::Component> はアクセサをつくるのに L<Class::Accessor::Fast> をつかって
+います。
+
+=head2 コンポーネントの設定(Component configuration)
+
+At creation time, the class configuration of your component (the one
+available via C<$self-E<gt>config>) will be merged with possible
+configuration settings from the applications configuration (either
+directly or via config file).  This is then stored in the controller
+object's hash reference. So, if you read possible configurations like:
+
+作成時にコンポーネントのクラス設定（C<$self-E<gt>config>で使えるやつ）はアプリケーション設定で使用可能な設定とマージされます。で、これらはコントローラオブジェクトのハッシュリファレンスに保存されます。なので設定は以下のように読み込むことができます。
+
+  my $model_name = $controller->{model_name};
+
+you will get the right value. The C<config> accessor always only
+contains the original class configuration and must not be used for
+component configuration.
+
+C<config>アクセサは常に元のクラス設定のみを含んでいて、コンポーネント設定のためには使われません。
+
+You are advised to create accessors on your component class for your
+configuration values. This is good practice and makes it easier to
+capture configuration key typos. You can do this with the
+C<mk_ro_accessors> method provided to L<Catalyst::Component> via
+L<Class::Accessor::Fast>:
+
+設定値用に以下のようなアクセサを用意しておくと便利です。
+
+  use base 'Catalyst::Controller';
+  __PACKAGE__->mk_ro_accessors('model_name');
+  ...
+  my $model_name = $controller->model_name;
+
+=head1 実装(IMPLEMENTATION)
+
+This part contains the technical details of various implementation
+methods. Please read the L</"BEST PRACTICES"> before you start your
+implementation, if you haven't already.
+
+いろんな実装方法の詳細を説明します。
+
+=head2 Actionクラス(Action classes)
+
+Usually, your action objects are of the class L<Catalyst::Action>.
+You can override this with the C<ActionClass> attribute to influence
+execution and/or dispatching of the action. A widely used example of
+this is L<Catalyst::Action::RenderView>, which is used in every newly
+created Catalyst application in your root controller:
+
+アクションオブジェクトはL<Catalyst::Action>クラスのインスタンスです。C<ActionClass>属性を使うことでこの挙動に影響を与えることができます。広く使われている例ではL<Catalyst::Action::RenderView>があります。
+
+  sub end : ActionClass('RenderView') { }
+
+Usually, you want to override the C<execute> and/or the C<match>
+method. The execute method of the action will naturally call the
+methods code. You can surround this by overriding the method in a
+subclass:
+
+大抵の場合、C<execute>やC<match>メソッドをオーバーライドすることになるでしょう。サブクラスでexecuteメソッドをオーバーライドすることでメソッドをラップすることができます。
+
+  package Catalyst::Action::MyFoo; use strict;
+
+  use Class::C3; use base 'Catalyst::Action';
+
+  sub execute {
+      my $self = shift;
+      my ($controller, $c, @args) = @_;
+      # put your 'before' code here
+      my $r = $self->next::method(@_);
+      # put your 'after' code here
+      return $r;
+  }
+  1;
+
+We are using L<Class::C3> to re-dispatch to the original C<execute> method
+in the L<Catalyst::Action> class.
+
+L<Catalyst::Action>クラスにある元のC<execute>メソッドに再度ディスパッチするためにL<Class::C3>を使ってます。
+
+The Catalyst dispatcher handles an incoming request and, depending
+upon the dispatch type, will call the appropriate target or chain. 
+From time to time it asks the actions themselves, or through the
+controller, if they would match the current request. That's what the
+C<match> method does.  So by overriding this, you can change on what
+the action will match and add new matching criteria.
+
+C<match>メソッドをオーバーライドするとCatalystのディスパッチャの挙動を変更できます。
+
+For example, the action class below will make the action only match on
+Mondays:
+
+たとえば以下のアクションクラスは月曜日にだけマッチします。
+
+  package Catalyst::Action::OnlyMondays; use strict;
+
+  use Class::C3;
+  use base 'Catalyst::Action';
+
+  sub match {
+      my $self = shift;
+      return 0 if ( localtime(time) )[6] == 1;
+      return $self->next::method(@_);
+   }
+  1;
+
+And this is how we'd use it:
+
+こうやって使います。
+
+  sub foo: Local ActionClass('OnlyMondays') {
+      my ($self, $c) = @_;
+      $c->res->body('I feel motivated!');
+  }
+
+If you are using action classes often or have some specific base
+classes that you want to specify more conveniently, you can implement
+a component base class providing an attribute handler.
+
+For further information on action classes, please refer to
+L<Catalyst::Action> and L<Catalyst::Manual::Actions>.
+
+=head2 コンポーネントなクラス(Component base classes)
+
+Many L<Catalyst::Plugin> that were written in Catalyst's early days
+should really have been just controller base classes. With such a
+class, you could provide functionality scoped to a single controller,
+not polluting the global namespace in the context object.
+
+Catalyst がうまれたての頃に多くの L<Catalyst::Plugin> が書かれました。
+
+You can provide regular Perl methods in a base class as well as
+actions which will be inherited to the subclass. Please refer to
+L</Controllers> for an example of this.
+
+You can introduce your own attributes by specifying a handler method
+in the controller base. For example, to use a C<FullClass> attribute
+to specify a fully qualified action class name, you could use the
+following implementation. Note, however, that this functionality is
+already provided via the C<+> prefix for action classes. A simple
+
+シンプルな
+
+  sub foo : Local ActionClass('+MyApp::Action::Bar') { ... }
+
+will use C<MyApp::Action::Bar> as action class.
+
+は、C<MyApp::Action::Bar> を Action クラスとしてつかいます。
+
+  package MyApp::Base::Controller::FullClass; use strict; use base
+  'Catalyst::Controller';
+
+  sub _parse_FullClass_attr {
+      my ($self, $app_class, $action_name, $value, $attrs) = @_;
+      return( ActionClass => $value );
+  }
+  1;
+
+Note that the full line of arguments is only provided for completeness
+sake. We could use this attribute in a subclass like any other
+Catalyst attribute:
+
+  package MyApp::Controller::Foo;
+  use strict;
+  use base 'MyApp::Base::Controller::FullClass';
+
+  sub foo : Local FullClass('MyApp::Action::Bar') { ... }
+
+  1;
+
+=head2 コントローラ(Controllers)
+
+Many things can happen in controllers, and it often improves
+maintainability to abstract some of the code out into reusable base
+classes.
+
+You can provide usual Perl methods that will be available via your
+controller object, or you can even define Catalyst actions which will
+be inherited by the subclasses. Consider this controller base class:
+
+  package MyApp::Base::Controller::ModelBase;
+  use strict;
+  use base 'Catalyst::Controller';
+
+  sub list : Chained('base') PathPart('') Args(0) {
+      my ($self, $c) = @_;
+      my $model = $c->model( $self->{model_name} );
+      my $condition = $self->{model_search_condition} || {};
+      my $attrs = $self->{model_search_attrs} || {};
+      $c->stash(rs => $model->search($condition, $attrs);
+      }
+
+  sub load : Chained('base') PathPart('') CaptureArgs(1) {
+      my ($self, $c, $id) = @_;
+      my $model = $c->model( $self->{model_name} );
+      $c->stash(row => $model->find($id));
+      }
+  1;
+
+This example implements two simple actions. The C<list> action chains
+to a (currently non-existent) C<base> action and puts a result-set
+into the stash taking a configured C<model_name> as well as a search
+condition and attributes. This action is a
+L<chained|Catalyst::DispatchType::Chained> endpoint. The other action,
+called C< load > is a chain midpoint that takes one argument. It takes
+the value as an ID and loads the row from the configured model. Please
+not that the above code is simplified for clarity. It misses error
+handling, input validation, and probably other things.
+
+The class above is not very useful on its own, but we can combine it
+with some custom actions by sub-classing it:
+
+  package MyApp::Controller::Foo;
+  use strict;
+  use base 'MyApp::Base::Controller::ModelBase';
+
+  __PACKAGE__->config( model_name => 'DB::Foo',
+                       model_search_condition=> { is_active => 1 },
+                       model_search_attrs => { order_by => 'name' },
+                   );
+
+  sub base : Chained PathPart('foo') CaptureArgs(0) { }
+
+  sub view : Chained('load') Args(0) {
+      my ($self, $c) = @_;
+      my $row = $c->stash->{row};
+      $c->res->body(join ': ', $row->name,
+      $row->description); }
+  1;
+
+This class uses the formerly created controller as a base
+class. First, we see the configurations that were used in the parent
+class. Next comes the C<base> action, where everything chains off of.
+
+Note that inherited actions act like they were declared in your
+controller itself. You can therefor call them just by their name in
+C<forward>s, C<detaches> and C<Chained(..)> specifications. This is an
+important part of what makes this technique so useful.
+
+The new C<view> action ties itself to the C<load> action specified in
+the base class and outputs the loaded row's C<name> and C<description>
+columns. The controller C<MyApp::Controller::Foo> now has these
+publicly available paths:
+
+=over
+
+=item /foo
+
+Will call the controller's C<base>, then the base classes C<list>
+action.
+
+=item /foo/$id/view
+
+First, the controller's C<base> will be called, then it will C<load>
+the row with the corresponding C<$id>. After that, C<view> will
+display some fields out of the object.
+
+=back
+
+=head2 モデルとビュー(Models and Views)
+
+If the functionality you'd like to add is really a data-set that you
+want to manipulate, for example internal document types, images,
+files, it might be better suited as a model.
+
+The same applies for views. If your code handles representation or
+deals with the applications interface and should be universally
+available, it could be a perfect candidate for a view.
+
+Please implement a C<process> method in your views. This method will
+be called by Catalyst if it is asked to forward to a component without
+a specified action. Note that C<process> is B<not a Catalyst action>
+but a simple Perl method.
+
+You are also encouraged to implement a C<render> method corresponding
+with the one in L<Catalyst::View::TT>. This has proven invaluable,
+because people can use your view for much more fine-grained content
+generation.
+
+Here is some example code for a fictional view:
+
+  package CatalystX::View::MyView;
+  use strict;
+  use base 'Catalyst::View';
+
+  sub process {
+      my ($self, $c) = @_;
+      my $template = $c->stash->{template};
+      my $content = $self->render($c, $template, $c->stash);
+      $c->res->body( $content );
+  }
+
+  sub render {
+      my ($self, $c, $template, $args) = @_;
+      # prepare content here
+      return $content;
+  }
+  1;
+
+=head2 プラグイン(Plugins)
+
+The first thing to say about plugins is that if you're not sure if
+your module should be a plugin, it probably shouldn't. It once was
+common to add features to Catalyst by writing plugins that provide
+accessors to said functionality. As Catalyst grew more popular, it
+became obvious that this qualifies as bad practice.
+
+まずもって、あなたがプラグインをつくろうとおもっている場合、十中八九プラグインを
+つくるべきではありません。
+
+By designing your module as a Catalyst plugin, every method you
+implement, import or inherit will be available via your applications
+context object.  A plugin pollutes the global namespace, and you
+should be only doing that when you really need to.
+
+あなたのモジュールを Catalyst のプラグインとして実装した場合、あなたが実装したす
+べてのメソッドはあなたのアプリケーションの context object に継承されます。プラグ
+インはグローバルなネームスペースをけがします。あなたはほんとうにそうしたいときに
+だけそうするべきです。
+
+Often, developers design extensions as plugins because they need to
+get hold of the context object. Either to get at the stash or
+request/response objects are the widely spread reasons. It is,
+however, perfectly possible to implement a regular Catalyst component
+(read: model, view or controller) that receives the current context
+object via L<Catalyst::Component/"ACCEPT_CONTEXT($c, @args)">.
+
+When is a plugin suited to your task? Your code needs to be a
+plugin to act upon or alter specific parts of Catalyst's request
+lifecycle. If your functionality needs to wrap some C<prepare_*> or
+C<finalize_*> stages, you won't get around a plugin.
+
+Another valid target for a plugin architecture are things that
+B<really> have to be globally available, like sessions or
+authentication.
+
+B<Please do not> release Catalyst extensions as plugins only to
+provide some functionality application wide. Design it as a controller
+base class or another suiting technique with a smaller scope, so that
+your code only influences those parts of the application where it is
+needed, and namespace clashes and conflicts are ruled out.
+
+The implementation is pretty easy. Your plugin will be inserted in the
+application's inheritance list, above Catalyst itself. You can by this
+alter Catalyst's request lifecycle behaviour. Every method you
+declare, every import in your package will be available as method on
+the application and the context object. As an example, let's say you
+want Catalyst to warn you every time uri_for returned an undefined
+value, for example because you specified the wrong number of captures
+for the targeted action chain. You could do this with this simple
+implementation (excuse the lame class name, it's just an example):
+
+プラグインの実装は簡単なようにみえます。あなたのプラグインは Catalyst の継承ツリー
+の上にはいります。これによりあなたは、Catalyst のリクエストライフサイクルの挙動を
+変えることができます。あなたが定義したりあなたのパッケージに import したメソッド
+は、すべてアプリケーションとコンテキストオブジェクトにはえます。例としてあなたが
+Catalyst に uri_for の返り値が undef だったとき警告をだすプラグインをつくったとし
+ましょう。(中略)(アホみたいなクラス名ですいません。これは例なので勘弁してね)
+
+  package Catalyst::Plugin::UriforUndefWarning;
+  use strict;
+  use Class::C3;
+
+  sub uri_for {
+      my $c = shift;
+      my $uri = $c->next::method(@_);
+      $c->log->warn( 'uri_for returned undef for:', join(', ', @_), );
+      return $uri;
+  }
+
+  1;
+
+This would override Catalyst's C<uri_for> method and emit a C<warn>
+log entry containing the arguments that led to the undefined return
+value.
+
+これは Catalyst の C<uri_for> メソッドをうわがきし、undef がかえってきたら警告を
+ログに吐きだします。
+
+=head2 COMPONENT() をつかってコンポーネントを生成する(Factory components with COMPONENT())
+
+Every component inheriting from L<Catalyst::Component> contains a
+C<COMPONENT> method. It is used on application startup by
+C<setup_components> to instantiate the component object for the
+Catalyst application. By default, this will merge the components own
+C<config>uration with the application wide overrides and call the
+class' C<new> method to return the component object.
+
+L<Catalyst::Component> を継承しているすべてのコンポーネントは C<COMPONENT> メソッ
+ドをもっています。
+
+You can override this method and do and return whatever you want.
+However, you should use L<Class::C3> to forward to the original
+C<COMPONENT> method to merge the configuration of your component.
+
+Here is a stub C<COMPONENT> method:
+
+  package CatalystX::Component::Foo;
+  use strict;
+  use base 'Catalyst::Component';
+
+  use Class::C3;
+
+  sub COMPONENT {
+      my $class = shift;
+      my ($app_class, $config) = @_;
+
+      # do things here before instantiation my
+      $obj = $self->next::method(@_);
+      # do things to object after instantiation
+      return $object;
+  }
+
+The arguments are the class name of the component, the class name of
+the application instantiating the component, and a hash reference with
+the controller's configuration.
+
+You are free to re-bless the object, instantiate a whole other
+component or really do anything compatible with Catalyst's
+expectations on a component.
+
+For more information, please see L<Catalyst::Component/"COMPONENT($c,$arguments)">.
+
+=head1 SEE ALSO
+
+L<Catalyst>, L<Catalyst::Manual::Actions>, L<Catalyst::Component>
+
+=head1 AUTHOR
+
+Robert Sedlacek C<< <rs@474.at> >>
+
+Jonathan Rockway C<< <jrockway@cpan.org> >>
+
+=head1 LICENSE AND COPYRIGHT
+
+This document is free, you can redistribute it and/or modify it under
+the same terms as Perl itself.
+
+=cut