Commit | Line | Data |
1f9daa1e |
1 | =head1 NAME |
2 | |
3 | Reaction::Manual::FAQ |
4 | |
5 | =head2 INTRODUCTION |
6 | |
7 | =head3 What is Reaction? |
8 | |
9 | Reaction is an MVCish framework that is designed with two goals in mind: |
10 | "don't repeat yourself" and "components rule." |
11 | |
12 | =head3 How is it different from other MVC frameworks? |
13 | |
14 | Reaction is more flexible and abstract. Web development is only a specialized |
15 | set of what Reaction is designed to provide - the inner classes are general |
16 | enough to be used in many different environments and for solving non-web |
17 | problems. |
18 | |
19 | It is planned to go a lot further than just the web - we want to develop GUIs |
20 | and CLIs as easily and painlessly as possible, using Reaction. How about |
21 | writing your web application and instantly getting a CLI to go with it? That's |
22 | only part of the flexibility we have in mind. |
23 | |
24 | =head3 How is it different from Catalyst? |
25 | |
26 | Catalyst is MVC-based whereas Reaction splits the Model into 2 parts: The |
27 | "Domain Model" and the "Interface Model." Web development is only a sample of |
28 | what Reaction can do - but it already comes bundled with the basic components |
29 | that you would have to program in Catalyst. At the moment, Reaction runs on |
30 | Catalyst for web development. |
31 | |
32 | =head3 What's a Domain? |
33 | |
34 | A domain is the field where an abstraction makes sense. For example, to build |
35 | a web site a programmer may come up with an abstraction of a User, Products, |
36 | User roles, etc. These concepts are just one particular implementation of all |
37 | the possible abstractions for that web site -- the set of all these possible |
38 | abstractions make up the Domain. |
39 | |
40 | =head3 What's a Domain Model? |
41 | |
42 | A Domain Model is an actual computational model of an abstraction. In most |
43 | cases these models are business-based, as in the set of objects that make up |
44 | the representation for a particular domain, such as Users, Products, User |
45 | Roles, etc. |
46 | |
47 | =head3 What's an Interface Model? |
48 | |
49 | A well defined model for the common operations involved in a particular mode |
50 | of interaction with the domain. In other words, it's a layer around the Domain |
51 | Model that provides interaction with it. One example would be an authorization |
52 | procedure for different views of the same data, based on user's credentials. |
53 | |
54 | =head3 I'm lost! What does "Model" mean? |
55 | |
56 | The term "model" can mean two things: "model as in Computer Model" and "Model |
57 | as in MVC". For this document, the former will be written as just "Model" |
58 | whereas the latter will be referred to as "Model as in MVC." |
59 | |
60 | =head3 Haven't I seen these definitions elsewhere? |
61 | Yes, similar terms have been used in Java-land and Smalltalk-ville. Note that |
62 | for the sake of simplicity we are not giving rigorous (and more complex) |
63 | definitions. |
64 | |
65 | =head3 What's a View? |
66 | |
67 | =head3 What's a Viewport? |
68 | |
69 | ListView and ActionForm are subclasses of ViewPort. |
70 | |
71 | =head3 What's a Focus Stack? |
72 | |
73 | =head3 What are Tangents? |
74 | |
75 | =head3 Can I have a pony? |
76 | |
77 | =head2 USING REACTION |
78 | |
79 | =head3 Where do I put my HTML? |
80 | |
81 | Packages involved |
82 | ComponentUI |
83 | ComponentUI::Controller::Bar |
84 | ComponentUI::Controller::Baz |
85 | ComponentUI::Controller::Foo |
86 | ComponentUI::Controller::Root |
87 | ComponentUI::Model::TestDB |
88 | ComponentUI::Model::Action |
89 | ComponentUI::View::XHTML |
90 | |
91 | CRUD |
92 | |
93 | =head1 AUTHORS |
94 | |
95 | See L<Reaction::Class> for authors. |
96 | |
97 | =head1 LICENSE |
98 | |
99 | See L<Reaction::Class> for the license. |
100 | |
101 | =cut |