[catagits/Reaction.git] / lib / Reaction / Manual / Intro.pod

=head1 NAME

Reaction::Manual::Intro - Introduction to Reaction

=head1 INTRODUCTION

Reaction is basically an extended MVC:

=over

=item Domain Model 

DBIx::Class::Schema, MyApp::Foo, MyApp::Bar, etc.

=item Interface Model 

InterfaceModel::DBIC::Schema, InterfaceModel::Action,
MyApp::InterfaceModel::Foo classes.

=item Controller 

Mediation and navigation.

=item ViewPort

Event handling encapsulation.

=item Widget

View logic.

=item Renderer 

MyApp::View:: classes, renders viewports.

=back

=head1 THE REACTION WAY

The idea is you separate your domain model, which encapsulates the domain
itself from your interface model, which is a model of how a particular app or
class of apps interact with that domain and provides objects/methods to
encapsulate the common operations it does.

=head2 Domain Models vs Interface Models

Domain models are expected to drive the application business logic and data.
All domain models that need to be effectively displayed somehow at the user
interface (a table, for instance) must interact with an interface model.
These should provide the common methods needed in order to carry out
user-generated events.

=head1 SETTING UP A REACTION APPLICATION

Reaction applications are set up just like Catalyst:

    $ catalyst.pl MyApp
    # output ommited
    $ cd MyApp

=head2 Models

Reaction provides a reflector component which automagically
maps a L<DBIx::Class::Schema> into a set of Interface Models which can be used
by Reaction to build the interface components. If you're not familiar with
L<DBIx::Class> or don't have a schema handy, now is a good time to go through
L<DBIx::Class::Manual::Intro> to get a schema set up.

    package MyApp::InterfaceModel::DBIC;

    use base 'Reaction::InterfaceModel::Object';
    use Reaction::InterfaceModel::Reflector::DBIC;

    my $reflector = Reaction::InterfaceModel::Reflector::DBIC->new;

    $reflector->reflect_schema(
         model_class  => __PACKAGE__,
         schema_class => 'MyApp::Schema',
         sources => [qw/Foo Baz/],
    );

    1;

=head2 Controllers

Your Reaction application must have a Root controller which inherits from
C<Reaction::UI::Controller::Root>.

    package MyApp::Controller::Root;

    use warnings;
    use strict;
    use base qw/Reaction::UI::Controller::Root/;

    __PACKAGE__->config(
        view_name => 'Site',
        window_title => 'My Reaction App',
        namespace => ''
    );

    1;

XX TODO

=head2 View

XX TODO

=head1 SEE ALSO

=over 

=item * L<Reaction::Manual::Cookbook>

=item * L<Reaction::Manual::FAQ>

=back

=head1 AUTHORS

See L<Reaction::Class> for authors.

=head1 LICENSE

See L<Reaction::Class> for the license.

=cut
Commit	Line	Data
df2804f5	1	=head1 NAME
	2
	3	Reaction::Manual::Intro - Introduction to Reaction
	4
	5	=head1 INTRODUCTION
	6
	7	Reaction is basically an extended MVC:
	8
	9	=over
	10
	11	=item Domain Model
	12
	13	DBIx::Class::Schema, MyApp::Foo, MyApp::Bar, etc.
	14
	15	=item Interface Model
	16
	17	InterfaceModel::DBIC::Schema, InterfaceModel::Action,
	18	MyApp::InterfaceModel::Foo classes.
	19
	20	=item Controller
	21
	22	Mediation and navigation.
	23
	24	=item ViewPort
	25
	26	Event handling encapsulation.
	27
	28	=item Widget
	29
	30	View logic.
	31
	32	=item Renderer
	33
	34	MyApp::View:: classes, renders viewports.
	35
	36	=back
	37
	38	=head1 THE REACTION WAY
	39
	40	The idea is you separate your domain model, which encapsulates the domain
	41	itself from your interface model, which is a model of how a particular app or
	42	class of apps interact with that domain and provides objects/methods to
	43	encapsulate the common operations it does.
	44
	45	=head2 Domain Models vs Interface Models
	46
	47	Domain models are expected to drive the application business logic and data.
	48	All domain models that need to be effectively displayed somehow at the user
	49	interface (a table, for instance) must interact with an interface model.
	50	These should provide the common methods needed in order to carry out
	51	user-generated events.
	52
	53	=head1 SETTING UP A REACTION APPLICATION
	54
	55	Reaction applications are set up just like Catalyst:
	56
	57	$ catalyst.pl MyApp
	58	# output ommited
	59	$ cd MyApp
	60
	61	=head2 Models
	62
	63	Reaction provides a reflector component which automagically
	64	maps a L<DBIx::Class::Schema> into a set of Interface Models which can be used
65	by Reaction to build the interface components. If you're not familiar with
66	L<DBIx::Class> or don't have a schema handy, now is a good time to go through
67	L<DBIx::Class::Manual::Intro> to get a schema set up.
68
69	package MyApp::InterfaceModel::DBIC;
70
71	use base 'Reaction::InterfaceModel::Object';
72	use Reaction::InterfaceModel::Reflector::DBIC;
73
74	my $reflector = Reaction::InterfaceModel::Reflector::DBIC->new;
75
76	$reflector->reflect_schema(
77	model_class => __PACKAGE__,
78	schema_class => 'MyApp::Schema',
79	sources => [qw/Foo Baz/],
80	);
81
82	1;
83
84	=head2 Controllers
85
86	Your Reaction application must have a Root controller which inherits from
87	C<Reaction::UI::Controller::Root>.
88
89	package MyApp::Controller::Root;
90
91	use warnings;
92	use strict;
93	use base qw/Reaction::UI::Controller::Root/;
94
95	__PACKAGE__->config(
96	view_name => 'Site',
97	window_title => 'My Reaction App',
98	namespace => ''
99	);
100
101	1;
102
103	XX TODO
104
105	=head2 View
106
107	XX TODO
108
109	=head1 SEE ALSO
110
111	=over
112
113	=item * L<Reaction::Manual::Cookbook>
114
115	=item * L<Reaction::Manual::FAQ>
116
117	=back
118
119	=head1 AUTHORS
120
121	See L<Reaction::Class> for authors.
122
123	=head1 LICENSE
124
125	See L<Reaction::Class> for the license.
126
127	=cut