Skip to content
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

Placement of navigation icon #142

Closed
sopotsabadze opened this issue Oct 6, 2022 · 2 comments
Closed

Placement of navigation icon #142

sopotsabadze opened this issue Oct 6, 2022 · 2 comments

Comments

@sopotsabadze
Copy link

Enhancement Description

If I create command class and send it to another method as a parameter, which in turn call the command gateway, navigation icon is shown in the place where command object is created and not where the send() method is called. It would be easier for the developer to navigate between command senders and handlers if the icon was shown where command is sent.

Here is an example:

public class CommandCreator {
        public void createCommand() {
            sendCommand(new TestCommand());
        }
        public void sendCommand(TestCommand command) {
            commandGateway.send(command);
        }
}

Current Behaviour

Navigation icon is shown next to the sendCommand(new TestCommand()); method.

Wanted Behaviour

Navigation icon should be shown next to the commandGateway.send(command); method.

Problem becomes more annoying when command creation is in one class and sending is in another.

@CodeDrivenMitch
Copy link
Member

Hello @sopotsabadze, thanks for your feature request.

The reason we put the line marker on the constructor (or builder) invocation is that that is usually the place where the business decision is made. It's also easier to scan for the constructor invocations of concrete classes, instead of all calls to the CommandBus and CommandGateway (method invocation indices tend to be very slow, I tried that before).

Besides that, I assume you have a service that actually sends the command and the command is passed as a parameter. If that parameter is abstract (or even Object/Any), it would match a lot or all commands in your classpath, making navigation very tedious with a large list of options.

Considering these aspects I think it's better to leave the implementation as-is.

@sopotsabadze
Copy link
Author

I understand, thank you for the consideration and attention to this matter.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants