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
mmo...@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. ;-)
