-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathMVC_Framework.html
More file actions
254 lines (202 loc) · 10.3 KB
/
MVC_Framework.html
File metadata and controls
254 lines (202 loc) · 10.3 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<!-- saved from url=(0108)https://cygnus.cc.kuleuven.be/bbcswebdav/pid-14352243-dt-content-rid-29260566_3/orgs/C130069-B-1415/MVC.html -->
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>MVC Framework</title>
</head>
<body>
<div id="header">
Distributed Applications<br>
KU Leuven - Campus Groep T<br>
2015-2016<br>
</div>
<div id="groupmembers">
<ul>
<li>Matthias Mombaerts</li>
<li>Max Helskens</li>
<li>Vincent Ceulemans</li>
</ul>
</div>
<h1>Play Framework (2.5)</h1>
<h2>Short description</h2>
<p>
Play was first released in 2007. It is built on Scala (and some Java). It aims at developer friendlyness and high scalability.
Can be used with Java or Scala as programming language.
</p>
<h2>Technical features</h2>
<h3>MVC solution</h3>
<p>
The model layer is not strictly defined by Play. It can be an ordinary Java class, a JPA entity...
</p>
<p>
For the controller layer Play provides a Controller superclass which must be inherited.
A controller consists of different Actions (methods) which are mapped to URLs via a seperate 'routes' configuration file.
</p>
<p>
The view layer consists of a proprietary templating engine using Scala.
</p>
<p>
The project structure is very transparant with adjecent /models, /views and /controllers directories.
</p>
<h3>Navigation</h3>
<p>
URLs are mapped to Actions (controller methods) using a seperate config file. URL parameters can be specified and mapped to become input arguments of the Action method.
This is clear for small applications, but may become cumbersome for large projects because each Action must be explicitly listed.
</p>
<p>
Templates can refer to a "logical" name - a combination of the controller name and method -
which is replaced by the real URL after rendering.
</p>
<h3>Form handling</h3>
<p>
Play uses a FormFactory to create a Form object with a binding to a model class.
The Form object can construct the model, store validation errors and fill itself with values from an existing model.
HTML form parameters are automatically binded when submitting.
</p>
<p>
The templating engine includes a helper library to generate the correct HTML markup for the form and input tags.
</p>
<p>
By default the Form object cannot deal with OneToMany / ManyToMany relations. Those fields in the model/entity will generate generic errors when submitting the form.
The developer must provide its own 'Data binder' to map the form input (for instance a group of checkboxes) to the correct entity and vice versa.
While not too difficult, it is cumbersome.
</p>
<h3>Validation</h3>
<p>
Entity classes can be annotated with JSR-303 (Bean Validation) annotation or Play's own Constraints annotations.
These are automatically used for validating and rendering Forms.
</p>
<h3>Server-side handling of user interface events</h3>
<p>Not suported</p>
<h3>Rendering</h3>
<p>
Play uses the Twirl template engine. It uses Scala as expression language.
Usage is similar to JSTL. For simple templates you can convert from one to the other by replacing the '$'-signs with an '@' sign.
</p>
<pre>
<code>
JSTL: ${item.id}
TWIRL: @item.getId()
</code>
</pre>
<p>
Other constructs like for loops are slightly different since they use the Scala syntax.
</p>
<pre>
<code>
@for(item <- list){
<li>@item.getName()</li>
}
</code>
</pre>
<p>
Twirl is not so strict with delimiters. The @ sign indicates the start of an expression but there is no need to specify an end delimiter.
The engine can determine this automagicaly.
</p>
<p>
Twirl is interesting in that its templates are called like functions from the controller and can accept arguments.
</p>
<pre>
<code>
@(title: String)
<!DOCTYPE html>
<html>
...
</code>
</pre>
<p>
This allows for more decoupling since the variable name can change without modyfing the call to the template.
It is also more clear which variables are used by each template.
</p>
<h3>I18N and L10N</h3>
<p>Each language is defined in a seperate text file containing key value pairs. (Same format as ResourceBundles in JSP).</p>
<p>Using it in the templates is really simple:</p>
<pre>
<code>
<span>@Messages("viewall")</span>
</code>
</pre>
<p>This is much shorter and clearer than the JSTL equivalent.</p>
<h3>JavaScript integration</h3>
<p>
A JavaScript router can be generated. This is used to generate URLs in JavaScript code (for instance: A JQuery Ajax Request).
This is a nice alternative to hard coding URLs in the JavaScript files.
</p>
<h2>Documentation</h2>
<h3>Kind of documentation, quality, up-todate</h3>
<p>
Official documentation consists of a series of written pages explaining each concept of the framework.
The documentation is split into a part for Java developers and Scala developers.
They both deal with the same subjects but differ in the language (Java or Scala) of the examples.
</p>
<p>
The documentation and API are often lacking in verbosity leaving the developer to find out certain details. (For instance simple things like: where should I create this file).
<p>
Some features (certain form related template tags) are only mentioned in the API and not in the documentation.
For generating forms only the inputText tag is mentioned. To create checkboxes, radio buttons and select boxes there exist tags, but they are only found after carefully looking at the API.
</p>
<p>
While the written documentation is up to date, some other parts are not.
Most notably: the introduction video on the main site uses an outdated version of the framework.
</p>
<p>
Many other examples from other sources also use older versions. This is annoying since major changes have occured between seemingly small updates.
(For instance the 2.5, 2.4 series are not backward compatible as you would expect.). Also: Searching on Google often returns pages from older versions of the documenation, leading developers astray.
</p>
<h3>Community activity</h3>
<p>
Play has an active mailinglist, and much animo on their Github repository (activity in Bug tracker, Pull requests etc).
</p>
<p>
Though they claim to have over 10.000 questions on StackOverflow the reality is that most of these have none or few answers.
</p>
<p>
Some controversy aparently exists on the switch from the 1.x series to 2.x series which gravely broke backwards compatibility.
(<a href="http://www.elidedbranches.com/2012/03/why-im-moving-away-from-play-framework.html">http://www.elidedbranches.com/2012/03/why-im-moving-away-from-play-framework.html</a>)
Several developers moved on or continued using the 1.x series.
</p>
<h2>Future evolution</h2>
<p>The Play Github repository shows almost daily contributions and version 2.5.4 was released just recently.</p>
<p>A roadmap exists for versions 2.6 and 3.0 focussing more on small improvements and fixes.</p>
<p>Conclusion: the project is still active. But no game changing features are planned at this moment.</p>
<h2>Your perception</h2>
<p>The framework is straightforward and a joy to use for simple projects, when moving to advanced topics it becomes increasingly difficult.</p>
<p>If you stay within the basic set of features offered it will provide very low development work and time.</p>
<h3>Ease of use</h3>
<p>
The framework is very easy to use, with minimal boiler plate code and clear syntax.
Its features are not that advanced but avoid a too high level of abstraction.
</p>
<h3>Ease of installation</h3>
<p>
Play uses a custom IDE and server running in a web browser. Installation exists of downloading a zip file and running a bash script to run this service.
The setup does however take some time (apparently due to many dependencies being downloaded) but requires very little input from the user.
Since a server is included the installation is painless.
Using your own editor like Netbeans requires some additional configuration steps.
Deploying the final application on a production server may be somewhat difficult since no war files can be generated.
(Play uses its own format)
</p>
<h3>Learning curve</h3>
<p>
The initial learning curve is gently. With the help of the many quick start projects available from the editor you can get fast results.
</p>
<p>
It gets difficult though when moving on to slightly more advanced features. This is because many tutorials and examples are outdated. (See part about Documentation)
</p>
<p>Beginners may see learning the basics of Scala language as an obstacle. Though in practice only very simple constructs are needed.</p>
<h2>Practical information</h2>
<h3>Website</h3>
<p>
<a href="https://www.playframework.com/">
https://www.playframework.com/
</a>
</p>
<h3>Download</h3>
<p>
<a href="https://www.playframework.com/download">
https://www.playframework.com/download
</a>
</p>
</body>
</html>