I agree, though I am biased, Apache OFBiz IS the best thing out there. However, I don't think OFBiz is the best thing that COULD be out there.
That said, I don't think that everyone should take the approach I am taking. If everyone did, there would be too much competition for me. On the other hand, if I personally did not take this approach... OFBiz would not exist. -David On Jan 25, 2011, at 2:19 PM, Ruth Hoffman wrote: > David: > Thanks for elaborating. IMHO, nothing you have outlined here is a show > stopper. What a shame that you can't see what others (many others...I'm > finding more each day) can clearly see: OFBiz is the best thing out there. It > may not be perfect in your eyes, but another framework isn't the answer. > IMHO, understanding how to work around any objections, being honest and open > about any limitations (if they really do exist) and remaining open to new > ways of thinking about OFBiz is the only way forward. > > Regards, > Ruth > > On 1/25/11 4:53 PM, David E Jones wrote: >> On Jan 25, 2011, at 6:02 AM, Ruth Hoffman wrote: >> >>> On 1/25/11 2:06 AM, David E Jones wrote: >>>> 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. >>> David - you keep saying this..Please provide some examples of "cumbersome >>> and inconsistent" within the framework. And why not try and fix these? >>> Instead of reinventing the wheel. What "funny quirky" things have turned of >>> prospective developers? Do you have an specific examples? >> Yes, I have mentioned these many times especially in the last 2-3 years. >> Some of them I have tried to fix in OFBiz itself and ran into rather large >> problems. These are not easy changes to make in a large and mature project >> like OFBiz, and after trying a few times I decided that a new framework was >> the only way forward (another thing I've written before and made very clear). >> >> These are the things that led to many aspects of the design of Moqui, and >> the best summary of them is the document I wrote about the differences >> between the Moqui and OFBiz frameworks: >> >> http://sourceforge.net/projects/moqui/forums/forum/1086127/topic/3597296 >> >> To sum up here are some of the major inconsistencies and annoyances in the >> current OFBiz framework that bug me frequently while I'm developing: >> >> 1. XML actions are different in each widget and in the simple-methods; they >> share some underlying code but there are so many differences >> >> 2. scriptlets and expressions are a messy combination of BeanShell, UEL, and >> Groovy and keeping track of which is a pain, plus the Groovy syntax and >> capabilities are SO much better than the others so I find myself almost >> always using ${groovy:...} instead of the default, and in annoying places >> like the form.field.@use-when attribute since it is always BeanShell I just >> use a set action to prepare a boolean and then check it in the use-when >> (BeanShell is HORRIBLE compared to groovy, especially when squeezed into XML >> attributes) >> >> 3. the controller.xml file gets HUGE for larger applications, and if split >> it becomes harder to find requests and views; *Screen.xml files also tend to >> get HUGE with large numbers of screens in them; both are not organized in >> the same way as the application, also generally making things harder to >> find; views/screens and requests don't define incoming parameters so when >> doing request-redirect you have to specify the parameters to use in a larger >> number of places >> >> 4. another on the topic of why so many files: service groups and >> simple-methods are just XML, why not include them inline in the service >> definition (especially for smaller services), and encourage fewer services >> per file >> >> 5. loading of artifacts is not very lazy, meaning lots of unused screens, >> forms, services, entities and so on that are not used are loaded anyway; >> also many artifacts are difficult to reload by cache clearing and so that >> has limited support in OFBiz; this slows things down reloading lots of stuff >> in development, and results in more resources used than needed in production >> >> 6. the deployment model of OFBiz is limited and the use of static fields for >> initialization makes it difficult to deploy in other ways; there are few >> init/destroy methods and object instances that would make more deployment >> models easier and more flexible; also because of this it is difficult to get >> data from other parts of the framework (for example the audit log stuff in >> the OFBiz Entity Engine uses ThreadLocal variables to pass userLoginId and >> visitId down since there is no other good way of doing it); in other words, >> the tools don't share a context >> >> 7. no API for apps; the framework is made up of an enormous number of >> classes that follow a bunch of different "patterns" (in quotes because the >> use of the term is generous) because of various people "cleaning" things up >> over time (also in quotes because the use of the term is generous), and >> there is no distinction between the API that apps are intended to use and >> the internal implementation of that API; this has the nasty side effect of >> making it difficult to find the object and method you want, AND it makes >> backward compatibility problems REALLY nasty because it gets people >> believing that EVERY SINGLE object needs to ALWAYS be backward compatible... >> and that results in more and more piles of trash code lying around over >> time, and all of that code and differing patterns makes framework changes >> error-prone and unnecessarily difficult (and this is true for some of the >> app code in OFBiz too) >> >> I should get back to work... there's a short list anyway... >> >> The trick is how to solve these without abandoning backward compatibility, >> and requiring a refactor of much of the framework and then based on that the >> updating of massive numbers of application artifacts... and that is just the >> stuff in OFBiz itself... not including everything that everyone else has >> written outside the project that they may want to update. And, ALL of that >> would have to be retested. Plus, it would take so long to get all of this >> done in a branch with huge numbers of changes while others are making >> incremental changes in the trunk making it nearly impossible to merge the >> branch into the trunk, so it would basically be a fork anyway... >> >> -David >> >> >> >
