You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Marc Morin <ma...@emforium.com> on 2010/12/11 21:40:06 UTC
getter/setter facade (was: Re: O->R Mapping (Was: findByAnd(Map) ws
findList(EntityCondition)))
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();
My point is, there is a simple facade we can present on all the goodness of the GenericValue, delegator, dispatcher, transactions, that makes the Java purest feel better about OFBiz. (been easier to find Java developers than OFBiz ones...)
We have been using this exact decorator pattern in our OFBiz application for over 2 years, it feels natural when writing Java code (ie. when in Rome act like a Roman), haven't heard any developers say they don't want to use it in favor of the "String" way, once exposed to it and writing new code. When modifying existing code, they want to change all GenericValues to their appropriate object decorator. (we aren't doing this in app/framework so we can merge easier, but would love to do see it done/do it)
Well, looks like we'll continue on our own marry way on this one, keep our forked technology to ourselves.... I can feel the rope pushing that I mentioned previously. ;-)
Re: getter/setter facade (was: Re: O->R Mapping (Was: findByAnd(Map) ws findList(EntityCondition)))
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
Hi Marc,
On Dec 11, 2010, at 9:40 PM, 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();
>
> My point is, there is a simple facade we can present on all the goodness of the GenericValue, delegator, dispatcher, transactions, that makes the Java purest feel better about OFBiz. (been easier to find Java developers than OFBiz ones...)
I doubt that a good Java developer would have problems in learning the former.
Based on my experience, if developers are willing to learn and master OFBiz, they can get comfortable with some of the peculiarities of OFBiz in a few hours. And when they learn how to use the delegator API then, as an added value, they also understand how to deal with Minilang.
On the other hand, I know that there are development teams that tend to initially reject some of the tools used in OFBiz: this has something to do with a-critic conformism to commonly accepted practices or fashion, rather than real advantages.
Jacopo
>
> We have been using this exact decorator pattern in our OFBiz application for over 2 years, it feels natural when writing Java code (ie. when in Rome act like a Roman), haven't heard any developers say they don't want to use it in favor of the "String" way, once exposed to it and writing new code. When modifying existing code, they want to change all GenericValues to their appropriate object decorator. (we aren't doing this in app/framework so we can merge easier, but would love to do see it done/do it)
>
> Well, looks like we'll continue on our own marry way on this one, keep our forked technology to ourselves.... I can feel the rope pushing that I mentioned previously. ;-)
>
>
>
Re: getter/setter facade
Posted by 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.
Re: getter/setter facade
Posted by 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
Posted by Nicolas Malin <ma...@librenberry.net>.
Le 13/12/2010 08:56, Nicolas Malin a écrit :
> Le 12/12/2010 01:32, Adam Heath a écrit :
>> BJ Freeman wrote:
>>> most of the frame works are objects.
>>> so how would you implement your object in simple-methods
>>> like GenericValue?
>> These new classes are still GenericValue, while also being more
>> specific.
>>
>> class Party extends GenericValue {}
> This system already exist with neogia addons. If you install the
> persistance layer with ofbiz-generator addons you have a "simulation"
> ORM over entity engine. It's not a greate revolution, we use this only
> for big customer project.
>
> Nicolas
Just an example from neogia accounting components :
String transId = (String) context.get(AcctgTransaction.transId);
AcctgTransaction acctgTransaction =
AcctgTransactionServices.findByPrimaryKey(delegator, transId);
List<AcctgTransactionItem> listAcctgTransactionItems =
acctgTransaction.getAcctgTransactionItemsWC();
if
(AcctgTransactionStatus.FINALIZED.equals(acctgTransaction.getStatusId())) {
return
ServiceUtil.returnSuccess(UtilProperties.getMessage(resource,
"NaccountingAlreadyFinalized", locale));
}
We also extend delegator interface :
List<AcctgTransaction> transactions =
delegator.findNList(AcctgTransaction.ENTITY_NAME,
EntityExpr.makeCondition(UtilMisc.toMap(AcctgTransaction.statusId,
AcctgTransactionStatus.WIP)), null, null, null, false);
Nicolas
--
Nicolas MALIN
Consultant
Tél : 06.17.66.40.06
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : 02.48.02.56.12
Site : http://www.librenberry.net/
Re: getter/setter facade
Posted by Nicolas Malin <ma...@librenberry.net>.
Le 12/12/2010 01:32, Adam Heath a écrit :
> BJ Freeman wrote:
>
>> most of the frame works are objects.
>> so how would you implement your object in simple-methods
>> like GenericValue?
>>
> These new classes are still GenericValue, while also being more specific.
>
> class Party extends GenericValue {}
>
This system already exist with neogia addons. If you install the
persistance layer with ofbiz-generator addons you have a "simulation"
ORM over entity engine. It's not a greate revolution, we use this only
for big customer project.
Nicolas
--
Nicolas MALIN
Consultant
Tél : 06.17.66.40.06
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : 02.48.02.56.12
Site : http://www.librenberry.net/
Re: getter/setter facade
Posted by BJ Freeman <bj...@free-man.net>.
I have always wondered why they were used instead of simple methods
seem a lot less maintenance.
I have avoided classes.
=========================
BJ Freeman
Strategic Power Office with Supplier Automation <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
Specialtymarket.com <http://www.specialtymarket.com/>
Systems Integrator-- Glad to Assist
Chat Y! messenger: bjfr33man
Adam Heath sent the following on 12/11/2010 4:32 PM:
> BJ Freeman wrote:
>> most of the frame works are objects.
>> so how would you implement your object in simple-methods
>> like GenericValue?
>
> These new classes are still GenericValue, while also being more specific.
>
> class Party extends GenericValue {}
>
Re: getter/setter facade
Posted by Adam Heath <do...@brainfood.com>.
BJ Freeman wrote:
> most of the frame works are objects.
> so how would you implement your object in simple-methods
> like GenericValue?
These new classes are still GenericValue, while also being more specific.
class Party extends GenericValue {}
Re: getter/setter facade
Posted by BJ Freeman <bj...@free-man.net>.
most of the frame works are objects.
so how would you implement your object in simple-methods
like GenericValue?
=========================
BJ Freeman
Strategic Power Office with Supplier Automation <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
Specialtymarket.com <http://www.specialtymarket.com/>
Systems Integrator-- Glad to Assist
Chat Y! messenger: bjfr33man
Marc Morin sent the following on 12/11/2010 2:07 PM:
> Well the good old GenericValue is an object as well. ;-)
>
>
> Marc Morin
> Emforium Group Inc.
> ALL-IN Software
> 519-772-6824 ext 201
> mmorin@emforium.com
>
> ----- Original Message -----
>> when you use a Class it is an object.
>> getter and setter are methods by another name.
>> if you instantiate a class all the methods are carried with it whether
>> they are used or not.
>> so regardless of your argument it is OO.
>>
>> if you are familar with c then create a hello world function and
>> compile then create a class hello world. not the difference in size
>> and look at
>> the stack for a call to both.
>>
>> the last time I did this the function compiled to 1K the class compile
>> was 10K with no methods in the class.
>>
>> then put getter and setter in the hellow world and watch the size and
>> the stack when using the class.
>>
>> this will give you an idea of what is being talked about.
>>
>>
>>
>> =========================
>> BJ Freeman
>> Strategic Power Office with Supplier Automation
>> <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
>> Specialtymarket.com<http://www.specialtymarket.com/>
>> Systems Integrator-- Glad to Assist
>>
>> Chat Y! messenger: bjfr33man
>>
>> Marc Morin sent the following on 12/11/2010 12:40 PM:
>>
>>
>>> 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();
>>>
>>> My point is, there is a simple facade we can present on all the
>>> goodness of the GenericValue, delegator, dispatcher, transactions,
>>> that makes the Java purest feel better about OFBiz. (been easier to
>>> find Java developers than OFBiz ones...)
>>>
>>> We have been using this exact decorator pattern in our OFBiz
>>> application for over 2 years, it feels natural when writing Java
>>> code (ie. when in Rome act like a Roman), haven't heard any
>>> developers say they don't want to use it in favor of the "String"
>>> way, once exposed to it and writing new code. When modifying
>>> existing code, they want to change all GenericValues to their
>>> appropriate object decorator. (we aren't doing this in app/framework
>>> so we can merge easier, but would love to do see it done/do it)
>>>
>>> Well, looks like we'll continue on our own marry way on this one,
>>> keep our forked technology to ourselves.... I can feel the rope
>>> pushing that I mentioned previously. ;-)
>>>
>>>
>>>
>>>
>
Re: getter/setter facade
Posted by Marc Morin <ma...@emforium.com>.
Well the good old GenericValue is an object as well. ;-)
Marc Morin
Emforium Group Inc.
ALL-IN Software
519-772-6824 ext 201
mmorin@emforium.com
----- Original Message -----
> when you use a Class it is an object.
> getter and setter are methods by another name.
> if you instantiate a class all the methods are carried with it whether
> they are used or not.
> so regardless of your argument it is OO.
>
> if you are familar with c then create a hello world function and
> compile then create a class hello world. not the difference in size
> and look at
> the stack for a call to both.
>
> the last time I did this the function compiled to 1K the class compile
> was 10K with no methods in the class.
>
> then put getter and setter in the hellow world and watch the size and
> the stack when using the class.
>
> this will give you an idea of what is being talked about.
>
>
>
> =========================
> BJ Freeman
> Strategic Power Office with Supplier Automation
> <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
> Specialtymarket.com <http://www.specialtymarket.com/>
> Systems Integrator-- Glad to Assist
>
> Chat Y! messenger: bjfr33man
>
> Marc Morin sent the following on 12/11/2010 12:40 PM:
>
>
> > 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();
> >
> > My point is, there is a simple facade we can present on all the
> > goodness of the GenericValue, delegator, dispatcher, transactions,
> > that makes the Java purest feel better about OFBiz. (been easier to
> > find Java developers than OFBiz ones...)
> >
> > We have been using this exact decorator pattern in our OFBiz
> > application for over 2 years, it feels natural when writing Java
> > code (ie. when in Rome act like a Roman), haven't heard any
> > developers say they don't want to use it in favor of the "String"
> > way, once exposed to it and writing new code. When modifying
> > existing code, they want to change all GenericValues to their
> > appropriate object decorator. (we aren't doing this in app/framework
> > so we can merge easier, but would love to do see it done/do it)
> >
> > Well, looks like we'll continue on our own marry way on this one,
> > keep our forked technology to ourselves.... I can feel the rope
> > pushing that I mentioned previously. ;-)
> >
> >
> >
> >
Re: getter/setter facade
Posted by BJ Freeman <bj...@free-man.net>.
when you use a Class it is an object.
getter and setter are methods by another name.
if you instantiate a class all the methods are carried with it whether
they are used or not.
so regardless of your argument it is OO.
if you are familar with c then create a hello world function and compile
then create a class hello world. not the difference in size and look at
the stack for a call to both.
the last time I did this the function compiled to 1K the class compile
was 10K with no methods in the class.
then put getter and setter in the hellow world and watch the size and
the stack when using the class.
this will give you an idea of what is being talked about.
=========================
BJ Freeman
Strategic Power Office with Supplier Automation <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
Specialtymarket.com <http://www.specialtymarket.com/>
Systems Integrator-- Glad to Assist
Chat Y! messenger: bjfr33man
Marc Morin sent the following on 12/11/2010 12:40 PM:
> 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();
>
> My point is, there is a simple facade we can present on all the goodness of the GenericValue, delegator, dispatcher, transactions, that makes the Java purest feel better about OFBiz. (been easier to find Java developers than OFBiz ones...)
>
> We have been using this exact decorator pattern in our OFBiz application for over 2 years, it feels natural when writing Java code (ie. when in Rome act like a Roman), haven't heard any developers say they don't want to use it in favor of the "String" way, once exposed to it and writing new code. When modifying existing code, they want to change all GenericValues to their appropriate object decorator. (we aren't doing this in app/framework so we can merge easier, but would love to do see it done/do it)
>
> Well, looks like we'll continue on our own marry way on this one, keep our forked technology to ourselves.... I can feel the rope pushing that I mentioned previously. ;-)
>
>
>
>