This doesn't make sense... what does "valid" mean in what you wrote?
Trying to understand more generally: are you arguing against progress in general, or just in the case of OFBiz? Do you still drive the first car you ever bought, or a more recently manufactured one of the same design? Wait... maybe that's a bad question because maybe you do... a better question is do you think that most people do or that car companies should continue producing cars designed in the '50s or '60s or '70s? On a related note: How would you feel about a framework designer, or politician, or anyone in any field who stuck by their positions from a decade ago just to stand by them, even their are clearly better ideas around and problems with the old ones? To answer another possible question: yes, in another 10 years I may abandon Moqui and the data model and other projects based on it and do yet another framework. Or, more hopefully, because the Moqui Framework is separate from the rest of those projects we can do new versions of Moqui that are forked from the previous version (as many projects do, Tomcat is a great example of this) and let the other projects update whenever they feel like it, and continue to use older versions as long as it makes sense for them. -David On Jan 25, 2011, at 2:09 PM, BJ Freeman wrote: > what I pick up is you are saying ofbiz is no longer valid and now Moqui is. > How I evaluate that is what is to say that Moqui also will not be valid at > some point so why invest in Moqui. > > > ========================= > > BJ Freeman > Strategic Power Office with Supplier Automation > <http://www.businessesnetwork.com/automation/viewforum.php?f=52> > Specialtymarket.com <http://www.specialtymarket.com/> > Systems Integrator-- Glad to Assist > > Chat Y! messenger: bjfr33man > > > David E Jones sent the following on 1/25/2011 1:53 PM: >> >> 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 >> >> >> >
