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
