Re: getter/setter facade

[Adam Heath <do...@brainfood.com>]

Marc Morin wrote:
> Now it's pretty obvious that many are reading the incorrectly renamed O->R mapping subject and saying it's counter to OFBiz entity model, core philosophy, discussed before... go away you Object lovin' Java developer... ;-)
> 
> I don't want to repeat the topic, but it is a getter/setter decorator around the Entity/Delegator API that you all love.  Not hibernate, not OO persistence...
> 
> I don't know how anyone can say that the following code is "nicer", "safer", easier to maintain
> 
>     GenericValue order = delegator.findOne("OrderHeader", UtilMisc.toList("orderId", orderId), true);
>     Timestamp entryDate = order.getTimestamp("entryDate");
>     List<GenericValue> orderItems = order.getRelated("OrderItem");
> 
> vs (evil Object facade, what a Java developer would expect to see, IDE auto-completion, type safety)
> 
>     OrderHeader order = OrderHeader.findOne(delegator,orderId);
>     Timestamp entryDate = order.getEntryDate();
>     List<OrderItem> orderItems = order.getOrderItemList();

Only one suggestion on the api.  getOrderItemList should not have a
list suffix on the method.  The type return is defined by the entity
definition(in this case, 'many').  Plus, once removing the list
suffix, OrderItem could conflict by name with a field named the same.
 So, in such cases, remove the get prefix.  order.OrderItem().

Have you extended the base-line non-typed get() method to support
relation fetching?  So, in groovy, I could do order.entryDate(which is
possible now), or order.OrderItem(because the first char is capital,
it would do a relation fetch).

As for those of us that have been resisting, I don't want to be one of
those.  Ofbiz is for a community, and if people want this, then we
shouldn't really say no.  I have moved back and forth several times
over the years about this.

The interface wouldn't be hard to write.  At build type, something
similar to javacc/jjtree would be run, that would auto-generate a java
class, based on any entity.

Er, oops, I just found a problem with your idea.  How do you handle
<extend-entity>?

Re: getter/setter facade

[Marc Morin <ma...@emforium.com>]

> Have you extended the base-line non-typed get() method to support
> relation fetching? So, in groovy, I could do order.entryDate(which is
> possible now), or order.OrderItem(because the first char is capital,
> it would do a relation fetch).
> 

So we haven't but that is something that should be done in GenericValue.get(fieldName). Good idea.