Spring Roo brings alternatives for setting up a project: a) Entering project using a script file or b) Creating the database first and reverse engineering it using Roo DBRE commands.
For this article I am using option a), via an script file. Option b) is specially convenient for projects with an database already in place. I’ll vist Roo DBRE in a coming article in the near future.
project --topLevelPackage org.pragmatikroo.roodocman
persistence setup --provider HIBERNATE --database MYSQL --databaseName roodocman --userName <username> --password <password>
entity --class ~.domain.Document
field string --fieldName name --notNull --sizeMax 30
field string --fieldName description --sizeMax 500
field string --fieldName filename --notNull
//field blob --fieldName content --notNull //Type not supported by Roo
field string --fieldName contentType --notNull
field numbert --fieldName size -
controller all --package ~.web
Notice content field is of type blob. This field would have to be entered manually into the entity class. You can use the IDE of your choice. I use STS. Either you use STS or the native Roo shell, the project would need to be synced by Roo after the change. More on this later.
Please review the seminal article for more information about the example entity fields. All highlighted code is manually added to the original file created by Roo. Why I added field size and url directly into the entity class?. I could have entered referred fields using the shell too. Right?. I did it in purpose to mentioned that Spring Roo is a round-trip tool. There are two more fields not shown in the entity class. They are the id and version fields, Roo automatically handle them using an ITD. Details about round-trip capabilities and how Roo uses ITDs, please visit Spring Roo website at http://www.springsource.org/roo. One more thing about the blob field. DBMS have different type of blobs. Verify that your project database is using the right one for your purposes.
As mention before: always make sure that Roo synced your latest changes. That would save you a lot of confusion.
It is a good time to deploy the application and verify that everything is working find to this point.
Required Source code changes
Well, to this point Spring Roo has done a lot for us. Properly setup the project. Created a Maven pom.xml with all required dependencies -well, almost; more on this below-. Generate all the code necessary for having a working web app. If this not enough, Roo is there in the background monitoring the project against any possible change.
With exception of the blob field -content- all the other fields are ready to go. Roo took care of them. In order to save/retrieve data from the blob field, we need to modify code in the client and in the server side for allowing file uploads.
Server Side Changes
Basically we need code that allows us to save/retrieve documents that include a blob field. The documents are entered using a web form. Typically Roo by default, generates client and server side code for having CRUD operations for every entity. I am not allowing updates in this version of the application. So, I disabled it, by setting the update=false in the @RooWebScaffold annotation. Please make sure next code is included in the DocumentController project file.
The code above allows CRUD operations with all the document fields including the blob. Very-very important: all this source code must be placed in the DocumentControler.java file to avoid been removed by Roo when the project is synced for changes.
Client Side Changes
On client side, I created a create custom form. Please replace the content of the create.jspx, with:
Well, the Reader has been exposed to two pretty close but at the same time different ways of implementing a particular web application project. Both are using the same high quality open source code Java-based development stack: Spring 3.X. I believe both ways are good and valid. There is a significant difference in Spring Roo approach though. Roo advocates for removing the “unnecessary abstractions” from web development. So, you won’t find Daos or Services classes in a typical Roo project. This is totally fine with me. However, it is a subject still in revision by the community at large. Not to mention that nothing stops you for implementing them if you need/want them. If you allow me one final point, I like better Roo approach because it gives me more time for thinking and figuring our how to solve the problem.