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@gmail.com> 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@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@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@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@lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>> _______________________________________________
>>> forge-dev mailing list
>>> forge-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>
>>>
>> _______________________________________________
>> forge-dev mailing list
>> forge-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/forge-dev
> _______________________________________________
> forge-dev mailing list
> forge-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>
>

_______________________________________________
forge-dev mailing list
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, pgp.mit.edu

_______________________________________________
forge-dev mailing list
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"