So I think we cannot look at things purely from a theoretical point of view. There has to be a balance between clean code and continued usability.
Pros of your approach: - cleaner semantics - less pollution of the global namespace - the other benefits you mentioned Cons of your approach: - less orientation towards business focused individuals - more work on part of the developer. The DSL was always historically a comfort point for OFBiz not just the groovy DSL but XML and everything else. - Major amount of work to refactor all the services. I'm also not sure the problems you're facing are really that critical. For example, you mentioned a con in unit-testing support functions? Really? It's a support function for a service, you _must_ have an integration test for that thing anyway. You cannot apply TDD on services, the nature of it is just not workable. And If you add unit tests your support functions you have now mixed production with test code without an obvious advantage (TDD is about millisecond tests). So weighing the pros and cons, and listening also to Jacopo's feedback, I'm not sure this would be a highly valuable move. On Wed, Nov 14, 2018 at 7:35 PM Mathieu Lirzin <mathieu.lir...@nereide.fr> wrote: > > Hello Jacopo, > > Jacopo Cappellato <jacopo.cappell...@hotwaxsystems.com> writes: > > > thank you for starting this interesting conversation. > > I think it is fine to implement services in plain Java or in plain Groovy > > methods and you have highlighted some of the advantages over their > > implementation using the Groovy DSL. > > However in my opinion the Groovy DSL (even in its current "basic" version, > > implemented thru a few lines of code, that could be enhanced and extended) > > has some advantages too and may be preferred by a different audience of > > "users" that are more focused on business rules than on programming; data > > preparation scripts are also a good fit for the DSL. > > Sure, allowing “business oriented” people to adapt OFBiz to their needs > by letting them to automate a process in terms of business rules is > *very* valuable. > > I never had the chance to exchange with people focused on business rules > working with OFBiz which are able to write services/ECA/handlers. > However I am rather skeptic regarding your claim that the Groovy service > DSL allows a wider audience to adapt/compose OFBiz services to their > needs. I guess it serves more as a “fun” thing for programmers to play > with, than something with an effective business value. > > In my opinion improving simplicity (locality, uniformity, value > orientation, ...) would be far more effective at empowering both > business and code oriented programmers. [1] > > Thanks for sharing your view. > > [1] https://www.infoq.com/presentations/Simple-Made-Easy-QCon-London-2012 > > -- > Mathieu Lirzin > GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
