-
Notifications
You must be signed in to change notification settings - Fork 13
Step 3 populating data
Purpose: show different ways to add data to your models when developing applications. This section covers play's integrated db manager, working with crud module and loading data using fixtures.
Note: you can get the sources of this step with the following commands
cd ~/devel/apps
git clone git://github.com/opensas/play-demo.git
cd play-demo
git checkout origin/03-populating_data
Open up another browser and navigate to http://localhost:9000/@db.
Enter jdbc:h2:mem:play for URL JDBC, sa for user name and leave the password empty.
You can execute sql statements to query and update the data in the in-memory H2 database. Enter the following commands to create a couple of events:
insert into eventtype( name ) values ( 'presentation' );
insert into eventtype( name ) values ( 'workshop' );
select * from eventtype;
insert into event( name, type_id, place, date ) values ( 'first event', 1, 'first event''s place', '2011-08-24 10:30:00' );
insert into event( name, type_id, place, date ) values ( 'scond event', 2, 'second event''s place', '2011-08-25 14:30:00' );
select * from event;
then hit ctrl-enter to execute
now go back to localhost:9000, hit refresh and you'll see the two events
Edit the cond/dependencies.yml file
# Application dependencies
require:
- play -> crud
then stop the application, and from the command line type
~/devel/apps/play-demo$ play deps
~ _ _
~ _ __ | | __ _ _ _| |
~ | '_ \| |/ _' | || |_|
~ | __/|_|\____|\__ (_)
~ |_| |__/
~
~ play! 1.2.3, http://www.playframework.org
~
~ Resolving dependencies using /home/sas/Dropbox/Public/devel/play/apps/play-demo/conf/dependencies.yml,
~
~
~ Installing resolved dependencies,
~
~ modules/crud -> /home/sas/devel/opt/play-1.2.3/modules/crud
~
~ Done!
run play eclipsify again in order to include the new module in the eclipse project
Pay attention to play's warning: However, it's often better to delete and re-import the project into your workspace since eclipse keeps dirty caches...
And now we'll create CRUD's controllers. By convention, CRUD's controllers will be named just like the models it relates to, with an "s".
app/controllers/Events.java
package controllers;
import play.mvc.*;
public class Events extends CRUD {
}
app/controllers/EventTypes.java
package controllers;
import play.mvc.*;
public class EventTypes extends CRUD {
}
And now we tell play how to map our requests to the crud module
conf/routes
# Routes
# This file defines all application routes (Higher priority routes first)
# ~~~~
# Home page
GET / Application.list
GET /events Application.list
* /admin module:crud
Just point your browser to localhost:9000 and you should see the crud module in action.
Now go ahead and create presentation and workshop event types.
Implement method toString in models/EventTypes so that we can see event's description on browse mode.
models/EventType.java
@Entity
public class EventType extends Model {
public String name;
@Override
public String toString() {
return name;
}
}
Do the same with the Event model.
We can specify required fields in the model, and the crud module will automatically enforce those constraints.
So edit the models like this
models/EventType.java
@Entity
public class EventType extends Model {
@Required(message="You have to complete the event type's name.")
public String name;
@Override
public String toString() {
return name;
}
}
models/Event.java
@Entity
public class Event extends Model {
@Required(message="You have to complete the event's name.")
public String name;
@Required(message="You have to select the type of the event.")
@ManyToOne
public EventType type;
@Required(message="You have to complete the event's place.")
public String place;
@Required(message="You have to complete the event's date.")
public Date date;
@Override
public String toString() {
return name;
}
}
Also, you can specify which format date to use, and crud module will see that only correct dates are entered, according to the format specified.
conf/application.conf
[...]
# Date format
# ~~~~~
date.format=MM-dd-yyyy
# date.format.fr=dd/MM/yyyy
[...]
Fixtures provides an easy way to yout entities with a predefined set of data. This is very useful for testing purposes.
So create the following fixture file in conf/data.yml
conf/data.yml
EventType(presentation):
name: presentation
EventType(workshop):
name: workshop
Event(first):
name: Drools and jBPM5
type: presentation
place: 64 rue Taitbout, PARIS
date: 06-17-2011 9:00:00
Event(second):
name: Search Engines
type: presentation
place: One Brattle Square, Cambridge
date: 06-23-2011 18:30:00
Event(Third):
name: Scale the Everest with Scala
type: presentation
place: One Brattle Square, Cambridge
date: 04-08-2011 20:00:00
Event(Fourth):
name: Play! framework, a java web framework for non-purists
type: workshop
place: 64 rue Taitbout, PARIS
date: 08-25-2012 20:00:00
Now we'll create a job that will be executed everytime our application starts up, and it will populate our database with the info from the fixture file.
So create a Bootstrap job in a lib.jobs package:
lib/jobs
package lib.jobs;
import play.jobs.Job;
import play.jobs.OnApplicationStart;
import play.test.Fixtures;
@OnApplicationStart
public class BootstrapJob extends Job {
@Override
public void doJob() {
Fixtures.deleteAllModels();
Fixtures.loadModels("data.yml");
}
}
Notice the @OnApplicationStart annotation, it tells play to execute this job on start up.
Besides being executed on startup, we'll add a link to force the job to repopulate data. This link will become very handy while we are developing the app.
So create an action in controllers/Application.java
controllers/Application.java
package controllers;
import java.util.List;
import lib.jobs.BootstrapJob;
import models.Event;
import play.mvc.Controller;
public class Application extends Controller {
public static void list() {
List<Event> events = Event.find("order by date desc").fetch();
render(events);
}
public static void loadFromYamlFile() {
new BootstrapJob().doJob();
list();
}
}
The last call to the list() method issues a redirect. Play automatically does this to enforce the redirect after post pattern.
And then we will add the link to this action in the template
views/Application/list.html
#{a @loadFromYamlFile()}load data from yaml file#{/a}
Now you can move on to Step 4 - styling