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