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" <[email protected]> >>>> 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" <[email protected]> >>>>>>> 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. > >
