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

Client command framework improvements #2730

Merged
merged 7 commits into from
Oct 11, 2016
Merged

Client command framework improvements #2730

merged 7 commits into from
Oct 11, 2016

Conversation

azatsarynnyy
Copy link
Member

@azatsarynnyy azatsarynnyy commented Oct 7, 2016

What does this PR do?

  1. Introduced contextual commands.
  2. Added ${explorer.current.file.parent.path} macro.
  3. Cleaned up unused resources.
  4. Refactored code in order to simplify it and made it more clear and understandable:
  • simplified a way of providing new command types;
  • command types api moved to ide-api to avoid unnecessary dependency on machine extension;
  • command management extracted from EditCommandsPresenter to the separate facade - CommandManager. So EditCommandsPresenter now doesn't perform several http requests manipulating with commands but only one;
  • refactored code related to the obsolete terminology CommandPropertyValueProvider -> Macro;
  • macro can provide its description (it will be really useful for showing it in UI);
  • macros processing separated from the command execution and extracted to the separate component MacroProcessor since it's used not only for the commands but in debug configurations for example.

What issues does this PR fix or reference?

Mainly, it was done for https://github.com/codenvy/artik-ide/issues/139.

@vparfonov plz review

@codenvy-ci
Copy link

Build # 654 - FAILED

Please check console output at https://ci.codenvycorp.com/job/che-pullrequests-build/654/ to view the results.

@codenvy-ci
Copy link

Build # 658 - FAILED

Please check console output at https://ci.codenvycorp.com/job/che-pullrequests-build/658/ to view the results.

@codenvy-ci
Copy link

Build # 666 - FAILED

Please check console output at https://ci.codenvycorp.com/job/che-pullrequests-build/666/ to view the results.

Copy link

@dkulieshov dkulieshov left a comment

Choose a reason for hiding this comment

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

Great job

