I have a yeoman generator with some subgenerators.
I know I can pass options from the parent- to the subgenerators when calling composeWith(...).
But how can I pass the answers I get from prompting? The are not available at the point when composeWith is called.
For example I prompt in the generator for an app name and want to provide this to all the subgenerators as options?
One way to do this is using the built-in config.
In the "parent" generator:
configuring(){
this.log('Saving configuration in .yo-rc.json')
const answers = this.answers.answers()
for(const key in answers){
this.config.set(key, answers[key])
}
this.config.save()
}
In the "child" generator, to populate templates:
const templateData = {
...this.config.getAll(),
...
}
this.fs.copyTpl(
this.templatePath(),
this.destinationPath(),
templateData
)
This should be simple enough to change for your use case, eg perhaps you'd want this.config.get(something) in the child generator.
Just note this won't work across different generators; only between a generator and its own sub-generators:
The .yo-rc.json file is a JSON file where configuration objects from multiple generators are stored. Each generator configuration is namespaced to ensure no naming conflicts occur between generators.
This also means each generator configuration is sandboxed and can only be shared between sub-generators. You cannot share configurations between different generators using the storage API. Use options and arguments during invocation to share data between different generators.
Oh, found in the related questions that I could call the subgenerator after prompting, instead of the initialize-method (as in the quite outdated tutorial)
Related
I have rule A implemented with a macro that uses declare_directory to produce a set of files:
output = ctx.actions.declare_directory("selected")
Names of those files are not known in advance. The implementation returns the directory created by declare_directory with the following:
return DefaultInfo(
files = depset([output]),
)
Rule A is included in "srcs" attribute of rule B. Rule B is also implemented with a macro. Unfortunately the list of files passed to B implementation through "srcs" attribute only contains the "selected" directory created by rule A instead of files residing in that directory.
I know that Args class supports expansion of directories so I could pass names of all files in "selected" directory to a single action. What I need, however, is a separate action for every individual file for parallelism and caching. What is the best way to achieve that?
This is one of the intended use cases of directory outputs (called TreeArtifacts in the implementation), and it's implemented using ActionTemplate:
https://github.com/bazelbuild/bazel/blob/c2100ad420618bb53754508da806b5624209d9be/src/main/java/com/google/devtools/build/lib/actions/ActionTemplate.java#L24-L57
However, this is not exposed to Starlark, and has only a couple usages currently, in the Android rules AndroidBinary.java and C++ rules CcCompilationHelper.java. The Android rules and C++ rules are going to be migrated over to Starlark, so this functionality might eventually be made available in Starlark, but I'm not sure of any concrete timelines. It would probably be good to file a feature request on Github.
I have developed a rest-api client (in java) customised to the needs of my product. I wanted to generate tests using my rest api client using swagger-codegen modules based on yaml-file.
I have already extended DefaultCodegenConfig & even tried implementing the CodegenConfig interface to build my custom jar. I have customized the api.mustache and api_test.mustache files and passing them in the constructor and processOpts() method of my CustomCodeGen that extends DefaultCodegenConfig.
However, I want to use the custom/new mustache template variables that I have added in my customised api.mustache.
For e.g. if refer to standard api.mustache, the template variables it typically uses are
- {{classname}}
- {{#operation}}
- {{#contents}}
- {{#parameters}}
etc.
Now, I want to introduce a new template variable, let's say {{custom_param}}. Now I am not clear how do I integrate this new template variable with the implementation.
Looks like from this Mustache-Template-Variables published here, swagger-codegen does not allow adding new template-variables and perhaps we are restricted to only the variables mentioned on this page.
So, is there some way to make the new template variables work ?
Some time ago I added the uniqueItems parameter for bean validation as it was not getting processed by the engine even though it was a part of the implemented JSR.
So I believe codebase needs to be updated to use your own variable which is only possible if you fork the code.
In case it helps, these two were the PRs:
For query parameters: https://github.com/swagger-api/swagger-codegen/pull/10154.
For body parameters: https://github.com/swagger-api/swagger-codegen/pull/10490.
So just to give you some context, I'm trying to create a generator that will create some files (based on user input of course) as well as update some existing files in the project (like adding a new route for example).
Creating the files using this.template is no problem... the question is: is there any way to do this with Yeoman without having to read the file using Node and doing some fanciful find and replace?
Ok, so I found the answer to my question.
Addy Osmani showed me where to look in this thread on twitter, and then I later found this link which shows exactly what I need.
The gist of it boils down to two functions : readFileAsString and write. Usage is as follows:
var path = "/path/to/file.html",
file = this.readFileAsString(path);
/* make modifications to the file string here */
this.write(path, file);
Edit: I've also blogged about this on my blog.
EDIT 1
As mentionned in comments by Toilal :
The write method doesn't exists anymore, and must be replaced by writeFileFromString (arguments are also reversed) – Toilal
EDIT 2
And then, as mentionned in comments by ivoba:
this.writeFileFromString & this.readFileAsString are deprecated, github.com/yeoman/html-wiring should be used by now, things change :) – ivoba
Yeoman also provides a more elegant way of fs operations using mem-fs-editor.
You can use this.fs.copy, passing a process function as an option to do any modifications to the content:
this.fs.copy(path, newPath, {
process: function(content) {
/* Any modification goes here. Note that contents is a Buffer object */
var regEx = new RegExp('old string', 'g');
var newContent = content.toString().replace(regEx, 'new string');
return newContent;
}
});
This way you can also take advantage of mem-fs-editor features.
In combination with #sepans' excellent answer, instead of using regular expressions, one can use some parser.
From Yeoman documentation:
Tip: Update existing file's content
Updating a pre-existing file is not always a simple task. The most reliable way to do so is to parse the file AST and edit it. The main issue with this solution is that editing an AST can be verbose and a bit hard to grasp.
Some popular AST parsers are:
Cheerio for parsing HTML.
Esprima for parsing JavaScript - you might be interested in AST-Query which provide a lower level API to edit Esprima syntax tree.
For JSON files, you can use the native JSON object methods.
Parsing a code file with RegEx is perilous path, and before doing so, you should read this CS anthropological answers and grasp the flaws of RegEx parsing. If you do choose to edit existing files using RegEx rather than AST tree, please be careful and provide complete unit tests. - Please please, don't break your users' code.
More specifically, when using esprima you will most probably require also some generator such as escodegen to generate js back.
var templatePath = this.destinationPath(...);
this.fs.copy(templatePath, templatePath, {
process: function (content) {
// here use the parser
return ...
}
});
Note that you can use the same path in from, to arguments in order to replace the existing file.
On the other hand, the downside of such parsers is that in some cases it may alter the original file way too much, and although safe, this is more intrusive.
Use var text = this.fs.read(filePath) to read from a file and this.fs.write(filePath, content) to write to a file at location.
You can use the mem-fs-editor, and call the fs.append(filepath, contents, [options]) method.
e.g.
this.fs.append(this.contextRoot + "/index.html", " <p>Appended text</p>");
I'm currently writing some functions that are related to lists that I could possibly be reused.
My question is:
Are there any conventions or best practices for organizing such functions?
To frame this question, I would ideally like to "extend" the existing lists module such that I'm calling my new function the following way: lists:my_funcion(). At the moment I have lists_extensions:my_function(). Is there anyway to do this?
I read about erlang packages and that they are essentially namespaces in Erlang. Is it possible to define a new namespace for Lists with new Lists functions?
Note that I'm not looking to fork and change the standard lists module, but to find a way to define new functions in a new module also called Lists, but avoid the consequent naming collisions by using some kind namespacing scheme.
Any advice or references would be appreciated.
Cheers.
To frame this question, I would ideally like to "extend" the existing lists module such that I'm calling my new function the following way: lists:my_funcion(). At the moment I have lists_extensions:my_function(). Is there anyway to do this?
No, so far as I know.
I read about erlang packages and that they are essentially namespaces in Erlang. Is it possible to define a new namespace for Lists with new Lists functions?
They are experimental and not generally used. You could have a module called lists in a different namespace, but you would have trouble calling functions from the standard module in this namespace.
I give you reasons why not to use lists:your_function() and instead use lists_extension:your_function():
Generally, the Erlang/OTP Design Guidelines state that each "Application" -- libraries are also an application -- contains modules. Now you can ask the system what application did introduce a specific module? This system would break when modules are fragmented.
However, I do understand why you would want a lists:your_function/N:
It's easier to use for the author of your_function, because he needs the your_function(...) a lot when working with []. When another Erlang programmer -- who knows the stdlb -- reads this code, he will not know what it does. This is confusing.
It looks more concise than lists_extension:your_function/N. That's a matter of taste.
I think this method would work on any distro:
You can make an application that automatically rewrites the core erlang modules of whichever distribution is running. Append your custom functions to the core modules and recompile them before compiling and running your own application that calls the custom functions. This doesn't require a custom distribution. Just some careful planning and use of the file tools and BIFs for compiling and loading.
* You want to make sure you don't append your functions every time. Once you rewrite the file, it will be permanent unless the user replaces the file later. Could use a check with module_info to confirm of your custom functions exist to decide if you need to run the extension writer.
Pseudo Example:
lists_funs() -> ["myFun() -> <<"things to do">>."].
extend_lists() ->
{ok, Io} = file:open(?LISTS_MODULE_PATH, [append]),
lists:foreach(fun(Fun) -> io:format(Io,"~s~n",[Fun]) end, lists_funs()),
file:close(Io),
c(?LISTS_MODULE_PATH).
* You may want to keep copies of the original modules to restore if the compiler fails that way you don't have to do anything heavy if you make a mistake in your list of functions and also use as source anytime you want to rewrite the module to extend it with more functions.
* You could use a list_extension module to keep all of the logic for your functions and just pass the functions to list in this function using funName(Args) -> lists_extension:funName(Args).
* You could also make an override system that searches for existing functions and rewrites them in a similar way but it is more complicated.
I'm sure there are plenty of ways to improve and optimize this method. I use something similar to update some of my own modules at runtime, so I don't see any reason it wouldn't work on core modules also.
i guess what you want to do is to have some of your functions accessible from the lists module. It is good that you would want to convert commonly used code into a library.
one way to do this is to test your functions well, and if their are fine, you copy the functions, paste them in the lists.erl module (WARNING: Ensure you do not overwrite existing functions, just paste at the end of the file). this file can be found in the path $ERLANG_INSTALLATION_FOLDER/lib/stdlib-{$VERSION}/src/lists.erl. Make sure that you add your functions among those exported in the lists module (in the -export([your_function/1,.....])), to make them accessible from other modules. Save the file.
Once you have done this, we need to recompile the lists module. You could use an EmakeFile. The contents of this file would be as follows:
{"src/*", [verbose,report,strict_record_tests,warn_obsolete_guard,{outdir, "ebin"}]}.
Copy that text into a file called EmakeFile. Put this file in the path: $ERLANG_INSTALLATION_FOLDER/lib/stdlib-{$VERSION}/EmakeFile.
Once this is done, go and open an erlang shell and let its pwd(), the current working directory be the path in which the EmakeFile is, i.e. $ERLANG_INSTALLATION_FOLDER/lib/stdlib-{$VERSION}/.
Call the function: make:all() in the shell and you will see that the module lists is recompiled. Close the shell.
Once you open a new erlang shell, and assuming you exported you functions in the lists module, they will be running the way you want, right in the lists module.
Erlang being open source allows us to add functionality, recompile and reload the libraries. This should do what you want, success.
What is the best way to put custom library or helper methods in symfony?
I am using doctrine with my project. One place I consider to put is under project_root/lib/vendor/MyClasses/
But if I want to create a class or helper function which will use some core symfony/doctrine methods and return a result then how to do that and where should I put it?
I want it to call from different modules to avoid code duplication.
As for the custom library part of the question, you might probably want to put your external library into the lib/vendor folder. Since symfony doesn't automatically load everything that's in there, you'll have to tell its autoloader to do so.
You can either extend your config/ProjectConfiguration.class.php (as described here) or (and this is the much simpler and cleaner way) you add them to your config/autoload.yml (you might have to create this one).
For the latter option, this is a great place to start looking at.
It seems to be a duplicate question.
As asked in symfony's 1.2 "Definitive Guide" docs :
Helper functions (regular PHP functions returning HTML code) should be saved in a file called FooBarHelper.php, where FooBar is the name of the helper group. Store the file in the apps/myapp/lib/helper/ directory (or in any helper/ directory created under one of the lib/ folders of your project) so it can be found automatically by the use_helper('FooBar') helper for inclusion.
So, if you want to create custom helper FooBar for foo() function, create file lib/helper/FooBarHelper.php :
function foo() {echo "foo!"; }
to use it in your template:
use_helper('FooBar')
....
foo(); //outs "foo!"