... | @@ -36,7 +36,7 @@ The [JButler Base Project](https://gitlab.labes.inf.ufes.br/labes/jbutler-base-p |
... | @@ -36,7 +36,7 @@ The [JButler Base Project](https://gitlab.labes.inf.ufes.br/labes/jbutler-base-p |
|
|
|
|
|
6. Once WildFly is running, go back to the `jbutler-base-project` folder and copy the application package `target/jbutler-base-project.war` to the `$WILDFLY_HOME/standalone/deployments` folder. WildFly should start deploying. If everything goes well, you should see this message: `Deployed "jbutler-base-project.war"`;
|
|
6. Once WildFly is running, go back to the `jbutler-base-project` folder and copy the application package `target/jbutler-base-project.war` to the `$WILDFLY_HOME/standalone/deployments` folder. WildFly should start deploying. If everything goes well, you should see this message: `Deployed "jbutler-base-project.war"`;
|
|
|
|
|
|
7. Open http://localhost:8080/jbutler-base-project in your browser and try some of the features;
|
|
7. Open http://localhost:8080/jbutler-base-project in your browser and try some of the features. Check out the different types of CRUD front-ends, we will use one of them in this tutorial;
|
|
|
|
|
|
8. When you want to undeploy the application, go to the `$WILDFLY_HOME/standalone/deployments` folder and rename the `jbutler-base-project.war.deployed` file to `jbutler-base-project.war.undeploy`. You can then delete the `jbutler-base-project.*` files from that folder and stop WildFly by pressing Ctrl+C in the terminal in which it's open.
|
|
8. When you want to undeploy the application, go to the `$WILDFLY_HOME/standalone/deployments` folder and rename the `jbutler-base-project.war.deployed` file to `jbutler-base-project.war.undeploy`. You can then delete the `jbutler-base-project.*` files from that folder and stop WildFly by pressing Ctrl+C in the terminal in which it's open.
|
|
|
|
|
... | @@ -429,7 +429,7 @@ If you want, change `text.developedBy` and add your name, as you are developing |
... | @@ -429,7 +429,7 @@ If you want, change `text.developedBy` and add your name, as you are developing |
|
|
|
|
|
## Set up AdminFaces, a ready-to-use front-end
|
|
## Set up AdminFaces, a ready-to-use front-end
|
|
|
|
|
|
When we don't have front-end designers working on our teams, we can use some generic ones, such as [AdminFaces](https://github.com/adminfaces), which is based on [AdminLTE](https://almsaeedstudio.com/themes/AdminLTE/index2.html) and [Bootstrap](http://getbootstrap.com/), but for JSF.
|
|
When we don't have front-end designers working on our teams, we can use some generic front-ends, such as [AdminFaces](https://github.com/adminfaces), which is based on [AdminLTE](https://almsaeedstudio.com/themes/AdminLTE/index2.html) and [Bootstrap](http://getbootstrap.com/), but for JSF.
|
|
|
|
|
|
A dependency for `admin-template` was already included in our `pom.xml`, so to set up AdminFaces, create its configuration file `src/main/resources/admin-config.properties` with the following contents:
|
|
A dependency for `admin-template` was already included in our `pom.xml`, so to set up AdminFaces, create its configuration file `src/main/resources/admin-config.properties` with the following contents:
|
|
|
|
|
... | @@ -607,14 +607,14 @@ $ ln -s `pwd`/target/oldenburg/ $WILDFLY_DEPLOY/oldenburg.war |
... | @@ -607,14 +607,14 @@ $ ln -s `pwd`/target/oldenburg/ $WILDFLY_DEPLOY/oldenburg.war |
|
$ touch $WILDFLY_DEPLOY/oldenburg.war.dodeploy
|
|
$ touch $WILDFLY_DEPLOY/oldenburg.war.dodeploy
|
|
```
|
|
```
|
|
|
|
|
|
Before `mvn package` produces `target/oldenburg.war`, it assembles it in a folder called `target/oldenburg`, so the above commands create a link to this folder in WildFly's deployments folder. When a folder is detected, WildFly doesn't automatically deploy it, so you need to create the `oldenburg.war.dodeploy` file there as well.
|
|
Before `mvn package` produces `target/oldenburg.war`, it assembles it in a folder called `target/oldenburg`, so the above commands create a link to this folder in WildFly's deployments folder. When a folder is detected, WildFly doesn't automatically deploy it, so you need to create the `oldenburg.war.dodeploy` file there as well:
|
|
|
|
|
|
The advantage in this case is that you can change something under `src/main/webapp` (in a web page, CSS, script, etc.) and update it on the server only with `mvn package` (no need to redeploy). If you change something under `src/main/java` or `src/main/resources`, though, you need to redeploy:
|
|
|
|
|
|
|
|
```sh
|
|
```sh
|
|
$ mv $WILDFLY_DEPLOY/oldenburg.war.deployed $WILDFLY_DEPLOY/oldenburg.war.dodeploy
|
|
$ mv $WILDFLY_DEPLOY/oldenburg.war.deployed $WILDFLY_DEPLOY/oldenburg.war.dodeploy
|
|
```
|
|
```
|
|
|
|
|
|
|
|
The advantage in this case is that you can change something under `src/main/webapp` (in a web page, CSS, script, etc.) and update it on the server only with `mvn package` (no need to redeploy). If you change something under `src/main/java` or `src/main/resources`, though, you need to redeploy.
|
|
|
|
|
|
Finally, to undeploy and remove Oldenburg from the server:
|
|
Finally, to undeploy and remove Oldenburg from the server:
|
|
|
|
|
|
```sh
|
|
```sh
|
... | @@ -706,6 +706,11 @@ public class Workshop extends PersistentObjectSupport implements Comparable<Work |
... | @@ -706,6 +706,11 @@ public class Workshop extends PersistentObjectSupport implements Comparable<Work |
|
public int compareTo(Workshop o) {
|
|
public int compareTo(Workshop o) {
|
|
return year - o.year;
|
|
return year - o.year;
|
|
}
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
public String toString() {
|
|
|
|
return acronym;
|
|
|
|
}
|
|
}
|
|
}
|
|
```
|
|
```
|
|
|
|
|
... | @@ -775,13 +780,13 @@ For all this to work, we need to configure JPA by creating the file `src/main/re |
... | @@ -775,13 +780,13 @@ For all this to work, we need to configure JPA by creating the file `src/main/re |
|
</persistence>
|
|
</persistence>
|
|
```
|
|
```
|
|
|
|
|
|
Finally, we also need to create the `oldenburg` schema in MySQL and give the `labes` user "full" privileges on it, just like before with the `mysystem` schema for the [JButler Base Project](https://gitlab.labes.inf.ufes.br/labes/jbutler-base-project) deployment.
|
|
Finally, we also need to create the `oldenburg` schema in MySQL and give the `labes` user "full" privileges on it, just like before with the `mysystem` schema for the [JButler Base Project](https://gitlab.labes.inf.ufes.br/labes/jbutler-base-project) deployment. No need to create the tables, as the JPA implementation (Hibernate), as specified in the above configuration, will do it for us.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Implement the CRUD (application, controller and view)
|
|
## Implement the CRUD (application, controller and view)
|
|
|
|
|
|
Finally, let's implement the CRUD, which will require a service class in the `application` package (which JButler implements as stateless EJBs, just like DAOs), a controller class in the `control` package, a new Web page and a link to that Web page in the template.
|
|
Finally, let's implement the CRUD, which will require a service class in the `application` package (which JButler implements as stateless EJBs, just like DAOs), a controller class in the `controller` package, a new Web page and a link to that Web page in the template.
|
|
|
|
|
|
Starting with the service, create the EJB interface `br.ufes.inf.labes.oldenburg.core.application.ManageWorkshopsService`:
|
|
Starting with the service, create the EJB interface `br.ufes.inf.labes.oldenburg.core.application.ManageWorkshopsService`:
|
|
|
|
|
... | @@ -826,10 +831,10 @@ public class ManageWorkshopsServiceBean extends CrudServiceImpl<Workshop> |
... | @@ -826,10 +831,10 @@ public class ManageWorkshopsServiceBean extends CrudServiceImpl<Workshop> |
|
|
|
|
|
Similar to the DAO, if our CRUD is very simple and requires nothing different than what JButler already provides, the EJB interface is empty and the implementation only needs to provide the DAO that gets injected (just like the `EntityManager` in the DAO). JButler does the rest, providing CRUD operations and support for validation of business logic (out of scope of this simple tutorial, see [JButler CRUD Validation](tutorials/JButler-CRUD-Validation)).
|
|
Similar to the DAO, if our CRUD is very simple and requires nothing different than what JButler already provides, the EJB interface is empty and the implementation only needs to provide the DAO that gets injected (just like the `EntityManager` in the DAO). JButler does the rest, providing CRUD operations and support for validation of business logic (out of scope of this simple tutorial, see [JButler CRUD Validation](tutorials/JButler-CRUD-Validation)).
|
|
|
|
|
|
Next, create the controller class `br.ufes.inf.labes.oldenburg.core.control.ManageWorkshopsController`:
|
|
Next, create the controller class `br.ufes.inf.labes.oldenburg.core.controller.ManageWorkshopsController`:
|
|
|
|
|
|
```java
|
|
```java
|
|
package br.ufes.inf.labes.oldenburg.core.control;
|
|
package br.ufes.inf.labes.oldenburg.core.controller;
|
|
|
|
|
|
import br.ufes.inf.labes.jbutler.ejb.application.CrudService;
|
|
import br.ufes.inf.labes.jbutler.ejb.application.CrudService;
|
|
import br.ufes.inf.labes.jbutler.ejb.controller.CrudController;
|
|
import br.ufes.inf.labes.jbutler.ejb.controller.CrudController;
|
... | @@ -1002,7 +1007,7 @@ The [JButler Base Project](https://gitlab.labes.inf.ufes.br/labes/jbutler-base-p |
... | @@ -1002,7 +1007,7 @@ The [JButler Base Project](https://gitlab.labes.inf.ufes.br/labes/jbutler-base-p |
|
</ui:composition>
|
|
</ui:composition>
|
|
```
|
|
```
|
|
|
|
|
|
## TODO -- Explain the code below, test CRUD, fix bugs
|
|
## TODO -- Write missing explanations
|
|
|
|
|
|
`src/main/resources/br/ufes/inf/labes/oldenburg/core/view/messages.properties`
|
|
`src/main/resources/br/ufes/inf/labes/oldenburg/core/view/messages.properties`
|
|
|
|
|
... | | ... | |