Yes that is the general idea. The profile needs to be created via either a profile name or path. I think the $ffprofile class should be workable on its own without a cmdlet to assist. One to assit with creating the profile is
probably helpful. At the minimum adding the argument and setting the arguments Help to include a reference to the namespace to create the profile itself is needed. In general I only create cmdlets for abstracting New-Object if it inlcudes more
than just the New-Object, such as adding members or creating prereequisit class like office (outlook, excel, word) application types.
- I think setting an existing profile is an edge case in QA (at least from feedback I have seen in forums discussing Selenium).
- Anyone needing to do more then setting to an existing profile is going to need to work with the class. Abstracting these functions to cmdlets could be a module voume of developement alone.
I am still in the evaluation stages of using Selenium. We had started using WATIN, but that seems to be a bit abandoned especially for cross browser work. If you didn't have this PS module going, I would have been substantially slowed down.
As we explore functionality, I will make sure to send you any feedback we have.
I don't know if you have this, but this is how I have seen to open a FF profile by name. I have actually not had proper luck opening default profiles, but I have not had an opertunity to dig into it. As is we made a non-default for the automation
account and this seems to work.
$profileManager = new-object OpenQA.Selenium.Firefox.FirefoxProfileManager
$profile = $profileManager.GetProfile('default')