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

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

If Seam Faces or PrettyFaces is being used then their view action ability would be used. If vanilla JSF is being used, then we need to figure out the best way to make this happen, which it looks like isn't all that easy :( The idea is in the method would set a new instance of Address on the class so it's instantiated when the user goes to fill it out. Of course if things aren't filled out then you'd have an empty address instance persisted, could be good or bad, that really depends on the app. I know that's a fairly simplistic explanation, but it is the high level idea. Did it come across clearly? On Tue, Nov 8, 2011 at 22:27, Richard Kennard < richard(a)kennardconsulting.com&gt; wrote: > Jason, > > Okay agreed. Could you explain how you would see the 'view action' > approach working? > > Richard. > > On 9/11/2011 4:24 PM, Jason Porter wrote: > > 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 > > > > > > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/forge-dev > -- Jason Porter http://lightguard-jp.blogspot.com http://twitter.com/lightguardjp Software Engineer Open Source Advocate Author of Seam Catch - Next Generation Java Exception Handling PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev

Sorry, bad example. I meant more like: #{customerBean.customer.address} So originally the Forge scaffolding did this: public class CustomerBean ... private Customer customer = new Customer(); ... } So at construction time, basically. This pattern would need extending: public class CustomerBean extends PersistenceUtil implements MenuItem { ... private Customer customer; ... public CustomerBean() { customer = new Customer(); customer.setAddress( new Address() ); } ... } On 9/11/2011 6:02 PM, Lincoln Baxter, III wrote: > It looks like, from this thread, the view layer is accessing an entity directly via "#{customer}" - this is not a good practice in general, however, if > it is to be done, then what needs to happen, I think, is that "Customer" be initialized in whatever method is producing it. > > I've copied Steve Ebersole because he is probably the best person to answer this question (I hope this is OK Steve. We want to get this stuff right in > Forge.) > > E.g: > > @Produces > @Named("customer") > public Customer getCustomer() > { > if(customer == null) > { > customer = new Customer(); > customer.setAddress(new Address()); > } > } > > Is this on the same page? I don't think doing this in the Entity itself is correct. Thoughts? > ~Lincoln > > On Wed, Nov 9, 2011 at 7:23 AM, Jason Porter <lightguard.jp(a)gmail.com&lt;mailto: lightguard.jp(a)gmail.com&gt;&gt; wrote: > > If Seam Faces or PrettyFaces is being used then their view action ability would be used. If vanilla JSF is being used, then we need to figure out the > best way to make this happen, which it looks like isn't all that easy :( > > The idea is in the method would set a new instance of Address on the class so it's instantiated when the user goes to fill it out. Of course if > things aren't filled out then you'd have an empty address instance persisted, could be good or bad, that really depends on the app. > > I know that's a fairly simplistic explanation, but it is the high level idea. Did it come across clearly? > > > On Tue, Nov 8, 2011 at 22:27, Richard Kennard < richard(a)kennardconsulting.com <mailto:richard@kennardconsulting.com>> wrote: > > Jason, > > Okay agreed. Could you explain how you would see the 'view action' approach working? > > Richard. > > On 9/11/2011 4:24 PM, Jason Porter wrote: > > 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 <mailto:richard@kennardconsulting.com>> 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 <mailto:richard@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 <mailto:forge-dev@lists.jboss.org > > >>>> https://lists.jboss.org/mailman/listinfo/forge-dev > >>> _______________________________________________ > >>> forge-dev mailing list > >>> forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> > >>> https://lists.jboss.org/mailman/listinfo/forge-dev > >>> > >>> > >> _______________________________________________ > >> forge-dev mailing list > >> forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> > >> https://lists.jboss.org/mailman/listinfo/forge-dev > > _______________________________________________ > > forge-dev mailing list > > forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> > > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > -- > Jason Porter > http://lightguard-jp.blogspot.com > http://twitter.com/lightguardjp > > Software Engineer > Open Source Advocate > Author of Seam Catch - Next Generation Java Exception Handling > > PGP key id: 926CCFF5 > PGP key available at: keyserver.net <http://keyserver.net>;, pgp.mit.edu <http://pgp.mit.edu> > > _______________________________________________ > forge-dev mailing list > forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/forge-dev > > > > > -- > Lincoln Baxter, III > http://ocpsoft.com > http://scrumshark.com > "Keep it Simple" > > > _______________________________________________ > 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