[forge-dev] Auto instantiate properties of custom type
Richard Kennard
richard at kennardconsulting.com
Wed Nov 9 02:48:48 EST 2011
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 at gmail.com <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto:forge-dev at lists.jboss.org>
> >>>> https://lists.jboss.org/mailman/listinfo/forge-dev
> >>> _______________________________________________
> >>> forge-dev mailing list
> >>> forge-dev at lists.jboss.org <mailto:forge-dev at lists.jboss.org>
> >>> https://lists.jboss.org/mailman/listinfo/forge-dev
> >>>
> >>>
> >> _______________________________________________
> >> forge-dev mailing list
> >> forge-dev at lists.jboss.org <mailto:forge-dev at lists.jboss.org>
> >> https://lists.jboss.org/mailman/listinfo/forge-dev
> > _______________________________________________
> > forge-dev mailing list
> > forge-dev at lists.jboss.org <mailto:forge-dev at lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/forge-dev
> >
> >
>
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org <mailto: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 <http://keyserver.net>, pgp.mit.edu <http://pgp.mit.edu>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org <mailto: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"
>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
More information about the forge-dev
mailing list