[forge-dev] Auto instantiate properties of custom type

Lincoln Baxter, III lincolnbaxter at gmail.com
Wed Nov 9 02:02:43 EST 2011 

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


-- 
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20111109/4c3f81ad/attachment.html

More information about the forge-dev mailing list