Views

I'm working on creating a visitor pattern toolkit. I'm looking at creating one view per project to manage all the node classes in that project. Is that a reasonable way to use Views? Also, if I run CreateView in an Execute() method of a command, will the
view be added to Views to be used later in the Execute method?

In terms of design, a 'view' is really meant to represent a separate 'aspect' or viewpoint that you want to give to your users about how the elements in your toolkit are displayed/operated.

We designed this feature to accommodate the cases where toolkit builders might found value in providing a different set of elements to focus the toolkit users workflow in different areas of concern. Probably only valuable to toolkit builders who provide medium
to large sized toolkits.
For example, if you built a toolkit for building custom web services, you might want to have one view for designing the 'contract' of the web service, and a different view focused on the 'security' options of that service and its endpoints, and perhaps another
focused on 'deployment' host options for that service.

As a toolkit builder 'vies' gives you that kind of option. But, you also have the option to put all that info in the single (default) view and have top level elements to represent those viewpoints beneath them as well. The choice is the toolkit builders.

The intention was to have these views defined statically (at design time) in the patternmodel. Adding them dynamically may not have been intentional. I am not even sure if that would work, but perhaps it does. If it did, then the answer to your question would
be yes, you should have them all in memory to work with in the 'Execute' method.
But I suspect when you call CreateView, you would need to tell the api which view to create - no? and therefore if you don't have it already statically defined in the schema of your toolkit (i.e. in the patternmodel) it could not be actually instantiated.

Now that we are talking about this API method, I think the CreateView() API is simply there for completeness of the toolkit pattern model element, but we should probably find a way to remove it, since I don't think we intend anyone to call it from automation.