[forge-dev] Auto instantiate properties of custom type
Lincoln Baxter, III
lincolnbaxter at gmail.com
Wed Nov 9 03:05:37 EST 2011
Ok, I still would like Steve's input on this one.
How should we do this?
~Lincoln
On Wed, Nov 9, 2011 at 8:48 AM, Richard Kennard <
richard at kennardconsulting.com> wrote:
> 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
>
> _______________________________________________
> 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/4652bbea/attachment-0001.html
More information about the forge-dev
mailing list