This is a good question that basically provides context for what we've been discussing. Why use a framework like the OFBiz Framework or Moqui when there are so many other frameworks out there?
1. nearly all frameworks out there follow and "object-mapping" approach (everything is mapped to objects) instead of domain-specific artifact approach (ie instead of defining a Java class that represents a screen, just define a screen using a "language" designed for defining screens; same with services, relational data/entities, etc, etc) 2. even among the object-mapping crowd there are not many comprehensive frameworks, mostly just a bunch of tools and you have to cobble them together and fill in the gaps; I often use JBoss Seam as an example since they have a pretty complete stack, but just try using it compared to the OFBiz Framework and you'll see that there are LOTS of little gaps to fill and LOTS of decisions about how you're going to use the tools (no strong best practices as there are with OFBiz Framework); Rails and Grails are other frameworks that allow you to make and use DSLs (domain-specific-languages) but the resulting DSLs are not very self-describing and while it is easy to create them these frameworks only come with a very limited and weak set of standard DSLs that do not come close to the feature set of the OFBiz or Moqui frameworks 3. sort of related to #2, most "frameworks" seem to be moving more and more in the direction of smaller and more reusable pieces which results in a bunch of little things that don't work well together and tools that don't know about and/or don't use other tools that would be of value; the OFBiz and Moqui approach is to have a comprehensive set of tools that work well together; for example: the forms know about the services and entities, as do the screens; in Moqui the security configuration knows about all of the various artifacts and allows for run-time inheritable authorization on each; with tools that are all meant to operate in a stand-alone way you can't do that; another innovation that this makes impossible is the idea of a shared execution context that is available for all tools and that has all of the information about what is running and by who and such for the tools to easily handle more advanced features; this was started but never finished in OFBiz, and is the basis for the API design in Moqui (ie the ExecutionContext and all of the related interfaces) So, yes, it's true that the main reason for creating so many framework tools initially was that good tools were hard to find. Over the years the tools out there have improved, and there are many more of the, but they are pretty much all trying to do a better job of the same old thing. Object-Relational-Mapping and general object-mapping and the crazy object bias that exists is unfortunate, and while those approaches are getting better tools the whole idea is flawed to start with. Or, perhaps better said, there are better paradigms to operate under that result in leaner artifacts that are easier to create and maintain, especially for larger applications. In short, if you want to spend a good deal of time being a framework hobbyist along with your application development then the host of tools out there can provide you with endless hours of joy. If you want to focus on building applications and let the framework deal with the low-level crap, then a framework like OFBiz or Moqui is a better choice. -David On Jan 25, 2011, at 1:52 AM, Sam Hamilton wrote: > Can I perhaps ask the stupid question of the thread, the non-developer as I > am reading the dev list... as I understand it when OFBiz was started there > were no mature frameworks that did what OFBiz wanted to do so you guys > created one to fill the void which over time has evolved into what I gather > as a monster of code. My question is why reinvent the framework again now > that there are so many mature java based frameworks in existence > http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks#Java > why create another one, why not instead ride on the back of a project that > will take care of itself much like OFBiz does with Tomcat? Surly there are > going to be plus and minus points to everything and anything that is used? > > > > On 25 Jan 2011, at 16:30, Jacques Le Roux 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 >>> >>> >> >> >
