It is certainly true that the OFBiz Framework includes web application framework elements, but many of the tools listed on that wikipedia page are ONLY web app frameworks and are not more comprehensive enterprise app frameworks. In other words they are mostly UI level things without the service/logic and data layers (though many support Hibernate or the like for persistence).
It would be interested to see OFBiz as a framework listed in more places, but given the difficulty in separating out the OFBiz Framework from the rest of the project I don't know how popular it would ever be for that (yeah, back to that same old discussion of priorities and rules for this and that...). -David On Jan 25, 2011, at 2:41 AM, Jacques Le Roux wrote: > OFBiz is not even in this list, I believe because it's not only a web > framework but rather an ERP using mostly web as UI (we could add it though?) > > Jacques > > 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 > >
