Feature Request: Templates or Settings

[still-dreaming-1]

When generating things, it would be nice if there was either a template file we could edit or some settings to customize what gets generated. Let's say a template was used. The default templates could already contain the necessary code to generate things intelligently like what currently happens. But that would give us the option to say, add "final" before "class". This would also allow us to pick a different style for the code, like placing the curly brace immediately following the class name instead of on a the next line. This would also make it possible to do things like, enable strict_types, or add a constructor.

Alternatively, these could be turned into options for the extension. This would be more user friendly, but less flexible.

There are already other templating solutions out there for VS Code, but I'm not aware of any that honor the PSR-4 settings from the composer.json file.

[damian-bal]

Nice idea, but I would need to think about what would be the best way to implement so it's easy to use and doesn't make it cumbersome to use.

[still-dreaming-1]

I think a good place to start would be a template file that is mostly WYSIWYG. What your extension provides that does not seem to exist elsewhere is the correct name of the namespace based on the user's composer.json PSR-4 settings. That part could be assigned to a variable that is referenced in the template. So it could ship with one template file that is the default version of the template. Then if the user wants to edit the template, it could create a copy of this file for the user to edit, in a user wide area. They could alternatively create a workspace specific template, which would be copied to a different location for them to edit. By separating the template in these three ways, updates to the extension could still update the default template, without changing the users template or workspace template.

While the template should be mostly WYSIWYG, the way it achieves that could open up further options. I think the template should be some JavaScript code that returns a string, and the content's of that string are what appear in the generated class. This way, it would still be mostly WYSIWYG because most users would just edit the contents of the string directly, seeing what they will get. But people using VS Code are programmers, and so they will appreciate and be capable of using the power a programming language to generate whatever code they want.

I think without this features your extension is only going to be helpful to a very specific kind of user, one that doesn't use strict_types very often or have any other things they want to have in most of their class files.

I don't see any of this creating a burden on the user because they don't actually need to use the feature at all. If they don't customize the template, it will work exactly as it does now.

[lud]

I second this proposal !

I need the generator to add declare(strict_types=1); to inserted classes and I do not know how to do it.

[damian-bal]

I will work on adding that feature 👍 it would be an option in settings for that extension, something like "Include strict types: true/false", or should it be asked when generating class? not sure what will be best.

[still-dreaming-1]

That is one of the things I wanted to use the template idea for as well, but I also wanted a list of classes that would be use included at the top, and for my classes to start out final. If you are still not willing to add that feature, I think a setting would be better than asking a question. Part of the point of this extension is to be able to move quickly and without friction, possibly activating it from a keyboard shortcut, so if I have to answer a question every time, I would get frustrated. I think most people that care about and use strict types and want to use them will want to use them for every new file they create. In the rare case where you have an exceptional file, having to delete that line from the code would not be a big deal. I also think many PHP programmers don't know what strict types is and might be annoyed by the question for that reason, or if they just don't want to use it they don't want to be asked every time. If it is a setting (or a template), they can explore and learn about that if and when they want to do that, but it is not a barrier to entry for using this extension. Also, if you ask it as a question, where does that end? Strict types is only one thing people may want. Eventually someone might ask for another optional thing, and then it would have to ask 2 questions, so a setting would be better. Also, I don't see how a settings file for this would be easier to use than a WYSIWYG like template file that is pre-filled in with the default. That would satisfy the strict types request and other future requests people have.

[damian-bal]

I agree, looks like template would be best option, and it could be enabled via settings, something like "Use custom template". On other hand best option would be to use checkboxes to check for "final", "strict types", etc... but VS code doesn't support them yet when using dialogs.

[lud]

You could go with two entries in the menu (in addition of trait/interface)

• class (defaults)
• class (wizard)

Defaults would generate a class based on settings (to enable strict types), or if a template is declared in the settings then it will jsut use the template as is. Wizard would ask final?, abstract?, strict-types? sequentially

That does not allow to use template AND questions but is "good enough".

[damian-bal]

@lud yeah, that's not a bad idea, and it would be easy to implement as well, thanks 👍

[still-dreaming-1]

This is still closed for some reason. If a template is too much to implement, having a few settings would go a long way. One setting could be a checkbox to add a strict_types declaration. Another setting could be a list of types to "use" at the top of each file. Also a checkbox for classes to be final would be very helpful.