toString() usage

[carlos.l.sanchez]

toString() seems to be used to identify objects in some views / cases, but not in all of them.

How are objects identified on the different views, and can this identification be done in as consistent a way as possible? For example using toString() systematically.

[Stefan Schmidt]

Carlos, when you refer to views you mean Spring MVC views (not GWT, Flex or Vaadin) right?

In MVC scaffolding the toString() method should not be used for any object identification or view rendering. Instead, Roo creates a ApplicationConversionServiceFactoryBean in your project which is responsible for all view rendering of domain types in drop down boxes for example.

Hope this clarifies things.

Stefan

[carlos.l.sanchez]

Stefan,

Yes, I mean Spring MVC views. Although per another thread I am willing to use whatever views are the most functional / stable at the moment. (I have never been able to use the GWT views so far, in any Roo version.)

And thanks for clarifying how MVC-scaffolded objects are identified / rendered.

Now what's the best practice to customize the ApplicationConversionServiceFactoryBean? For example, are any manual changes overridden in subsequent Roo re-generations?

[Stefan Schmidt]

Carlos, you should never make any changes to Roo managed ITDs (aspects) because Roo will simply replace them next time you start the Roo shell on your project. However, any code pushed in to the related java sources can be customized. Roo will not make any changes to code in your java sources.

There is currently an open bug for push-in refactoring of ApplicationConversionServiceFactoryBean unfortunately, we will be fixing this for the next release.

Can you be more specific about what does not work for you in the GWT scaffolding? If there are problems you should open a Jira ticket for that. Note, there is also an external add-on that offers Vaadin scaffolding.

[carlos.l.sanchez]

Thanks Stefan,

---------------------

As far as I can tell ApplicationConversionServiceFactoryBean is a .java, not an .aj / ITD. But in any case your main point may be that it is not intended to be manually modified.

And even though its implementation as a simple, default "super" override of FormattingConversionServiceFactoryBean seems specifically designed for manual customization ;-)

But I guess this is not fully implemented yet, and until it is (in the next release, then) we are "stuck" with the out-of-the-box identification / rendering of the MVC-scaffolded objects?

---------------------

And understood, I will create a Jira ticket for my GWT scaffolding issue.

Is the Vaadin scaffolding the most stable / functional at the moment?

[Stefan Schmidt]

Carlos,

I would say that the MVC scaffolding is currently the most mature given it has been around since the first release of Roo and we have constantly been improving it since.

The ApplicationConversionServiceFactoryBean is indeed a java source but the ApplicationConversionServiceFactoryBean_Roo_Conver sionService.aj is the ITD I am referring to. So that would need push-in.

[carlos.l.sanchez]

Stefan,

I see the ApplicationConversionServiceFactoryBean_Roo_Conver sionService.aj, thanks.

And so like for the domain objects, is it fine to redefine / override methods in its .java counterpart? Not sure I am clear on that part still.

[Stefan Schmidt]

Hi Carlos, yes all code in .java sources will not be changed by Roo (unless you tell it to via a command). This is a general convention we follow and is documented in our reference guide http://static.springsource.org/sprin...gle/index.html.

[carlos.l.sanchez]

Stefan,

So if I understand correctly in the end, it is in fact fine to override ApplicationConversionServiceFactoryBean_Roo_Conver sionService.aj's implementations in its .java counterpart to redefine how the MVC-scaffolded objects are identified / rendered.

Part of my confusion as to whether this was fine or not was your remark that

"There is currently an open bug for push-in refactoring of ApplicationConversionServiceFactoryBean unfortunately, we will be fixing this for the next release."

Is that bug only relevant when having Roo automatically push everything into the .java files, i.e. when getting rid of Roo? Which we don't intend to do!

[carlos.l.sanchez]

Even if

"it is in fact fine to override ApplicationConversionServiceFactoryBean_Roo_Conver sionService.aj's implementations in its .java counterpart to redefine how the MVC-scaffolded objects are identified / rendered"

(and I would still appreciate the "blessing"), a better way may be to:

* Be able to mark / annotate functional fields (versus system id's) as such, and

* Have ApplicationConversionServiceFactoryBean's Converters use those functional fields by default, versus all of them.

(Which may rarely be appropriate.)