Re: [forge-dev] Auto instantiate properties of custom type

It may boil down to which way we believe is the "correct" way. For all of the Forge plugins we've been trying to have then generated code use best practices. This helps lessen support as hopefully, the patterns will be repeated and they'll be done correctly with fewer bugs. This approach also helps to educate people, though we could certainly do a better job at that by documenting why Forge is generating code a certain way. I suggested my proposal as I view this as an interaction problem with the persistence model, not a problem with that model. Therefore, my solution kept the fix closer to the problem, or at least as I see it, it does :) However, I'm not tied to a particular solution and could be persuaded to others. I think some more discussion will provide a good approach. Sent from my iPhone On Nov 8, 2011, at 22:15, Richard Kennard <richard(a)kennardconsulting.com&gt; wrote: > I don't believe it will upset JPA, no. It *would* if you did: > > public Address getAddress() { > if ( this.address == null ) { this.address = new Address(); } > return address; > } > > Because JPA will call setAddress(null) and then getAddress() and get back a different result. But if the field is just initialised to a default value... > > private Address address = new Address(); > > ...then JPA will overwrite it with setAddress(null) and it'll be okay. > > But sure, if there is a nicer way to do it I don't mind doing it a different way? > > Richard. > > On 9/11/2011 4:11 PM, Jason Porter wrote: >> 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&gt; 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 >> _______________________________________________ >> forge-dev mailing list >> forge-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/forge-dev >> >> > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev