Titanium JIRA Archive
Alloy (ALOY)

[ALOY-179] Adding commands 'dry-run' option

GitHub Issuen/a
TypeImprovement
PriorityMedium
StatusClosed
ResolutionHold
Resolution Date2012-09-11T10:09:06.000+0000
Affected Version/sn/a
Fix Version/sn/a
ComponentsTitanium SDK, Titanium Studio, XML
Labelsn/a
ReporterShalom Gibly
AssigneeTony Lukasavage
Created2012-08-14T09:47:52.000+0000
Updated2013-05-01T14:56:15.000+0000

Description

At the moment, the Studio side has to check for possible name conflicts when calling the 'generate' commands. Those file-names are hard coded in the code, and we look for any conflicting files in the project before we allow generating (widgets, models etc.). At the end of the process, the Studio also opens up for editing the generated files. Again, by looking at the hard-coded locations, and by appending the name that the user input via the wizard dialog. This mechanism is pretty fragile, and in case Alloy adds or removes a generated file, a Studio update will have to be pushed to follow that change. This leads to a need for some sort of a 'dry-run' argument that can be passed to the 'generate' command, and this is the outline of what I have in mind:

Call a dry-run command. Something like: 
alloy generate widget MyWidget --dry-run

In case no existing conflicting files exist in the target location (project), Alloy will then write out to the output stream the file paths (relative to the working directory) that will be generated.

In case there is an existing file that cause for a name conflict, the Alloy command will return some sort of an error code and the file(s) that conflicts it.

When there are errors, we will not allow the 'OK' button in the wizard, and we will show the error Alloy returned. When everything is OK, we will use the list of returned paths, and open those files at the end of the operation.

Thanks!

Comments

  1. Russell McMahon 2012-08-28

    It seems Alloy could just do the right thing if widget exists and a user tries to generate a new one alloy should simply tell the user the files already exists. I don't understand why Studio cares?
  2. Shalom Gibly 2012-08-28

    We would like to alert the user in the wizard that these files are already there. In these cases, we will simply not allow the 'OK' on that wizard. Also, and even more important, we want to open up those generated files at the end of the process. So in case you add another type of file, the studio will open it without having to change its java code. I understand that the CLI notify the user that the files are already there (or one of them). However, it's easier for us to get the response in a structured form (like JSON), instead of parsing it and hoping you will not change the text ;) Also, I still think it's nicer to inform the user that a file (or a few) will not be generated while the wizard is open. As a user, I find it a lot more informative and friendly.
  3. Russell McMahon 2012-08-29

    Okay sounds good. How will the new platform CLI handle this? Since Alloy will be a part of the new CLI then I think we need to do what the new CLI does.
  4. Ingo Muschenetz 2012-08-29

    @Russ...how does this relate to the new CLI? Won't we still be calling alloy generate widget?
  5. Russell McMahon 2012-08-29

    When the CLI is in place it will be something like "titanium alloy generate widget". At least that is how Chris is thinking about it currently. I'm pushing Alloy to be the default so it would be like "titanium generate widget". But more I was wondering how you are handling the current tasks like new project, and how that will be handled with the new CLI. If there was a standard or protocol the CLI commands report back then I would like to do that.
  6. Ingo Muschenetz 2012-08-30

    Hi Russ. I have no idea how the new CLI will handle it. Honestly, until there is a new mechanism, I'm just going to call alloy X directly.
  7. Russell McMahon 2012-08-31

    Alloy and I think Studio and various teams will be talking next week to Chris about the new CLI. I'll sure to bring up the idea of Studio dry runs so we all implement them in a similar way.
  8. Tony Lukasavage 2012-09-11

    Waiting til new CLI is implemented

JSON Source