brightercommand / docs Goto Github PK

I found the following information confusing in the docs on passing information to the caller (https://github.com/BrighterCommand/Docs/blob/master/source/DispatchingARequest.rst#passing-information-to-the-caller):

In that case add a property to the Command that you can initialize from the Handler, for example create a NewEntityIdentity property in your command that you write the new entity’s identity to in the Handler, and then inspect the property in your Command in the calling code after the call to CommandDispatcher.Send() completes.

Implies that you can add a property to a command that is then updated inside the handler code.

but then the following line says you cannot do this:

Note that you cannot use this strategy with CommandDispatcher.Send() as you have no way to update the Command in process.

Did i misunderstand something here?

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

From https://github.com/BrighterCommand/Docs/blob/master/contents/AsyncDispatchARequest.md:

The asynchronous methods: SendAsync, PublishAsync, and PostAsync all accept a CancellationTokenand pass this token down the pipeline. The parameter defaults to null where the call does not intend to cancel.

CancellationToken a struct so this isn't the case.

Dear,

On readthedocs the index is a little unclear because some subsections have not a good styling, so e.g. 'Implementing a pipeline' is there multiple times but not clear in which context the title/item is relevant.

Currently there are some pull requests to solve an issue with the headers in the documentation.

How can these changes be incorporated into the documentation?

Possibly there are also more. Can I review the docs to adjust them too, so they can be merged too?

Greetings,

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

hi, i'm reading "Commands, Dispatcher, Processor — Brighter" and it's a very interesting doc " but i can't understand some paragraphes because i think that they are contradictory:
At the beginning of Command sections:
"It also serves to decouple the implementation of the request from the requestor. The caller of a Command object does not need to understand how the Command is implemented, only that the Command exists."
At the end of Command sections:
"The problems with the Command pattern are that the caller is coupled to a specific Command at the call site"

Could you give me more information to understand more about this?

In one of our examples at least, we use IRequest as the base for a Command.

See BrighterCommand/Brighter#2304

This is confusing as our advice would be to use Command or Event. in this case, our proposition that this was not a 'breaking change' was broken, because folks using the interface instead of Command have to alter their types to account for the new field

We should also offer advice not to use the "message contracts assembly" as NServiceBus does, to prevent confusion

In https://github.com/BrighterCommand/Docs/blob/master/contents/Logging.md we talk about liblog which was removed in V9

hi notice that the arrow from that link Command Interface to ConcreteCommand go to in wrong direction, it wouldn't go from ConcreteCommand to Command interface?

Class Diagram Command Pattern

Many of the links on https://www.goparamore.io/new-page-2/ are broken

e.g. https://brightercommand.github.io/Brighter/HelloWorldExample.html should be https://www.goparamore.io/hello-world/ ?

Applies to many links on the page - e.g. https://brightercommand.github.io/Brighter/CommandsCommandDispatcherandProcessor.html

(not sure it's an issue in this repo... but this was the most appropriate location I could find... feel free to close it and move it to more appropriate repo)

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.