Code360 powered by Coding Ninjas X Naukri.com. Code360 powered by Coding Ninjas X Naukri.com
Table of contents
1.
Introduction
2.
The play application layout
3.
Directories
3.1.
The app/ directory
3.2.
The public/directory
3.3.
The conf/directory
3.4.
The lib/directory
3.5.
The build.sbt file
3.6.
The project/directory
3.7.
The target/directory
3.8.
Typically .gitIgnore file
4.
Default sbt layout
5.
Frequently Asked Questions
5.1.
What purpose serves the Play framework?
5.2.
How does the Play Framework define MVC?
5.3.
Define sbt in the play framework.
6.
Conclusion
Last Updated: Mar 27, 2024
Medium

Anatomy of a play application

Author Ashish Sharma
0 upvote

Introduction

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. 

       

Play application description

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

types of 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:

 

logs
project/project
project/target
target
tmp
dist
.cache
RUNNING_PID

Default sbt layout

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:

Refer to our Guided Path on Coding Ninjas Studio to upskill yourself in Data Structures and AlgorithmsCompetitive ProgrammingJavaScriptSystem Design, and many more! If you want to test your competency in coding, you may check out the mock test series and participate in the contests hosted on Coding Ninjas Studio! But suppose you have just started your learning process and are looking for questions asked by tech giants like Amazon, Microsoft, Uber, etc. In that case, you must look at the problemsinterview experiences, and interview bundle for placement preparations.

Nevertheless, you may consider our paid courses to give your career an edge over others!

Do upvote our blogs if you find them helpful and engaging!

Happy Learning!

Live masterclass