Interesting to note that you did not turn to OpenBravo (joke ;o)
Jacques
Jonatan Soto wrote:
Very interesting threat indeed.
As a developer I find Ofbiz hard to sell because it has no impact on the
mass market where "cutting-edge" technologies rules it, like Struts was or
Spring, Hibernate, etc are for example. Companies are demanding concrete
skills to developers so it's obvious that developers tries to adjust to this
market.
It's almost a year since I started a full time dedication in Ofbiz
customization for my own company and I found it a very productive and
very entertaining. I've learned a lot and I'm still learning, but for some
reasons I have to seek for a job as a developer on a external company. Every
interview I've done they weren't so exited when I said "I'm starting up a
retail company and it's based on an ERP called Ofbiz". I almost dare to say
that Ofbiz is unknown in the IT scenario in Spain. On the other hand
OpenBravo for example it's more well-know because their alliances to the big
companies, as David said, they rule the IT market in general. Another reason
perhaps is the legislation adaptation and business process orientation to
this country that makes OpenBravo easy to sell.
I'm starting a new little project and I wanted to use the Ofbiz framework
only. I'm aware about the efforts done to have this ready but in order keep
updated my skills for this mass marketed IT companies so I finally decided
to do it with GWT+Spring+Hibernate. I need to sell myself.
Regards.
On Tue, Jan 25, 2011 at 9:30 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:
From: "David E Jones" <d...@me.com>
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.
It might be interesting to have a list of the principle issues you think
about..
Jacques
-David
