Feature Request: Allows @ZeebeVariablesAsType in handler function
See original GitHub issueThis feature should enable the possibility to get variables injected in a typed manner like this:
@ZeebeWorker(type = "foo", autoComplete = true)
public ProcessVariables handleFoo(@ZeebeTypedVariables ProcessVariables variables){
// do whatever you need to do
return variables;
}
Inspired by @berndruecker .
Issue Analytics
- State:
- Created 2 years ago
- Comments:9 (9 by maintainers)
Top Results From Across the Web
Feature Requests: What are they and how to manage them
Feature requests are a form of product feedback you may frequently encounter as a SaaS product manager. They typically come in the form...
Read more >Feature request handling - Zendesk help
1. Create an Enhancement request ticket in Jira assigned to Development · 2. Evaluate the request and decide on delivery vehicle and release ......
Read more >How To Handle Feature Requests - The Ultimate Guide for ...
How to track and manage feature requests in an organized and systematic way, all leading to better product execution.
Read more >Handle Requests Sent by Alexa | Alexa Skills Kit
This handler uses functions provided with the RequestEnvelopeUtils to retrieve a slot value. You can also access slots via the intent object within...
Read more >In-App Feature Requests - Instabug
To be able to use Instabug's Feature Requests product, you must first integrate the SDK. Allowing users to suggest new features can be...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Thanks Falko - super helpful!
“So it wouldn’t make sense to have multiple such objects. Unless, each of them is only a partial mapping, which I’m wondering how this is handled by the mapper.” --> precisely, the mapper ignores everything that is not part of the variables class, so you could create classes containing partial mappings (not sure if this is a good idea though).
Let’s do this: I’ll merge the PR now and we will have the two annotations available. And then we wait a couple of months to see it used in reality, and then we can still define a shortcut to save annotations if we feel this is important. The other way round it would also mean to have a breaking chance - which we should not do.
I’d love to avoid the
@ZeebeVariable
annotation in favor of a crisp readable syntax, especially when working with many variables. What confuses me is when you say to treat “all method parameters” as “VariablesAsType” becausejob.getVariablesAsType(ProcessVariables.class);
maps all process variables to fields/properties of the provided class. So it wouldn’t make sense to have multiple such objects. Unless, each of them is only a partial mapping, which I’m wondering how this is handled by the mapper.Thus, my suggestion would be to use an
@VariablesAsType
annotation for the variables to object mapper and rather make@ZeebeVariable
optional to say that all method parameters that are@ZeebeVariable
ActivatedJob
JobClient
@VariablesAsType
will be treated as individual variables to be casted to the respective parameter type, e.g.
The object mapper would thus stick to an annotation, which is less clutter in this case because it’s only one such parameter:
How do we know that the returned object must be mapped back to variables?