-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add basic workflow #3
Conversation
request.startStateConfig(processOptions.getStartStateConfig().get()); | ||
} | ||
|
||
public String startProcess(final ProcessExecutionStartRequest request) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use xdb public request as the input to BasicClient to reduce the SDK side wrapper.
return Strings.isNullOrEmpty(namespace) ? DEFAULT_NAMESPACE : namespace; | ||
} | ||
|
||
public String getType(final Class<? extends Process> processClass) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It maybe better to move it to Process class as a package private method(, so that it doesn't require to pass in any parameter. ), or keep it in ProcessUtil
Passing a process class here is a bit strange
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another idea: maybe it's even better to require passing in a Process instance when creating this ProcessOptions (is it possible in lombok to have a required field?, looks like by default all fields are optional in lombok --- looks like just put @NOT_NULL ?)
In the Process interface:
public interface Process{
default getProcessOptions(){
return ProcessOptions.build(this)
}
}
And we can make this build
method as a helper to provide more parameters, like timeout, etc
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In lombok builder, the default value of each field is NULL. Adding @NonNull
will make sure the specified field must be assigned with a non-null value at the RUNTIME.
Use ProcessOptionsBuilder builder(final Class<? extends Process> processClass)
is a good idea to provide ProcessOptions.builder(this.getClass()).build()
.
Lombok also provides another way to genetate the ProcessOptionsBuilder by new ProcessOptions.ProcessOptionsBuilder()
, I didn't find a way to disable it. So when using the new
method to generate the builder, users have to be aware the processClass must be set explicitly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So when using the new method to generate the builder, users have to be aware the processClass must be set explicitly.
yeah that's true. That's why it would be nice if the field being required is clear.
Though, usually when there is a helper build which is easier to use, users would not use the raw/harder one.
|
||
private final String id; | ||
|
||
public String getId(final Class<? extends AsyncState> stateClass) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
similar here, it seems better to pass in the state instance as required for builder?
|
||
public class ProcessUtil { | ||
|
||
public static final String DEFAULT_NAMESPACE = "default"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: I would feel slightly more natural if it's under ProcessOptions. Since it's a static field, it won't mess up with the lombok, I guess
return new AsyncStateExecuteResponse().stateDecision(toServerModel(request.getProcessType(), stateDecision)); | ||
} | ||
|
||
private StateDecision toServerModel(final String processType, final io.xdb.core.state.StateDecision stateDecision) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: toApiModel or toInternalModels. the api is between server and SDKs, technically doesn't have to be owned by server
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
overall looks great, just some small comments
public static final Integer INPUT = 11; | ||
|
||
@Override | ||
public @NonNull StateSchema getStateSchema() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess @nonnull is not required right? It will look a little cleaner if it's not required
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nonnull will make sure the StateSchema will not be null at runtime. So that we don't need to check if (getStateSchema() == null)
in case the user return null
for the method. Adding it can reduce the checking logic on the SDK side.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like we don't have to enforce this. Our SDK can be smart enough to consider a null as empty schema.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got it. Consider a null as empty schema sounds like a more user-friendly approach. I will remove the nonnull annotation and deal with the null cases.
System.out.println("BasicStartingState.waitUntil: " + input); | ||
Assertions.assertEquals(INPUT, input); | ||
|
||
return new CommandRequest().waitingType(CommandWaitingType.EMPTYCOMMAND); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: it would be better if it provide a helper:
CommandRequest.empty();
or
CommandRequest.empty;
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True, when we are ready for other CommandWaitingTypes, we should add helper like StateDecision. I will add it that time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah no problem. You may want it when start writing samples or more integ tests because it will save time. We can always change it later before final launch. When it’s time to share with more people we will have another review to refine the APIs
Assertions.assertEquals(INPUT, input); | ||
|
||
return StateDecision.multipleNextStates( | ||
StateMovement.builder().stateId(STATE_ID_NEXT_1).stateInput(input + 1).build(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
similar here, it would be nicer to have a helper:
Statemovement.create(stateId [class/string], input);
No description provided.