Hi,
My preference would be to the simplest for developer and keep the three
word (error, failure and success). For that, we can force the return of
each function as Map.
After delegate the problematic to each handler. By the way, the
GroovyEventHandler that call GroovyBaseScript already
Hi Gil,
I don't think we need to go as far as creating a new GroovyBaseClass.
Deprecating GroovyBaseScript:success is still preferred in my opinion,
replacing it with serviceSuccess and scriptSuccess. These two methods could
return separate types which extend from Map and help make it clear
Hello I got a quick look about it, having two separate class means
having two distinct groovy DSL and need lot of modification that IMO are
not worth the complexity for this subject.
I now only wonder, is it that bad too keep that one exception (about
untyped return) for
Hello Wiebke,
Please could you confirm that this work only relates to groovy code that is
expected to be compiled to class files and will not alter the structure of
the various groovyScripts directories in OFBiz components?
The reason for checking is that groovyScripts are loaded as independent
danwatford merged PR #8:
URL: https://github.com/apache/ofbiz-tools/pull/8
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail:
Hi everyone,
I have created OFBIZ-12813 to coordinate the refactoring work.
Best regards,
Wiebke
Am 27.04.23 um 19:18 schrieb Jacques Le Roux:
Hi Michael,
Actually, as you may have seen with recent Daniel's work, lazy
consensus is de facto if nobody oppose :)
Cheers
Jacques
Le
