diff options
| -rw-r--r-- | Makefile.PL | 45 | ||||
| -rw-r--r-- | lib/Reaction/Manual/Glossary.pod | 10 | ||||
| -rw-r--r-- | lib/Reaction/Manual/RenderPage.pod | 51 | ||||
| -rw-r--r-- | lib/Reaction/Manual/Tutorial.pod | 24 |
4 files changed, 84 insertions, 46 deletions
diff --git a/Makefile.PL b/Makefile.PL index 699ad33..aa061d2 100644 --- a/Makefile.PL +++ b/Makefile.PL @@ -9,40 +9,45 @@ author 'Matt S Trout <mst@shadowcat.co.uk>'; all_from 'lib/Reaction.pm'; requires 'Catalyst' => '5.7002'; -requires 'Catalyst::Component::InstancePerContext' => 0; +requires 'Catalyst::Component::ACCEPT_CONTEXT'; +requires 'Catalyst::Component::InstancePerContext'; +requires 'Catalyst::Model::DBIC::Schema' => 0; requires 'Catalyst::Plugin::ConfigLoader' => 0.19; -requires 'Catalyst::Plugin::Static::Simple' => 0; requires 'Catalyst::Plugin::I18N' => 0; -requires 'Catalyst::Model::DBIC::Schema' => 0; +requires 'Catalyst::Plugin::Static::Simple' => 0; requires 'Catalyst::View::TT' => '0.23'; requires 'Config::General' => 0; -requires 'Test::Class' => 0; -requires 'Test::Memory::Cycle' => 0; +requires 'Crypt::Eksblowfish::Bcrypt'; # lib/Reaction/InterfaceModel/Object/User/Role/ConfirmationCodeSupport.pm +requires 'Class::MOP'; requires 'DBIx::Class' => '0.07001'; requires 'DBIx::Class::IntrospectableM2M' => '0.001000'; -requires 'SQL::Translator' => '0.08'; -requires 'Moose' => '0.58'; -requires 'aliased' => 0; requires 'DateTime'; -requires 'DateTime::Span'; requires 'DateTime::Event::Recurrence'; -requires 'DateTime::Format::MySQL'; -requires 'Time::ParseDate'; -requires 'Email::Valid'; -requires 'Crypt::Eksblowfish::Bcrypt'; -requires 'Email::Send'; -requires 'Email::MIME'; -requires 'Email::MIME::Creator'; -requires 'Text::CSV_XS'; +requires 'DateTime::Span'; requires 'Devel::Declare' => '0.003004'; +requires 'Email::Valid'; +requires 'File::ShareDir' => '1.00'; # +requires 'File::Spec'; +requires 'Moose' => '0.58'; requires 'MooseX::Types' => '0.04'; requires 'MooseX::Types::Common'; requires 'MooseX::Types::DateTime'; +requires 'Path::Class::Dir'; +requires 'Path::Class::File'; requires 'Scalar::Util'; -requires 'File::ShareDir' => '1.00'; +requires 'Sub::Exporter'; +requires 'Sub::Name'; +requires 'Template'; +requires 'Time::ParseDate'; +requires 'URI'; +requires 'aliased'; requires 'namespace::clean' => '0.08'; -requires 'Catalyst::Component::ACCEPT_CONTEXT'; -requires 'Catalyst::Component::InstancePerContext'; +requires 'metaclass'; + +test_requires 'Test::Class'; +test_requires 'Test::WWW::Mechanize::Catalyst'; +test_requires 'Test::Memory::Cycle'; +test_requires 'SQL::Translator' => '0.08'; # for deploy in tests install_share; diff --git a/lib/Reaction/Manual/Glossary.pod b/lib/Reaction/Manual/Glossary.pod index 21480e8..d4cab76 100644 --- a/lib/Reaction/Manual/Glossary.pod +++ b/lib/Reaction/Manual/Glossary.pod @@ -8,8 +8,14 @@ Reaction::Manual::Glossary - Terms and Definitions used in Reaction =head3 Domain Model +=head3 Focus Stack + =head3 Interface Model +=head3 Layout + +=head3 LayoutSet + =head3 ListView =head3 MVC @@ -20,10 +26,14 @@ Model-View-Controller - a high-level software design pattern, which focuses on s A software design pattern in which one +=head3 RenderingContext + =head3 Role A particular interface that a class implements. Here, Role is used in the sense of Moose::Role; this same concept is sometimes called a Mix-In Class or a Decorator pattern. +=head3 Skin + =head3 View In Reaction, the View modules handle rendering the ViewPort. ViewPorts are the V in MVC. diff --git a/lib/Reaction/Manual/RenderPage.pod b/lib/Reaction/Manual/RenderPage.pod index c0b92f8..2c2a19d 100644 --- a/lib/Reaction/Manual/RenderPage.pod +++ b/lib/Reaction/Manual/RenderPage.pod @@ -3,37 +3,48 @@ =head2 Or, how to track why your page failed to render -Catalyst's C<end> action is supplied by -L<Reaction::UI::Controller::Root>, which your C<Root> controller -should inherit from, or at least the root controller of the part of -your application that is using Reaction. The C<end> action calls -L<Reaction::UI::Window/flush> which in turn calls -L<Reaction::UI::View/render_window>. +Catalyst's C<begin> and C<end> actions are supplied by +L<Reaction::UI::Controller::Root>, which your C<Root> controller should inherit +from, or at least the root controller of the part of your application that is +using Reaction. + +The C<begin> action creates a new L<Reaction::UI::Window> and stores it in $c->stash->{window}. +The C<end> action calls the flush() method on the stashed window object. +L<Reaction::UI::Window/flush> then calls L<Reaction::UI::View/render_window> +on the window's view. The View first fetches the root ViewPort from the Window's stack and creates a RenderingContext. The layout is chosen based on the ViewPort name or though the ViewPort's C<layout> attribute. The Widget is then used to render the content via the RenderingContext. +Is your head spinning yet? + Ingredients used: -* LayoutSet class: Reaction::UI::LayoutSet -* RenderingContext class: Reaction::UI::RenderingContext::TT + * A Reaction::UI::Skin object built from: - * The skin_name set on your View - * The View object - * The skin_base_dir (MyApp/share/skin) - * The share/skin/defaults.conf + share/skin/<my_skin>/skin.conf + + - The skin_name set on your View + - The View object + - The skin_base_dir (MyApp/share/skin) + - The share/skin/defaults.conf + share/skin/<my_skin>/skin.conf + * A Reaction::UI::LayoutSet object built from: - * The layoutset file itself, found in the share/skin/<my_skin>/layout directory - or the share/skin/default/layout directory. - * The Skin object + + - The layoutset file itself, found in the share/skin/<my_skin>/layout directory + or the share/skin/default/layout directory. + - The Skin object + * A Reaction::UI::Widget object built from: - * It's class, determined from the name of the ViewPort or read from the - layoutset file, and found in the widget_search_path. - * The View object - * The LayoutSet object + + - It's class, determined from the name of the ViewPort or read from the + layoutset file, and found in the widget_search_path. + - The View object + - The LayoutSet object + * A Reaction::UI::RenderingContext::TT object built from: - * Nothing + + - Nothing To render the window the correct Reaction::UI::Widget object is retrieved via the LayoutSet for the root ViewPort of the page. diff --git a/lib/Reaction/Manual/Tutorial.pod b/lib/Reaction/Manual/Tutorial.pod index 1753577..38f98f8 100644 --- a/lib/Reaction/Manual/Tutorial.pod +++ b/lib/Reaction/Manual/Tutorial.pod @@ -17,6 +17,12 @@ script as we would for any other Catalyst application: There is nothing to change in the application class file. +As you work through this tutorial you'll be creating several new files in +various directories. You can save some time by creating the directories now, +like this: + + mkdir -p share/skin/myapp/layout lib/MyApp/View/Site/Widget lib/MyApp/Schema lib/MyApp/InterfaceModel + =head1 THE VIEW Since we are not just rendering templates with Reaction, but layouts and widgets, @@ -239,7 +245,7 @@ takes this one step further by introducing so called interface models. The inter defines the layer between your application and your domain model (in this case, the L<DBIx::Class> schema). -The first thing we will need is a schema class: +The first thing we will need is a schema class in C<lib/MyApp/Schema.pm>: package MyApp::Schema; use strict; @@ -267,7 +273,7 @@ called C<example.sqlite>: $ The result class for this table combines the usual style of L<DBIx::Class> with L<Moose> meta -data additions: +data additions in C<lib/MyApp/Schema/Foo.pm>: package MyApp::Schema::Foo; use Moose; @@ -325,7 +331,8 @@ inspect many-to-many relations later on. The interface model should be separated from the application and the schema, since it will tie both together. In this case, we will use a reflector to set up the usual interface -model actions for our schema (C<Create>, C<Update>, C<Delete>, C<DeleteAll>): +model actions for our schema (C<Create>, C<Update>, C<Delete>, C<DeleteAll>) in +C<lib/MyApp/InterfaceModel/DBIC.pm>: package MyApp::InterfaceModel::DBIC; @@ -376,13 +383,18 @@ this we create a simple catalyst model in C<lib/MyApp/Model/DBIC.pm>: This model L<extends|Moose> the L<Catalyst::Model::Reaction::InterfaceModel::DBIC> base class shipped with Reaction. It's configuration must contain the C<im_class> naming our interface -model and the C<db_dsn>. Of course, since this is Catalyst, this can also easily be specified +model and the C<db_dsn>. If you're using a different kind of database then you +may neeb to add config for C<db_user>, C<db_password>, and C<db_params>. +All these get passed to the schema's connect() method. + +Of course, since this is Catalyst, all this can also easily be specified via your application config file under the C<Model::DBIC> key. =head1 BUILDING A SIMPLE CRUD CONTROLLER Now, since we have defined our interface model as well as our domain model including meta -data, it isn't very hard (at least not for us) to build a basic (but extendable) CRUD controller: +data, it isn't very hard (at least not for us) to build a basic (but extendable) +CRUD controller in C<lib/MyApp/Controller/Foo.pm>: package MyApp::Controller::Foo; use strict; @@ -411,7 +423,7 @@ As you can see, for the simplest case we don't need any code; we simply configur The C<model_name> is the name of our interface model sans the C<MyApp::Model::> prefix. This means this entry points to C<MyApp::Model::DBIC> in this case. The C<collection_name> is the name of -the collection in the specified interface model. For us, this would be C<Foo>, like the result +the collection in the specified interface model. For us, this would be C<Foo>, to match the result class we created above and want to manage. The C<actions> part of the configuration is not Reaction, but rather Catalyst specific. This |