Won't this cause issues with the JPA impl? From my conversations with the Hibernate
devs if what is returned from the property (getter/field) is not what was set by JPA then
extra db actions are performed.
IMO, this an integration point for the JSF or EL specs. I think, though, this is an
instantiation issue and should be done with a view action instead.
Sent from my iPhone
On Nov 8, 2011, at 21:37, Richard Kennard <richard(a)kennardconsulting.com> wrote:
Hi guys,
As you're probably aware, in JSF if I do...
#{customer}
...then a Customer object will get instantiated 'just in time'. But if I do...
#{customer.address.street}
...then 'address' will *not* get instantiated just in time. So if you use Forge
to do...
entity --named Customer
field custom --named address
[what custom type m'lord?] com.test.domain.Address
Then although you'll get a UI that includes a Customer with an embedded Address,
it'll fail as soon as you try to save. There isn't a very good solution to
this, so can I suggest the simplest?
When Forge generates field/getter/setter for a custom type (possibly limited to the
project's domain package), could it do:
@Column
private Address address *=new Address();*
public Address getAddress() {
return this.address;
}
public void setAddress(final Address address) {
this.address = address;
} }
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev