Hi Mathieu,
On Wed, Nov 14, 2018 at 12:38 AM Mathieu Lirzin <
[hidden email]>
wrote:
>
> Basically what I have in mind, is to organize services in classes like
> what is done in Java with the same method signature:
>
> (Map ⨯ Map) → Map
>
> where the maps parameters correspond respectively to the “dispatch
> context” and the “service input”. The main difference with Java
> services is the possibility to write map and list literals, and avoid
> explicit typing with ‘def’. Additionally it would be easy to provide a
> method for the dispatcher which could reads like the current ‘run’
> method of the DSL and provide the same semantics (throwing an exception
> upon failure). Something like:
>
> dispatcher.run service: "fooService" with: [...]
>
One of the most useful features of the DSL is that the userLogin object,
needed to perform authorization checks when a service is invoked, is
automatically retrieved from the "context" and passed to the service call
(similarly to what was happening in the legacy Minilang). The same is
happening for the "timeZone" and "locale" objects. This helps to keep the
code cleaner with more focus on the business rules and less on technical
details. I think we should consider these aspects in the new design.
Jacopo
Locked
