Hello everyone, I've been thinking for a few weeks about this topic, so I thought I'd just share my thoughts here.
OFBiz has great DSL, it is a blessing, it makes things easier OFBiz has great DSL, it is a curse, it makes things sloppy I think OFBiz is unique and it's rare to find software projects where non-programmers can participate. It makes the pool of participants bigger. But there is a price to pay in terms of quality. problem ----------- OFBiz has too much DSL. The amount of XML in the code base makes everything else looks tiny in comparison. As many programmers know, a DSL (Domain Specific Language) is just a tool to make certain things easier / faster. It is not _the_ solution for everything. In many frameworks that I use when things get too complicated I drop down to programming because the DSL hits certain limits and becomes a pain to deal with. When we write everything at a high level (DSL) we can accomplish a lot, but the drawbacks include: - Verbosity - Copy-paste patterns - Repetition due to inability to reuse - Inflexible architecture: - services do not compose - debugging becomes hard - reusability is low - modularity is low proposed direction -------------------------- We have a word in the community: "Functional". We mean by this word a person who is familiar with the entity model of OFBiz and understands how the system works through the DSL but has limited or no ability to program in a general purpose programming language. Many times when we hit an architectural problem, a solution at the programming language level can be as dramatic as 1% the size of the DSL solution and maybe 100 times faster. It can also be cleaner and more re-usable. I think maybe part of the solution is to encourage some of our "Functional" community members to embrace and enhance their programming skills and not settle for only functional knowledge. Examples for doing that: - Embrace Java, it's the number 1 programming language on the planet - Maybe attend basic coding lessons if possible - Read online, plenty for resources - Ask for help, from my experience people _love_ giving it here in the ASF - Before writing a custom widget, think, maybe you can resolve it with an FTL macro and make a root solution for many other widgets - Before repeating a CRUD service for the 100th time, think, maybe you can factor out common code into a nice Java service with parameters. - Why not replace all this wiring of events, services and ECAs and very complex route with a simple single service? Do i make sense? Sorry if babbled a lot, and congratulations if you made it to this line :) I'd love to hear your thoughts. Cheers, Taher Alkhateeb
