Add conditional handler in the handler chain

[ddobrin]

My client is inquiring about the addition of a 'conditional' handler in the chain, which would allow the selection of the next handler to be executed based on a config, similar to a previous framework they have been using.

For example:
handler1 might wish to execute, in a certain scenario, handler2_1 or handler2_2, based on a named element in the chain.

The next handler would be selected from a set of names provisioned in the handler.yml and not be just provisioned in the code.

It could be implemented by overloading:
public static void next(HttpServerExchange httpServerExchange) and
public static HttpHandler getNext(HttpServerExchange httpServerExchange) with a "next handler" name. Provisioning the incorrect name would have to fail the chain and is an artifact identified in testing.

In case this is the last handler in the chain, the issue can be solved in a different manner, however, if the chain is to be continued, there might be benefits to adding this feature.

Is this something we wish to consider?

[stevehu]

This is a valid use case and I am wondering if we can provide a generic middleware handler to with a config file to define the conditions and which chain to be called given evaluation result. In the handler.yml, we can define two or more chains and the endpoint handler will be config with the generic middleware handler as the last handler. The handler instance itself will call one of the chains defined in the handler.yml file. The other options would be let users to create customized handler to do the same job per their use case but at least it would be very helpful if we can provide a generic handler so that others can learn and customize it if their logic is complicated and cannot be handled by the handler we provide. What do you think?

[ddobrin]

Definitely a generic, reusable middleware handler.

I have implemented in a previous framework as:

1. handler in the chain is provisioned with a set of allowed paths' to follow, aka a list of allowable chains, for safety.
2. offered 2 variations:
   2.1 handler was calling a "next" and would specify the desired action to be taken, in this case it would be the next handler to be executed. Generic handler selected the next handler if it found it configured in the list and invoked it. It failed if the value was not found.
   2.2. handler allowed the injection of a class in the generic handler. The class would evaluate then select the next handler. it allowed a more elaborate decision based on information available in its service context, which here could be info in the request or an attachment. The handler was still generic, wired in the same way, and developers would just provide the class making the decision.

I would go initially with the first, as it would solve the immediate issue for my current client and think that the second is something useful for elaborate cases where the next would be multiple possible chains, more than an A or B type scenario.

[stevehu]

Both are good ideas. We can implement the option 1 first and then option 2 when we have time.

[ddobrin]

Agreed.

[DSchrupert]

I think this already exists, but in a way that is not config driven:

/**
 * Allow nexting directly to a flow.
 *
 * @param httpServerExchange
 *            The current requests server exchange.
 * @param execName
 *            The name of the next executable to go to, ie chain or handler.
 *            Chain resolved first.
 * @param returnToOrigFlow
 *            True if you want to call the next handler defined in your original
 *            chain after the provided execName is completed. False otherwise.
 * @throws Exception exception
 *
 */
public static void next(HttpServerExchange httpServerExchange, String execName, Boolean returnToOrigFlow)

[ddobrin]

I have not noticed this method in the Handler class and it represents a step into the desired direction

I think wiring in a generic handler would bring in 4 benefits:

• selection of the next handler in the chain, as per the previous note
• as this is developer driven, it could validate/fail if the execName is not one of the configured ones
• more important, it would bring clarity to the handler.yml, as any developer would see that this handler is a decision handler, and these are the allowed values.It is more legible and clear to understand, without having to go to code
• a decision function can be injected later, time permitting, in that class

[stevehu]

So far, there is no clear requirement for this feature. Closed the issue.

[ddobrin]

Issue reopened:
Client has a use case for this issue.

Details on the use case are to be provided.

[stevehu]

Given there are no concrete use cases for this feature, this issue is closed for now. If anyone needs this feature, please reopen this issue. Thanks.