Upcoming talks and demos:

Codemotion - Amsterdam - 16 May
DevDays - Vilnius - 17 May
Strata - London - 22 May



View Natalino Busa's profile on LinkedIn
Principal Data Scientist, Director for Data Science, AI, Big Data Technologies. O’Reilly author on distributed computing and machine learning. ​

Natalino leads the definition, design and implementation of data-driven financial and telecom applications. He has previously served as Enterprise Data Architect at ING in the Netherlands, focusing on fraud prevention/detection, SoC, cybersecurity, customer experience, and core banking processes.

​Prior to that, he had worked as senior researcher at Philips Research Laboratories in the Netherlands, on the topics of system-on-a-chip architectures, distributed computing and compilers. All-round Technology Manager, Product Developer, and Innovator with 15+ years track record in research, development and management of distributed architectures, scalable services and data-driven applications.

Tuesday, July 17, 2012

Chained actions in Play! Framework 2.0 (Scala)

Chaining actions in Play is not really easy. The main problem is that an action does not return an action, but a response type. So actions cannot be nested explicitely. I have written a wrapper around the Action trait to deal with Actions which are not terminal, but which are meant as intermediate processing and chain towards other Actions.

By using this pattern, you can write a tree of actions and propagate your handling down to more specialized actions. Hence you can starting with a set of general actions for your routing, and depending on the data processed move on to more specific actions. I have defined this intermediate actions as "ChainedAction". More in details, a chained action uses currying to pass on the request to other actions. Currying is the core technique used in this wrapper to define an arbitrary number of parameters for each (chained) action.



Ok, nice intro, but what can you actually do with it? Well you can simplify the chaining of the action as follow:



Some remarks:

1) As you can see a play! Action must return a response, hence they are not suited for chaining. On the other side a chained action returns an action or another chained action. This allows to compose actions more easily. You can create complex trees of (chained) actions this way, where the terminal action are the default play Actions which return the response type.

2) Each chained action, always passes on the request data to the next action down the action tree.

3) You can still define an arbitrary number of variables to be passed to each level of chainedAction.