This is your new Play application
=====================================
This file will be packaged with your application, when using `play dist`.
Lesson 2:
Lesson 2: Parts of an application
Product catalogue
Features we will support:
1.Users will be able to browse a list of products, as well as add new ones.
Let's look at each directory at low level
We’ll have a closer look at each of the top level directories. The directory app
is the most important one, but we’ll skip that for now, and talk about the others
first
The directory is the build process’ working directory. This is where your target
compiled classes are stored, among other things. Just be sure to never commit it in
your versioning system. Actually, if you’re using git as your versioning system,
you probably won’t: Play also generated a .gitignore file for you, making sure you
never commit files that are generated at runtime.
Let's discuss about conf file:
1. Configurations for play applications:
application.conf
routes
application.conf : The file contains configuration about your Play
application. This is where you’ll configure things like logging, database
connections, which port the server runs on, and more
The application configuration file is loaded at startup time, and is globally
readable
routes:
Every line it the file defines a single route. Let’s focus on the first routes
route, we’ll explain what the second route does in section X.
Any route consist of 3 parts: the HTTP , the and the method path action method,
as illustrated in figure 2.1
Note about HTTP methods:
There’s a lot of documentation to be found about the HTTP protocol and its methods, and what they imply
The method of a HTTP request signifies the purpose of your request:
whether you want to retrieve a resource from the server, or post
information to it, for example. There are a number of different methods
defined in the HTTP specification, and some extensions to the protocol
add even more, but the two most-used methods in the HTTP standard
are and .
GET:
GET is a retrieval request for a resource and contains no body,
although the URL used may contain parameters (everything that comes
after the ). It is important that a GET request may have any ? never
lasting effects on the server; every time you GET a URL should have
the same effect
The fancy word for this is idempotence. The most
important thing to remember is that you should only use it for
information , not for submission of data.
POST:
The POST method, on the other hand, is a request for data submission,
and may contain a body. It is still directed at a URL, but a POST
request has effects server-side. A POST request is often used for forms
that create or modify information. This is why your browser will likely
warn you when you reload a URL that you just POSTed to before.
There are more methods in the HTTP standard, such as PUT and
DELETE, but we’ll talk about those when we’re discussing HTTP APIs.
The routes file is very important to any Play application.
Play gives you full control over your URL schema, you can design
clean, human readable, bookmarkable URLs.
project directory:
Of these files, you’ll only deal with Build.scala. Both
build.properties plugins.sbt and are SBT configuration files, which is
configured just fine as it is.
Talk about dependency management
Public assets:
Public assets are usually support files that are not actually your application.
Things like images, stylesheets, JavaScript files and static HTML pages are all
public assets. Public assets are not generated by you application, they’re just served
to the client.
As you can maybe guess from its contents and its name, the directory public
contains resources that are served directly, without any processing. This is actually
what the second route we saw in section 2.3 does: it makes the contents of this
directory available as public assets; files that are available to the client directly.
# Map static resources from the /public folder to the /assets URL path
GET /assets/*file controllers.Assets.at(path="/public", file)
If you’re interested in pre-processing certain files, such as Less stylesheets,
CofeeScript files or JavaScript files, be sure to read section 2.6.1 about compiled
assets. But first, let’s move on to the the directory.
app directory:
There is one file, Application.java, that contains Java code
implementing the business logic for generating the webpage. Classes that take a
HTTP request, run some logic on it, and return a HTTP result are called controller
classes, which explains why they’re in the controllers folder.
There are two files, template index.scala.html and
main.scala.html, which are responsible for defining the HTML page. Any
content that’s generated on the server and sent to the client in a HTTP body, such
as a HTML page, is called a , therefore, the files are in the folder.
The template files contain a template in Play’s Scala template syntax. An
important aspect of Scala templates is that they’re actually compiled to regular
classes. This has all sorts of advantages, the most important of which are
compile-time syntax and type checking.
Another thing that’s important to note about the directory is that it’s app
actually the root for all your source code, meaning that any subfolder will
automatically have to be a package, just like with any regular Java project