public setter for id field - necessary?

[metronical]

Hi

Why is it necessary to have public setters for id properties on entities? I've noticed that if I override an id property in my java source then the ROO shell warns me that I am missing a setID() method but all seems to work OK.

Just curious really, is there somepart of the framework that need public mutators for id and version?

Jon

[Stefan Schmidt]

Jon,

This is indeed a little annoying as it breaks with the concept of immutability for ids and version fields. However, since the entities are also used as form backing objects the mutators for these fields are needed to convert data submitted through forms (PUT) back into a session attached entity. We are looking into alternatives.

-Stefan

[metronical]

I guess something using aspectj inter-type declarations to expose additional setters/getters only in the web tier might an idea. Thoug, I am a novice with Aspectj so don't really know what can be done.

Jon

[duckbill]

Jon,

This is indeed a little annoying as it breaks with the concept of immutability for ids and version fields. However, since the entities are also used as form backing objects the mutators for these fields are needed to convert data submitted through forms (PUT) back into a session attached entity. We are looking into alternatives.

-Stefan

DataBinder.initDirectFieldAccess()?

--
Jukka

[metronical]

I think that with a RAD framework like ROO, then you are kind of accepting that there is going to be a bit of a compromise to be made between a rich and fully encapsulated domain model and one that offers the convenience of being able to use the domain entity directly in the view without the need for DTOs. Though allowing direct field access would allow fields such as id and version to be private, we would also have to be careful to specifiy those fields that we want to allow binding to take place on; otherwise, we would be making the assumption that all fields are fair-game for binding in the view and this isn't going to be the case. At least with the property access approach you only expose getters/setters for those fields that you intend to be used in this way.

It would be better, I think, to stick with the property accessor but perhaps only expose this view of the domain object to the Data Binder somehow.

[duckbill]

we would also have to be careful to specifiy those fields that we want to allow binding to take place on

DataBinder.initDirectFieldAccess();
DataBinder.setAllowedFields(new String[] {"id", "version", ...})

This is probably something Roo could manage.

Personally, I'm not too worried about exposing the id and version setters.

[metronical]

Personally, I'm not too worried about exposing the id and version setters.

Sure, its hardly priority number one on the todo list but worth having at somepoint.

Jon