I think we've worked some of this out. (correct me if I'm wrong!)
The getDefinedInstance() functions on the homes will never be set unless the page is
called with an <s:link><f:param> corresponding to one of the 's in the
FooEdit.page.xml -- those params will in turn call through EL to the various home objects,
indirectly calling setId() which causes getDefinedInstance() to return a non-null object.
Presumably, this is intended as a way to instantiate a new object with non-null values for
these fields. (Gavin's post implies that its a way to pre-instantiate non-null
foreign key fields so that they are not null at persist time).
However, because wire() is called for both newly created and read-from-database (managed)
objects, setting those params can overwrite field values read from the db - (that
doesn't seem to be something one would want to do very often - perhaps its just a side
effect of the implementation not intended to every really be used).
Also, it's not clear why only xxx-to-one fields get this treatment - why not have
support for setting String, int, etc. fields too?
We have customized some of our Home class createInstance() functions to set various
default values for certain fields. It would be instructive to know when Seam developers
would instead advise initializing these variables in wire() instead?
NOTE to Seam developers: it would be very helpful if you could add an example in a future
seam release that uses and extends seam-gen generated EntityHomes and views as a way to
document how they are intended to be used (in addition to adding some Javadoc to the Home
and EntityHome classes :)). Currently, each of the examples uses a different approach to
DAO/Home interface, and none of the examples use these seamgen home beans, so it's
hard to see what the seamgen framework's intent is.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4076441#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...