Hello Taher, Taher Alkhateeb <slidingfilame...@gmail.com> writes:
> 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 The link between "business orientation" and the use of Groovy DSL is only theoric. > - 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. The amount of work is minimal in comparison to the effort of migrating from Minilang to Groovy, since this is basically a matter of changing the signature of the Groovy service and extracting the delegator and dispatcher for the dispatch context parameter. > I'm also not sure the problems you're facing are really that critical. To make it clear this is not *my* problem. As a professional programmer I can live with this extra incidental complexity which only slows me down. The problem is in fact the one of the business people which have to pay for this extra time. :-) > 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). The con I mentioned is theoric since, my experience in regard of unit testing Groovy DSL code is based on testing the ‘GetLocaleList’ action for the ‘LookupLocale’ screen. For services I think the business logic and validation of data contained in services could often be extracted in separate unit testable methods which would allow cheap better case coverage to complement the integration test which is about checking that the service has the expected effect on the database. -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
