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. > >
