Play is a Java and Scala web application framework with excellent efficiency that unifies parts and APIs for contemporary web application development. Web developers created Play for the creation of web applications. Play connects with several object-relational mapping (ORM) layers and has no preconceived notions about how to access databases. Although many users of this ORM utilize NoSQL or other ORMs, it comes with built-in support for Anorm, Slick, and JPA.
In this article, we will discuss the introduction to the Play application, play application layout, directories, typical gitignore file, and default sbt layout.
The play application layout
A Play application's design is standardized to make things as easy as possible. When the initial compilation is successful, the project structure appears as follows:
1.app → It describes the Application sources
1.1 assets → It Compiled the asset sources
1.1.1 stylesheets → It has the Typically LESS CSS sources
1.1.2 javascripts → It has the Typically CoffeeScript sources
1.2 controllers → It describes the Application controllers
1.3 models → It describes the Application business layer
1.4 views → It has the Templates
2.build.sbt → It has the Application build script
3.conf → It has the Configurations files and other non-compiled resources (on classpath)
4.application.conf → It has the Main configuration file
5.routes → It has the Routes definition
6.dist → It has the Arbitrary files to be included in your projects distribution
7.public → It contains the Public assets
7.1 stylesheets → It has the CSS files
7.2 javascripts → It has the Javascript files
7.3 images → It has the Image files
8. project → It has the sbt configuration files
8.1 build.properties → It has the Marker for sbt project
8.2 plugins.sbt → It has the sbt plugins including the declaration for Play itself
9.lib → It Unmanaged libraries dependencies
10.logs → It Logs the folder
10.1 application.log → It has the Default log file
11.target → It has Generated stuff
11.1 resolution-cache → It has Info about dependencies
11.2 scala-2.13
11.2.1 api → It has Generated API docs
11.2.2 classes →It has Compiled class files
11.2.3 routes → It has the Sources generated from routes
11.2.4 twirl → It has the Sources generated from templates
11.3 universal → It contains the Application packaging
11.4 web → It has the Compiled web assets
12. test → It has the source folder for unit or functional tests
Directories
The app/ directory
All executable artifacts, including the sources for generated components and the Java and Scala source code, are contained in the app directory.
The app directory contains three packages, one for each part of the MVC architectural pattern:
app/controllers
app/models
app/views
You can add your own packages, like a package for apps and services.
The public/directory
Static assets are those that are kept in the public directory and are immediately provided by the web server.
This directory has three subdirectories: one for photos, one for CSS stylesheets, and one for JavaScript scripts. You should arrange your static assets to maintain consistency across all Play applications.
In a newly created application, the /public directory is mapped to the /assets URL route; however, you may easily change that or even utilize different folders for your static assets.
The conf/directory
The application's configuration files are located in the conf directory. The two primary configuration files are:
Application.conf is the primary configuration file used by the application routes definition file.
If you need to add configuration settings particular to your application, it's a good idea to add more options to the application.conf file.
If a library requests one, it is a good idea to provide a custom configuration file in the conf directory.
The lib/directory
The unmanaged library dependencies, or all JAR files you choose to manually manage outside of the build system, are located in the optional lib directory. Any JAR files can be dropped here and will be added to your application's classpath.
The build.sbt file
The build.sbt file at the project's root often contains the primary build declarations for your project.
The project/directory
The sbt build definitions are located in the project directory:
plugins.sbt project's use of sbt plugins is defined by it.
The sbt version you should use to create your app is contained in build.properties.
The target/directory
Everything that the build system produces is located in the target directory. It can be helpful to understand what is produced here:
All compiled classes can be found in classes/. (from both Java and Scala sources).
Classes managed/ only includes classes the framework contains (such as the classes generated by the router or the template system). This class folder can be added to your IDE project as an external class folder.
The resource managed/ directory holds created resources, usually the output of compilations, such as LESS CSS and CoffeeScript components.
Generated sources, like the Scala sources produced by the template system, are found in the directory src managed/.
web/ houses the assets that sbt-web processes, including those from the public directories and app/assets.
Typically .gitIgnore file
Your version control system should disregard generated folders. This is the usual. An application for Play's gitignore file:
Additionally, you can employ the sbt and Maven default layout. You must disable the layout plugin and configure explicit monitoring for twirl templates in order to use this layout:
lazy val root: Project = (project in file("."))
.enablePlugins(PlayScala)
// Using the sbt default layout
.disablePlugins(PlayLayoutPlugin)
This will prevent Play from changing the sbt layout, which is as follows:
1.build.sbt → It has the Application build script
2.src → It has the Application sources
2.1 main → It contains the Compiled asset sources
2.2 java → It has the Java sources
2.2.1 controllers → It has the Java controllers
2.2.2 models → It contains the Java business layer
2.3 scala → It has the Scala sources
2.3.1 controllers → It contains the Scala controllers
2.3.2 models → It has the Scala business layer
2.4 resources → It has Configurations files and other non-compiled resources (on classpath)
2.4.1 application.conf → It contains the Main configuration file
2.4.2 routes → It has the Routes definition
2.5 twirl
2.6 views → It has the Templates
2.7 assets → It contains the Compiled asset sources
2.8 CSS → It has the Typically LESS CSS sources
2.8.1 js → It has the Typically CoffeeScript sources
3. public → It contains the Public assets
3.1 CSS → It has the CSS files
3.2 js → It has the Javascript files
3.3 images → It contains the Image files
4. test → It has the Unit or functional tests
4.1 java → It contains the Java source folder for unit or functional tests
4.2 scala → It has the Scala source folder for unit or functional tests
4.3 resources → It has the Resource folder for unit or functional tests
5.universal → It contains the Arbitrary files to be included in your projects distribution
6.project → It has the sbt configuration files
6.1 build.properties → It contains the Marker for sbt project
6.2 plugins.sbt → It has the sbt plugins including the declaration for Play itself
7. lib → It is used to Unmanaged libraries dependencies
8. logs → It has the Logs folder
8.1 application.log → It has the Default log file
9. target → It has the Generated stuff
9.1 scala-2.13
9.1.1 cache
9.1.2 classes → It has the Compiled class files
9.1.3 classes_managed → It has the Managed class files (templates, ...)
9.1.4 resource_managed → It has the Managed resources (less, ...)
9.1.5 src_managed → It contains the Generated sources (templates, ...)
Frequently Asked Questions
What purpose serves the Play framework?
Scala & Java developers may create web applications quickly and easily with Play Framework. Play's architecture is lightweight, stateless and suitable for the web. Play, which is based on Akka, gives highly scalable applications predictable and low resource consumption (CPU, memory, threads).
How does the Play Framework define MVC?
A play application adheres to the Web architecture's MVC architectural pattern. The Presentation layer and the Model layer are divided into independent layers by this pattern. A View and a Controller layer are further divided into the Presentation layer.
Define sbt in the play framework.
SBT files specify project settings. In addition, as detailed in the sbt manual, you can create your own unique custom parameters for your project. Knowing the sbt settings, in particular, is beneficial.
Conclusion
In this article, we have extensively discussed the introduction to the Play application, play application layout, directories, typical gitignore file, and default sbt layout.
After reading about the Anatomy of a play application, are you not feeling excited to read/explore more articles on the topic of file systems? Don't worry; Coding Ninjas has you covered. If you want to check out articles related to Play Application refer to these links: