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

Feature/action context #183

Merged
merged 6 commits into from
Jul 27, 2018
Merged

Feature/action context #183

merged 6 commits into from
Jul 27, 2018

Conversation

rubensworks
Copy link
Member

@rubensworks rubensworks commented Jul 24, 2018

Implements the generalization of a shared context #109.

Do not merge or review yet.

Context keys are now namespaced, for example:
{ '@comunica/bus-rdf-resolve-quad-pattern:sources': [{ type: 'hypermedia', value: ... }] }

The problem with this is that it becomes less convenient for programmatic API users to define sources.

A few possible solutions:

  1. Add shorthand aliases for config entries. Downside is that there can be clashing among aliases now.
  2. Developers must import and use string constant from the modules that define these keys. (we already define these keys) Downside is that context can not be constructed inline anymore.
  3. Add convenience constructors for contexts, such as newSourcesContext([...]). Downside is that it becomes more complicated when your context consists of several other stuff as well.
  4. Leave it as-is, developers now have to use longer key strings.

@joachimvh What is your opinion on these solutions?.

@rubensworks rubensworks self-assigned this Jul 24, 2018
@rubensworks rubensworks added this to In progress in Development 1.2.0 via automation Jul 24, 2018
@coveralls
Copy link

coveralls commented Jul 24, 2018

Pull Request Test Coverage Report for Build 326

  • 96 of 96 (100.0%) changed or added relevant lines in 25 files are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage remained the same at 100.0%

Totals Coverage Status
Change from base Build 324: 0.0%
Covered Lines: 2344
Relevant Lines: 2344

💛 - Coveralls

@joachimvh
Copy link
Member

I prefer 2 or 4. But 2 prevents defining contexts in config files, so I would keep it at 4. The majority of the actors doesn't make use of the context anyway, and if someone creates an actor that makes a lot of use of the context they can define their own variables to make for easier development.

@rubensworks rubensworks changed the title [WIP] Feature/action context Feature/action context Jul 25, 2018
@rubensworks
Copy link
Member Author

Ok, just added backwards compatibility. Ready for review now.

@rubensworks rubensworks moved this from In progress to To review in Development 1.2.0 Jul 25, 2018
* @return {Promise<T>} A promise that resolves to the handle test result.
*/
public abstract async testHandle(action: HI, mediaType: string): Promise<HT>;
public abstract async testHandle(action: HI, mediaType: string, context?: ActionContext): Promise<HT>;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should the context parameter be optional? This might encourage developers to not pass on the context when they receive it.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that makes sense. The context can still be null, but all remove the ?everywhere to make it clear that the context must be passed along.

@rubensworks rubensworks merged commit 5bca0ce into master Jul 27, 2018
Development 1.2.0 automation moved this from To review to Done Jul 27, 2018
@rubensworks rubensworks deleted the feature/action-context branch July 27, 2018 06:26
This was referenced Jul 27, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
Development

Successfully merging this pull request may close these issues.

None yet

3 participants