Having just spend 6 months working in a mixed OpenTaps, OFBiz 9.x
environment, all I can say is: "What a mess". Thankfully I do not have
to support the core project base - only my small piece. I still have not
found the value in the OpenTaps/Hibernate implementation. Maybe,
someday, I'll see that light.
David - Please see my other comment inline. I'm particularly interested
in the recurring theme of yours as articulated below:
On 1/25/11 2:06 AM, David E Jones wrote:
On Jan 24, 2011, at 9:20 PM, Adrian Crum wrote:
Having said that, I believe some things in OFBiz could benefit from ORM. Like a
postal address for example. A postal address entity could be supplied to an
object factory to create a postal address object. That object could have
built-in behaviors - like rendering itself correctly based on its locale. Or
knowing its geolocation. Little things like that might benefit from ORM,
Perhaps I am too set in my ways, but when I think of creating something generic
to format an address I think of that as a UI-level thing, preferably
represented in something as close to the UI as possible.
Based on that I'd rather have an FTL macro (or a few for different output
types, different preferred formats like one line versus many lines, etc), and
when that doesn't fit then do a custom template based on the data itself.
The last time I checked in on OpenTaps they seemed to be going in the direction
of ORM and DSL. Maybe there could be some lessons learned from that.
Old habits die hard. I imagine that OpenTaps gets as much, or likely more, pressure to
use "standard" technologies than OFBiz itself does. They have also had key
developers from the very beginning that didn't like the patterns in the OFBiz Framework
and they immediately started replacing it and writing new code using different tools. The
result is quite an impressive pile of code and list of tools used (even larger than the
amazingly bloated list for OFBiz!).
For those who haven't spent much time developing with object-mapping-oriented
tools and don't believe that they are more of a pain, by all means try a small
project. Grab the JBoss Seam stack (for example) and try building the OFBiz
Example application (the main parts of it anyway, not the various JS/etc demo
screens that have been added more recently) with it (after reading the docs
about recommended practices of course, make sure you know what they think of as
a slick way to develop to be fair).
I've worked with a number of people whose first exposure to enterprise app
programming was with OFBiz and later had just such an experience, and the
responses tend to be consistent in a way you can probably imagine.
All of that said, now that Moqui is starting to take shape I find the OFBiz
Framework to be cumbersome and inconsistent in many ways (things that are hard
to fix, but that are not surprising given the pioneering history of the OFBiz
Framework). Those funny quirky things are likely a turn-off to prospective
developers and I'm hoping to remove that impediment to adopting the approach.
David - you keep saying this..Please provide some examples of
"cumbersome and inconsistent" within the framework. And why not try and
fix these? Instead of reinventing the wheel. What "funny quirky" things
have turned of prospective developers? Do you have an specific examples?
-David
