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