*/
protected CommandConfiguration(@NotNull CommandType type, @NotNull String name, @Nullable Map<String, String> attributes) {
public CommandImpl(String name, String commandLine, String type) {
this.name = name;
Copy link

@dkulieshov dkulieshov Oct 10, 2016

Choose a reason for hiding this comment

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

I guess this can be replaced by a public CommandImpl(String name, String commandLine, String type, Map<String, String> attributes) constructor call, what do you think?

Copy link
Member Author

Choose a reason for hiding this comment

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

of course
thx

this.attributes = attributes;
this.commandLine = commandLine;
this.type = type;
this.attributes = new HashMap<>(attributes);

Choose a reason for hiding this comment

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

Do you think we can use an unmodifiable map here?

Copy link
Member Author

Choose a reason for hiding this comment

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

we can )
fixed


/** Creates copy of the given {@link Command}. */
public CommandImpl(Command command) {
this.name = command.getName();

Choose a reason for hiding this comment

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

Probably we can use a constructor call here, can't we?

Copy link
Member Author

Choose a reason for hiding this comment

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

sure
thx

return type;
}

@Override
public Map<String, String> getAttributes() {
if (attributes == null) {

Choose a reason for hiding this comment

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

I assume this lazy initialization should never happen as we will always initialize this field in class constructors, agree?

Copy link
Member Author

Choose a reason for hiding this comment

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

agree
fixed

public Promise<List<MachineDto>> getMachines(String workspaceId) {
return asyncRequestFactory.createGetRequest(baseHttpUrl + workspaceId + "/machine")
.header(ACCEPT, APPLICATION_JSON)
.loader(loaderFactory.newLoader("Getting info about bound machines..."))
Copy link

@dkulieshov dkulieshov Oct 10, 2016

Choose a reason for hiding this comment

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

I might be wrong but shouldn't such kind of message be mapped by a localized constants routines?

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, it should be a localization constant but it should be done for all gwt-clients for che services. May be in a separate PR in future.

Choose a reason for hiding this comment

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

I guess we need a dedicated task to fix this throughout the sources because this is not really related to this very issue

* <p>{@inheritDoc}
*/
@Override
void go(final AcceptsOneWidget container);

Choose a reason for hiding this comment

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

Looks odd, I guess that comes from inheritance?

Copy link
Member Author

Choose a reason for hiding this comment

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

yeah, it comes from the super interface
fixed, thx

return expandMacros(promise, stringContainer, macroRegistry.getMacros().iterator());
}

private Promise<String> expandMacros(Promise<String> promise,

Choose a reason for hiding this comment

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

I would recommend to avoid recursion here because that makes the logic a bit complicated in my humble and subjective opinion but I'm curious about yours.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah, I agree with your opinion Dmitry. But I believe it should be done in a separate task since I've just moved this code 'as-is' from another class during refactoring. And I don't want to modify it in this PR.
IMO In general, this algo of expanding macros wants to be rewritten to be simpler for understanding and easier for supporting.

};
}

private class StringContainer {

Choose a reason for hiding this comment

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

If I'm not mistaken this can be a static nested class

Copy link
Member Author

Choose a reason for hiding this comment

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

you aren't mistaken of course
let it be a static nested class
fixed

return workspaceServiceClient.addCommand(appContext.getWorkspaceId(), commandDto).then(new Function<WorkspaceDto, CommandImpl>() {
@Override
public CommandImpl apply(WorkspaceDto arg) throws FunctionException {
final CommandImpl newCommand = new CommandImpl(commandDto.getName(),

Choose a reason for hiding this comment

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

I guess we can use new CommandImpl(commandDto); here, what do you think?

Copy link
Member Author

Choose a reason for hiding this comment

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

good catch
thx


String workingDirectory = null;

if (cmd.hasArgument("-f")) {

Choose a reason for hiding this comment

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

I think such kind of routines should be moved into CommandLine class so we could run something like workingDirectory = cmd.nextTo("-f"); and get all we need, that would properly encapsulate the logic, what do you think?

Copy link
Member Author

Choose a reason for hiding this comment

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

Good idea for the further improvements of CommandLine class. 👍
I think it should be done in a separate task since I've just moved this code 'as-is' from another class during refactoring.

Choose a reason for hiding this comment

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

Of course! It's just a suggestion to keep in mind for the next time

@codenvy-ci
Copy link

Build # 679 - FAILED

Please check console output at https://ci.codenvycorp.com/job/che-pullrequests-build/679/ to view the results.

@codenvy-ci
Copy link

Build # 680 - FAILED

Please check console output at https://ci.codenvycorp.com/job/che-pullrequests-build/680/ to view the results.

*
* @return a promise that resolves to the real value associated with macro
*/
Promise<String> expand();
Copy link
Contributor

Choose a reason for hiding this comment

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

Not clear name of method for me maybe better something like "explicate or evaluate"

Copy link
Member Author

Choose a reason for hiding this comment

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

I think it's clear enough because it's a general terminology.

From https://en.wikipedia.org/wiki/Macro_(computer_science):

they are called "macros" because a big block of code can be expanded from a small sequence of characters

@azatsarynnyy azatsarynnyy merged commit 2ba8cdf into master Oct 11, 2016
@azatsarynnyy azatsarynnyy deleted the commands branch October 11, 2016 08:38
@azatsarynnyy azatsarynnyy added this to the 5.0.0-M6 milestone Oct 11, 2016
@codenvy-ci
Copy link

Build # 683 - FAILED

Please check console output at https://ci.codenvycorp.com/job/che-pullrequests-build/683/ to view the results.

JPinkney pushed a commit to JPinkney/che that referenced this pull request Aug 17, 2017
Client command framework improvements

1. Introduced contextual commands.
2. Added ${explorer.current.file.parent.path} macro.
3. Cleaned up unused resources.
4. Refactored code in order to simplify it and made it more clear and understandable:

- simplified a way of providing new command types;
- command types api moved to ide-api to avoid unnecessary dependency on machine extension;
- command management extracted from EditCommandsPresenter to the separate facade - CommandManager. So EditCommandsPresenter now doesn't perform several http requests manipulating with commands but only one;
- refactored code related to the obsolete terminology CommandPropertyValueProvider -> Macro;
- macro can provide its description (it will be really useful for showing it in UI);
- macros processing separated from the command execution and extracted to the separate component MacroProcessor since it's used not only for the commands but in debug configurations for example.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants