This is a really interesting thread. On Jan 25, 2011, at 3:12 AM, David E Jones wrote:
> > This discussion started with a discussion of Wicket, leading to a discussion > of the approach used in the framework. > > The big question is not how to market OFBiz as a whole, but instead how to > market the OFBiz Framework and the non-object-mapping approach that the OFBiz > Framework uses. > > In other words, how do you sell the framework to developers? Selling the > entire projects to business users and decision makers is another question > entirely. IMO we try to sell the OFBiz framework as a framework optimized for the development of ERP like applications i.e. applications where relational data model and (rather simple but in a large number) business rules play a big part of the game. Something like: if you are planning to build a videogame then pick framework ABC or CDE (there are plenty of them), but if you are planning to build an ERP application (or part of it) then OFBiz is the best choice for you. As a side note: of course OFBiz can be used for more than this, but in my opinion if we, as a community, will find an agreement on the very generic goal of the project (but limiting its scope like I did here) this will be beneficial for the diffusion of the project and also for the community (it will be easier to define the framework vs applications etc...) Just my 2 cents, Jacopo > > -David > > > On Jan 24, 2011, at 5:59 PM, BJ Freeman wrote: > >> word to mouth is the cheapest way. Also give ready made clients. >> I grew up in a industry that was built world wide on this principle. >> I have built my business on the same word to mouth. >> >> the stumbling block with ofbiz has been the size and learning curve. >> even with "Consultants" most clients I deal with think 7days of training is >> to much. >> >> so when Ofbiz gets the reputation, with the end user, of a very big program, >> that does everything they want; that is made for Dummies, it will be an up >> hill effort. >> >> Hence the effort for a Setup and screens with terminology the end user is >> familiar with. Their Terminology is defined by the end users business usage. >> >> >> David E Jones sent the following on 1/24/2011 3:48 PM: >>> >>> 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. >>>> >>>> >>> >>> >
