+1
A much better explanation of my thoughts than I could have put into words.
Thanks,
Michael
Am 02.05.23 um 11:43 schrieb Daniel Watford:
Hi Nicholas,
I can see value in the approach I think you are proposing (please correct
me if I am wrong) which I would summarise as:
- All scripts are
Hi Nicholas,
I can see value in the approach I think you are proposing (please correct
me if I am wrong) which I would summarise as:
- All scripts are considered service implementations and will handle
parameters and return types accordingly, and
- GroovyEventHandler should invoke an event
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,
I like the idea that the developer do not have to sync about which
method to use.
If I understand well what Michael envision, i.e. to use for event a new
GroovyBaseEvent class, and for services/scripts a GroovyBaseScript
class, that both extends a common class for the common code,
To have it even more clear, I would separate logic for events and services.
The GroovyBaseScript in the service engine package should only be used
for services and there should be another one for events, if really
needed. Mixing both together is bad practice IMO. There seem to be only
7
Hi Daniel,
I dont think there is a knowledge about methods being both services and events.
I think there are not (much?) such cases.
Being acquainted to OFBiz logs I did not check the trunk demo log content (now
in Docker);
so I wonder if there are such other cases than
Hello,
In my opinion, the semantics of calling an event handler vs a service
implementation are different, albeit similar enough that most
handler/implementation authors wouldn't necessarily care how the code was
called.
The untyped nature of Groovy had allowed a certain degree of flexibility in
Hi All,
At OFBIZ-12801, we had a discussion with Daniel and Gil about the described
issue (last comments there)
We are unsure of the best solution, so this thread to discuss and decide.
As Gil reported, Jacopo's comment of the related commit* contains
<>
What would be your opinion about a
10 matches
Mail list logo
