Ok, I still would like Steve's input on this one.<br><br>How should we do this?<br>~Lincoln<br><br><div class="gmail_quote">On Wed, Nov 9, 2011 at 8:48 AM, Richard Kennard <span dir="ltr"><<a href="mailto:richard@kennardconsulting.com">richard@kennardconsulting.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Sorry, bad example. I meant more like:<br>
<br>
#{customerBean.customer.address}<br>
<br>
So originally the Forge scaffolding did this:<br>
<br>
public class CustomerBean<br>
<br>
...<br>
private Customer customer = new Customer();<br>
...<br>
}<br>
<br>
So at construction time, basically. This pattern would need extending:<br>
<br>
public class CustomerBean extends PersistenceUtil implements MenuItem {<br>
<br>
...<br>
private Customer customer;<br>
...<br>
public CustomerBean() {<br>
customer = new Customer();<br>
customer.setAddress( new Address() );<br>
}<br>
...<br>
<div class="im"> }<br>
<br>
<br>
<br>
<br>
<br>
On 9/11/2011 6:02 PM, Lincoln Baxter, III wrote:<br>
> 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<br>
> it is to be done, then what needs to happen, I think, is that "Customer" be initialized in whatever method is producing it.<br>
><br>
> 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<br>
> Forge.)<br>
><br>
> E.g:<br>
><br>
> @Produces<br>
> @Named("customer")<br>
> public Customer getCustomer()<br>
> {<br>
> if(customer == null)<br>
> {<br>
> customer = new Customer();<br>
> customer.setAddress(new Address());<br>
> }<br>
> }<br>
><br>
> Is this on the same page? I don't think doing this in the Entity itself is correct. Thoughts?<br>
> ~Lincoln<br>
><br>
</div><div class="im">> On Wed, Nov 9, 2011 at 7:23 AM, Jason Porter <<a href="mailto:lightguard.jp@gmail.com">lightguard.jp@gmail.com</a> <mailto:<a href="mailto:lightguard.jp@gmail.com">lightguard.jp@gmail.com</a>>> wrote:<br>
><br>
> 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<br>
> best way to make this happen, which it looks like isn't all that easy :(<br>
><br>
> 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<br>
> 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.<br>
><br>
> I know that's a fairly simplistic explanation, but it is the high level idea. Did it come across clearly?<br>
><br>
><br>
</div><div class="im">> On Tue, Nov 8, 2011 at 22:27, Richard Kennard <<a href="mailto:richard@kennardconsulting.com">richard@kennardconsulting.com</a> <mailto:<a href="mailto:richard@kennardconsulting.com">richard@kennardconsulting.com</a>>> wrote:<br>
><br>
> Jason,<br>
><br>
> Okay agreed. Could you explain how you would see the 'view action' approach working?<br>
><br>
> Richard.<br>
><br>
> On 9/11/2011 4:24 PM, Jason Porter wrote:<br>
> > 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<br>
> best practices.<br>
> ><br>
> > This helps lessen support as hopefully, the patterns will be repeated and they'll be done correctly with fewer bugs. This approach also helps<br>
> to educate people, though we could certainly do a better job at that by documenting why Forge is generating code a certain way.<br>
> ><br>
> > I suggested my proposal as I view this as an interaction problem with the persistence model, not a problem with that model. Therefore, my<br>
> solution kept the fix closer to the problem, or at least as I see it, it does :)<br>
> ><br>
> > 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.<br>
> ><br>
> > Sent from my iPhone<br>
> ><br>
</div><div class="im">> > On Nov 8, 2011, at 22:15, Richard Kennard <<a href="mailto:richard@kennardconsulting.com">richard@kennardconsulting.com</a> <mailto:<a href="mailto:richard@kennardconsulting.com">richard@kennardconsulting.com</a>>> wrote:<br>
> ><br>
> >> I don't believe it will upset JPA, no. It *would* if you did:<br>
> >><br>
> >> public Address getAddress() {<br>
> >> if ( this.address == null ) { this.address = new Address(); }<br>
> >> return address;<br>
> >> }<br>
> >><br>
> >> Because JPA will call setAddress(null) and then getAddress() and get back a different result. But if the field is just initialised to a<br>
> default value...<br>
> >><br>
> >> private Address address = new Address();<br>
> >><br>
> >> ...then JPA will overwrite it with setAddress(null) and it'll be okay.<br>
> >><br>
> >> But sure, if there is a nicer way to do it I don't mind doing it a different way?<br>
> >><br>
> >> Richard.<br>
> >><br>
> >> On 9/11/2011 4:11 PM, Jason Porter wrote:<br>
> >>> 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)<br>
> is not what was set by JPA then extra db actions are performed.<br>
> >>><br>
> >>> 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<br>
> instead.<br>
> >>><br>
> >>> Sent from my iPhone<br>
> >>><br>
</div><div class="im">> >>> On Nov 8, 2011, at 21:37, Richard Kennard <<a href="mailto:richard@kennardconsulting.com">richard@kennardconsulting.com</a> <mailto:<a href="mailto:richard@kennardconsulting.com">richard@kennardconsulting.com</a>>> wrote:<br>
> >>><br>
> >>>> Hi guys,<br>
> >>>><br>
> >>>> As you're probably aware, in JSF if I do...<br>
> >>>><br>
> >>>> #{customer}<br>
> >>>><br>
> >>>> ...then a Customer object will get instantiated 'just in time'. But if I do...<br>
> >>>><br>
> >>>> #{customer.address.street}<br>
> >>>><br>
> >>>> ...then 'address' will *not* get instantiated just in time. So if you use Forge to do...<br>
> >>>><br>
> >>>> entity --named Customer<br>
> >>>> field custom --named address<br>
> >>>> [what custom type m'lord?] com.test.domain.Address<br>
> >>>><br>
> >>>> 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<br>
> good solution to<br>
> >>>> this, so can I suggest the simplest?<br>
> >>>><br>
> >>>> When Forge generates field/getter/setter for a custom type (possibly limited to the project's domain package), could it do:<br>
> >>>><br>
> >>>> @Column<br>
> >>>> private Address address *=new Address();*<br>
> >>>><br>
> >>>> public Address getAddress() {<br>
> >>>> return this.address;<br>
> >>>> }<br>
> >>>><br>
> >>>> public void setAddress(final Address address) {<br>
> >>>> this.address = address;<br>
> >>>> } }<br>
> >>>><br>
> >>>> _______________________________________________<br>
> >>>> forge-dev mailing list<br>
</div>> >>>> <a href="mailto:forge-dev@lists.jboss.org">forge-dev@lists.jboss.org</a> <mailto:<a href="mailto:forge-dev@lists.jboss.org">forge-dev@lists.jboss.org</a>><br>
<div class="im">> >>>> <a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br>
> >>> _______________________________________________<br>
> >>> forge-dev mailing list<br>
</div>> >>> <a href="mailto:forge-dev@lists.jboss.org">forge-dev@lists.jboss.org</a> <mailto:<a href="mailto:forge-dev@lists.jboss.org">forge-dev@lists.jboss.org</a>><br>
<div class="im">> >>> <a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br>
> >>><br>
> >>><br>
> >> _______________________________________________<br>
> >> forge-dev mailing list<br>
</div>> >> <a href="mailto:forge-dev@lists.jboss.org">forge-dev@lists.jboss.org</a> <mailto:<a href="mailto:forge-dev@lists.jboss.org">forge-dev@lists.jboss.org</a>><br>
<div class="im">> >> <a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br>
> > _______________________________________________<br>
> > forge-dev mailing list<br>
</div>> > <a href="mailto:forge-dev@lists.jboss.org">forge-dev@lists.jboss.org</a> <mailto:<a href="mailto:forge-dev@lists.jboss.org">forge-dev@lists.jboss.org</a>><br>
<div class="im">> > <a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br>
> ><br>
> ><br>
><br>
> _______________________________________________<br>
> forge-dev mailing list<br>
</div>> <a href="mailto:forge-dev@lists.jboss.org">forge-dev@lists.jboss.org</a> <mailto:<a href="mailto:forge-dev@lists.jboss.org">forge-dev@lists.jboss.org</a>><br>
<div class="im">> <a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br>
><br>
><br>
><br>
><br>
> --<br>
> Jason Porter<br>
> <a href="http://lightguard-jp.blogspot.com" target="_blank">http://lightguard-jp.blogspot.com</a><br>
> <a href="http://twitter.com/lightguardjp" target="_blank">http://twitter.com/lightguardjp</a><br>
><br>
> Software Engineer<br>
> Open Source Advocate<br>
> Author of Seam Catch - Next Generation Java Exception Handling<br>
><br>
> PGP key id: 926CCFF5<br>
</div>> PGP key available at: <a href="http://keyserver.net" target="_blank">keyserver.net</a> <<a href="http://keyserver.net" target="_blank">http://keyserver.net</a>>, <a href="http://pgp.mit.edu" target="_blank">pgp.mit.edu</a> <<a href="http://pgp.mit.edu" target="_blank">http://pgp.mit.edu</a>><br>
><br>
> _______________________________________________<br>
> forge-dev mailing list<br>
> <a href="mailto:forge-dev@lists.jboss.org">forge-dev@lists.jboss.org</a> <mailto:<a href="mailto:forge-dev@lists.jboss.org">forge-dev@lists.jboss.org</a>><br>
<div class="im">> <a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br>
><br>
><br>
><br>
><br>
> --<br>
> Lincoln Baxter, III<br>
> <a href="http://ocpsoft.com" target="_blank">http://ocpsoft.com</a><br>
> <a href="http://scrumshark.com" target="_blank">http://scrumshark.com</a><br>
> "Keep it Simple"<br>
><br>
><br>
</div><div><div></div><div class="h5">> _______________________________________________<br>
> forge-dev mailing list<br>
> <a href="mailto:forge-dev@lists.jboss.org">forge-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br>
<br>
_______________________________________________<br>
forge-dev mailing list<br>
<a href="mailto:forge-dev@lists.jboss.org">forge-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Lincoln Baxter, III<br><a href="http://ocpsoft.com">http://ocpsoft.com</a><br><a href="http://scrumshark.com">http://scrumshark.com</a><br>"Keep it Simple"<br>