This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

Teaching tricks to Roo

Jul 8th, 2010, 08:45 PM

Hello,

I wonder how can i do in -Roo terms- the following: My use case requires a custom entity non-numeric -String type-Id field that should be entered through the UI.

I have no problem enabling the custom id as needed. However Roo automatically removes the the field -because is an Id, I guess- from UI code generation. Consequently it is not available in the jspx forms. i.e create and such.

Can't you just give the field a Java name other than "id", for example "personId" or "pizzaId"? You can always change the field label to "Id" in the UI by editing src\main\webapp\WEB-INF\i18n\application.properties.

Comment

If I understand correctly, you want the "username" column of the "users" table (i.e. the primary key) to be editable via the UI? That would be a highly unusual database design; hopefully you're at liberty to change it.

Normally primary keys are generated by the database and not editable by (or visible to) the user. A better design would be:

However, It would be great having Roo able to create entities replicating exactly such kind of tables. I am sure there are tons of legacy db out there as this one.
What you think?

Now you're talking about reverse-engineering JPA entities from an existing database, which is the subject of ROO-435. But regardless of whether you do that or write your entities by hand, or even whether you're using Roo or Spring, the @Id field of a JPA entity can never be editable via the UI; it just doesn't make sense. For example, if a user with username = "bob" (which is also his primary key) edits his username to "bob2", how would the JPA provider know that it should update the existing "bob" row instead of inserting a new row with a PK of "bob2"?

Comment

I pretty much agree with everything you previously posted but the part on "never make the @Id editable from the UI". Specially since, I am strong supporter of surrogate keys for web development. However, I am supporter of never-say-never as well.

Even though I could just end in a rhetorical development exercise.
I decided to move the ball a little further and complete the implementation of database model taken from spring security 3.1.0.; previously referred.
allowing the username field annotated with @Id and being editable from the UI.

RESULTS:
It was really easy to tweak the jspx forms:create, list, show, etc. for properly handing the @Id annotated field 'username' from the UI. Presentation sourcecode seemed ready for such thing.

Following, I am showing pieces of controller/entity code on making JPA to correctly decide when to insert vs. merge

Comment

1) I fully agree that a surrogate-key implementation is the correct one; as the one posted by Andrews before. In fact my actual implementation of the entity model posted in the security 3.1 reference manual is this way.

2)As mentioned before this experiment was only a rhetorical development exercise for understanding better the details of the awesome tagx library coming with Roo and its flexibility.

3) As a Developer I can tell you that it is doable -however not practically or recommended- on taking care on the foreign key as well.