ToolsTutorial03

Welcome to the FrameWeb Tools Tutorial. This is part 03 of the tutorial, so if you got here directly you might want to start from the beginning of the tutorial.

FrameWeb Tools Tutorial, Part 03: generating code

In this part of the tutorial, we will start from the FrameWeb models that represent a simple new feature for the Oldenburg system, namely: student registration, and generate code for it.

Configure Code Generation

To be able to generate code, we first need to configure a few paths. Under the Sirius perspective, with your FrameWeb project open (if it's not, expand Model.frameweb > Project and double-click on the main project model), select the FrameWeb Configuration, open the Properties view and set the following attributes:

• Class Extension: .java;
• FrameWork Definition Path: frameweb/jbutler/templates;
• Page Extension: .xhtml;
• Src Path: src/main/java;
• View Path: src/main/webapp.

The values above should be adjusted if your project is organized differently. For instance, the FrameWork Definition Path should poing to the templates directory you copied from the FrameWeb repository. Src Path and View Path above follow standard convention for Maven projects, pointing to where the Java classes and the Web pages should be generated, respectively.

Generate the Code

Once FrameWeb is properly configured, generating code is quite easy: right-click any blank space in the FrameWeb editor and select Generate Source Code.

Switch to the Java EE perspective and check in the Project Explorer that code has been generated under Java Resources/src/main/java --- Java classes in packages br.ufes.informatica.oldenburg.core.application / controller / domain / persistence) --- and Deployed Resources/webapp. If any artifact you expected to be generated is not showing in the Project Explorer, right-click your project and select Refresh.

The code generator produces code that might not be well formatted and might be missing some imports. Right after code generation, I suggest you right-click the src/main/java folder unde Java Resources and select Source > Organize Imports. Then, right-click it again and select Source > Format. Since Eclipse fixes this quite efficiently, it doesn't make much sense to overcomplicate the code generation templates in order to fix this ourselves.

Unfortunately, the current version of the code generator (at the time of this writing) has a few issues (that are in our plans to fix), namely:

• It currently doesn't take into consideration pre-existing code, which means that if you generate code, edit it and then generate again, the second code generation will overwrite your edits;
• The naming conventions suggested by JButler's templates are due to the code generator not being able to properly read the structure of the UML models (e.g., it should read which interface a service class is implementing instead of guessing it through its name -- RegistrationServiceBean -> RegistrationService);
• The editor doesn't support generics, so methods that are supposed to receive as parameters or return a collection of some domain class (e.g., List<Author>) will be modeled as returning an un-typed collection (e.g., List) and, therefore, code will also be generated without the specific type of each collection.

In case of problems...

In case code has not been generated the way you expected, you could create a new issue in FrameWeb's issue tracker so we could try to fix it in the next version of the FrameWeb Tools. Please describe the issue (in English or Portuguese) as detailed as possible so we can try to reproduce it and then develop a fix, if applicable.

For some issues, however, you may be able to fix yourself by adjusting the respective template. In the next part of the tutorial, I'll try to explain the steps I took to adjust the Spring Boot templates produced by Lucas in order to create the JButler Java EE templates used in this tutorial.

Next: adding support for a new architecture