Do not post any licensing information in this forum.
another day in feature-request valley, though this one is a bit more expansive than usual.
Basically, I think that the module projects could use some serious upgrades, which is why I've gathered some ideas on how to make it better:
The tale of file based development
When I create a Module Project in the current day PSS, I create a folder and can put in ps1 files, as well as edit the psm1 and psd1 files. I can also move them into new subfolders.
Basically, the project is similar to a restricted explorer view and I seriously question, whether that is how it needs to be. Rather, I'd like to refocus it on the content that will be provided by the module, rather than its files.
Now what does this mean?
A module project no longer consists of files and folders. Rather it has a wider collection of content-elements:
- Function Help
- Help Topic Articles
- C# Code
- C# Libraries
Scripts are generic pieces of PowerShell code that is run when importing the module.
Validations are special scriptblocks, that return $true or $false. They can be used as a prerequisite for each content element (including other validations). A content element may have multiple validations set.
Example: Add a validation script to check whether the preference variable $global:DontAddAliases is $true. Attach this to the aliases defined. So if a user has this variable set to $true the module will not load (and export) the Aliases it usually would and have this validation configured.
Plain old functions.
If the user has a HelpWriter license, he can - directly from PSS - add help for any function in the module using the Help Writer.
The Module may define and export Aliases, including preconfigured alias-options.
Variables can be exported as well. However, as content they have a name, scope options and a scriptblock the user can fill in, the return value of which will be stored in the variable.
Help Topic Articles
Users may directly embed help topic articles (as called by Get-Help about_example_topic).
C# Source code scripts can be configured, with prerequisite assemblies that need to be loaded and referenced assemblies, whose location needs to be added to the Add-Type call.
Precompiled C# Libraries may be embeded, allowing for multiple versions (32bit / 64bit x .NET3.5 / .NET4.5), the correct one being automatically selected on module load.
Module Meta Information
The current .psd file can be edited directly. Wouldn't a simple edit form, similar to the PSS options menu, be simpler to edit? Maybe with a "view base file" option if that is actually necessary.
The Load Order
All content entities are loaded at some point (assuming all validations are met). However, the load order may matter. Thus we'd need a way, to choose import order. Provide a simple default order, example:
- C# Libraries
- C# Code
If the default doesn't work for the developer, s/he should have the option to manually choose the order. Example:
- Script: Prevalidation
- Function: Test-TestConnection
- Script: Preload
- C# Libraries
- C# Code
- Script: Post-Import
In this example, First the script named Prevalidation is run, then the function Test-TestConnection is run, then come all the validations. Following that, the Preload script executes, followed by C# Libraries and Code. Then all functions except Test-TestConnection (which already has been loaded) are imported, followed by all aliases, all scripts except for the specifically mentioned ones (Prevalidation, Preload & Post-Import), all variables and finally the Post-Import script.
The module can be configured for what language it should be localized in. A validation is available, that tells which help & about_ help topic haven't yet been localized in all supported languages (and what part is missing).
A nice dream I think, this certainly would change the way modules are written, and all within a single editor. On the other hand, such a ... exhaustive overhaul isn't just going to appear in the next service release with the snap of a finger.
So no, I don't expect this anytime soon, but I sure like the idea (which is why I spent the time to write this down).
Any comments, refinements or opinions?
I will bring this up with the team. As always, thank you for your feedback!
SAPIEN Technologies, Inc.
Yes. At least where modules are concerned. Modules are all about providing a capability, about providing resources and tools for the user. This places them in stark contrast to individual script files, whose purpose is to execute a specific action.davidc wrote:Essentially do don't want to worry about files and instead focus on business logic and workflow. Is that correct?
At the moment, both are handled mostly the same way by any editing tool you care to name. I believe that having the editing tool to focus upon those resources and tools, rather than on how they are stored is more efficient, effective and ultimately more intuitive for users.
Cheers, and as always, thanks for working steadily at improving my own efficiency through better tools
Who is online
Users browsing this forum: No registered users and 1 guest