What attracted me to OFBiz is its ability to work on any database, and any app server. If someone had pitched the advantage of the "OFBiz Approach" versus ORM at the time, I wouldn't have known what they were referring to, let alone understand the differences.
After reading Martin Fowler's Analysis Patterns, I saw a good similarity between his objects and OFBiz entities. There is a strong temptation to map OFBiz entities to those objects, and some good arguments could be made in favor of them. The downside is the loss of flexibility in accommodating table changes - any change made to a table must be reflected in the object. So, I have come to the conclusion that the "OFBiz Approach" is the most flexible one. I'm not sure that epiphany could have come from marketing literature.
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,
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.
-Adrian On 1/24/2011 3:48 PM, David E Jones wrote:
That brings up another good question: will any words written on paper convince people? We have marketing material all over the place, and it has changed a grown a lot over the years... and shrunken and been refined at times too. We could write that the OFBiz Framework approach is way better than all of those object-oriented (or rather, object-mapping) approaches out there, and we could list all of the benefits and (for those interested) all of the reasons why. Is anyone going to believe us? Perhaps if there were a dozen well-known technology journalists who wrote these things instead of us writing it, then more people would believe them. But how do you get journalists (or more to the point the journals or media outlets in general) to write such things, especially the really well-known and well-read ones? Well, that's what the marketing profession is for, including the public relations branch of that profession. But, even they have their limitations... and those limitations are mostly related to whatever budget they are given. So, and this is a jaded perspective, but without a billion-dollar company pimping out the technology, how does one compete with an approach (the object-everything/object-mapping approach) that various billion-dollar corps are pushing, and that thousands of smaller orgs and hundreds of thousands of individuals are going along with, and that dates back around 40 years? Actually, it doesn't date back that long. The object-oriented approach that I don't like dates back more to the introduction of object-relational mapping, and that resulted in object-everything mapping. It's a shame really. Objects are a great way of modeling certain things. The problem is making EVERYTHING an object. Screens are screens, they aren't objects, and objects are a clunky way of modeling a screen. When building a business app (or apps in general actually) we want to deal with things like screens and services and relational data structures (or hierarchical/node data structures like XML or JCR, or other such things), squeezing all of those into the world of objects makes an chaotic, redundant, and painful result. Yes, newer approaches of making objects more like these other things are getting better, but they will never overcome that conceptual mismatch. Never. In some cases domain-specific "languages" have caught on and are a better approach to this. However, they tend to be small and isolated things used for specific purposes. Using them as a general approach for a framework is still pretty unique, with the OFBiz Framework a pioneering effort in that and the Moqui Framework another step toward refining it and making it easier and more efficient and flexible. But, again, those are just descriptions of benefits... who would believe me? People that already think the same thing would, but those who don't or have a different bias won't. And, that brings us back the various billion-dollar corps. And who knows... maybe something better than both will come along and wipe them out anyway... ;) -David On Jan 24, 2011, at 2:59 PM, Jacques Le Roux wrote:David: I think I will thought about that, it's a real good question! I think, with a bit of sweetener, your answer below is a good start. We could discuss it, enhance it and put it as an explanation on the OFBiz main page: *Why OFBiz ?*. It should not be too long, it's always harder to say more with lesser words. Anyway, for the moment I will spleep on it. That's also why I put my last efforts in jQuery. For me, at the moment, the better way to improve OFBiz UI is still through such tools (javascript frameworks, jQuery being the easier to use IMO). This because, I don't want to be too far from the real code underneath. I don't, I have never trusted (so far), generators and such (GWT, etc.). One day though, we will maybe have enough power and perhaps they will be sufficiently smart and reliable, for the moment they are still too much verbose for me... But all is stale because it's always commercial powers struggling below (sometimes very well hidden), so it's like building on sand. We are still in this crasy period, or at least still feeling its madness. James: this said, though I think we don't really need it in OFBiz, Apache Wicket is also nice by itself. I was trying to understand, why you needed it. I thought you had maybe to reuse legacy code in OFBiz and found a good way with Wicket. Jacques David E Jones wrote:That brings up a good question, how could we convince people? -David On Jan 24, 2011, at 2:19 PM, Jacques Le Roux wrote:Thanks David, It's a long way to convince people Jacques From: "David E Jones"<d...@me.com>James, There is a difference between the design of a screen and the tools used to implement it. The generic screens in OFBiz in the business applications layer are meant to be just that: generic. They are not designed around any particular business process because there are SO many different possible business processes, and the more unique yours is, the greater the chance that custom screens will be required to meet the needs of your intended users. This is not rare for OFBiz, or for business applications in general. In fact, this is EXACTLY the situation that the OFBiz framework, and many of the generic business application artifacts, are meant for. These sorts of generic screens are far easier to reuse than very custom screens would be, and depending on your needs some may be far easier than building screens from scratch (ie from just data model and services). What you are proposing is a layer of Java objects to represent the data model, and a tool (Wicket) to use Java objects to represent the UI. That is a preference for Java objects, it is just a different technology. It has nothing to do with what the resulting UI will be like... that is simply a result of designing what you want, and then implementing it. In other words, technology bias has little to do with user interface design. If you give the OFBiz framework a chance as-is I'm sure you'll find that what you develop will be better organized, easier to maintain, and the artifacts will be easier to reuse. This is even more true with a certain next generation framework (www.moqui.org) that is based on many ideas in the OFBiz framework, but with a number of key differences and in general totally rethought and rewritten. Either way, the approach is not object-oriented for the business-level artifacts. That is intentional. Objects are great for implementing certain things, but for business development it tends to result in massive amounts of poorly organized and highly redundant code. This seems to be more true the larger the team gets, and is true even when writing things that extend OFBiz when the recommended tools and practices are not used. One extreme example of this I've seen is a case where over 500,000 lines of Java were written, just for an ecommerce application with around 20 screens. The bulk of the problem was that there were 100 developers who were given license to develop in their preferred way and few of them learned about the tools and practices and reusable artifacts that could save them time and money. So yes, you'll find bias against object-mapping here. What's the point in mapping everything to objects, especially things that do not naturally have an object-like structure? Why do object-relational mapping, object-service mapping, object-html mapping, object-everything mapping when you could just use the relational, service, html, etc concepts more directly? And yes, that concept applies no matter what kind of fancy clothing you try to put on that pig. By fancy clothing I mean things like annotations, inversion of control, and so on. A pig is a pig, and using objects for everything is inefficient, redundant, self-obfuscating, bloated, messy, and inflexible. -David On Jan 24, 2011, at 9:24 AM, james_sg wrote:Hi Jacques, Let me put it another way. I don't think this patch is good as it doesn't reuse the screen definition. Before any improvement can be made to use the screen definition, OFBiz should understand why a layer of POJOs should exist between the screen definition and renderers. Why this component? My client handles numerous orders each day. Each order have hundreds of items. Their existing desktop based ERP system supports the order clerks with that requirement efficiently. Now they want to move to web-based. Many OFBiz's forms are based on the tables instead of business objects. This mean the user have to click here and there in order to edit the forms. More clicking means less efficiency. This component was quickly put up so that I can rework the code to support forms based on business object. That means having the request header, request items etc on the same screen. Regards, James Jacques Le Roux wrote:James, It's quite clear, and IMO you did an excellent and interesting work. Unfortunately, I don't know if we will find enough interest in the community to commit your patch. Mostly because it's a bit redundant and not exactly in the spirit of OFBiz (less compilations and reboots). BTW why was the reason you created this component (apart that maybe you are a huge fan of wicket ;o), did you miss something in OFBiz? Thanks Jacques From: "james_sg"<snowme...@hotmail.com>Hi Jacques, Ok, I agree one con about it, is maintenance. The reason is because the screen renderer in OFBiz is tightly coupled with the screen definition. Since this implementation is a quick hack, I go with the easier way of coding the screen content in java instead of using the screen definition way. It will be good if OFbiz add a layer of POJOs between screen widgets and the renderer. Hope I am clear. Regards, james Jacques Le Roux wrote:Hi devs, James yong submitted a patch (simple enough to be quickly read) proposing to introduce Wicket as an OFBiz framework component. I's be interested to read your comments about pros and cons Note the urlrewrite stuff... One cons I see is maintenance... (We will see if James is still around, he created the Jira issue in August) Thanks Jacques-- View this message in context: http://ofbiz.135035.n4.nabble.com/Wicket-in-OFBiz-tp3233945p3234277.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.-- View this message in context: http://ofbiz.135035.n4.nabble.com/Wicket-in-OFBiz-tp3233945p3234461.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
