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