Posted by
David E Jones-2 on
Aug 05, 2006; 7:27pm
URL: http://ofbiz.116.s1.nabble.com/Ofbiz-and-Ruby-on-Rails-tp170367p170378.html
On Aug 5, 2006, at 11:09 AM, David Welton wrote:
> I think some of the principals are applicable, but Java just isn't as
> dynamic as Ruby... I don't know OFBiz' internals well enough to
> comment on specifics, but I definitely think that for the core guys,
> spending a few days with RoR to get some ideas would probably be a
> beneficial use of their time. One of my favorite things about RoR,
> for instance, is "don't repeat yourself" - you write stuff only once,
> if possible, and the framework figures out the rest for you. OFBiz
> tends to have the same, or similar names scattered all over the place.
> In most cases, you don't really want to configure stuff much... good
> defaults would work well enough.
>
> OTOH, OFBiz is pretty big, and what works in Rails might start to
> creak under such a big load.
This is a good point about the OFBiz framework, and is a nice
distinguishing factor comparing it to other tools. The intention is
not to have a minimal set of tools where you define a field once an
never again, but rather to have a true multi-tier enterprise
architecture with each tool taking care of a special purpose.
We do have things in place to allow higher level artifacts to
"inherit" or auto-define things based on lower level artifacts to
make this easier, but for more complicated software that is meant to
be customized, having it all in one place can be a real problem. It
limits flexibility and introduces unexpected side-effects, or to
avoid those side effects because of limited inherent re-usability it
forces you to reuse less and have in reality more redundancy...
So, the point of the way the OFBiz architecture is designed is to
support the type of software we are building: an extensive set of
base, best-practice applications that can be easily customized and
extended to meet the needs of a wide variety of businesses and
industries. This does lead to a lot more work required to tie pieces
together (hence a fairly large artifact reference diagram for the
framework), but every single one of those touch point becomes a point
of flexibility and re-usability in the bigger picture and becomes
worth many times the initial effort required to set it up in ease of
use and reuse later on. It's very much a big picture driven
architecture with business needs as the highest priority, and
technical elegance just under that.
Of course, to ease the inconvenience there are some tools that have
been discussed that will hopefully exist for navigating among OFBiz
artifacts, and even perhaps filling in missing ones and such. I
talked with J. Aaron Farr at OSCON and he has quite a bit of
experience with Eclipse plugin authoring and is interested in working
on this, so who knows... this may exist sooner (and free-er) than
expected.
-David