startnine / start9-api Goto Github PK

The entry should not hold state about the object; we should retrieve up-to-date information as we go

As described by this MSDN article,

Typically, organizations that develop host applications will also develop an SDK that describes the object model for add-in developers to program against. This SDK will include the add-in view assembly that contains the abstract base class or interface that the add-in must implement, as well as abstract base classes and interfaces that represent the types that are passed between the host and the add-in. this work can also include building the complete pipeline.

So why are we setting the example of copying everything into the solution, customizing the namespaces, setting the build paths, etc.? It's time consuming (for people that can't use our e:b:ic template that would eventually exist, that is), prone to (human) error, and gives module developers an obligation to understand MAF, which is a huge rabbit hole that 99% of module developers are better off not understanding (the only reason I could see it being useful is if you want to change the views and adapters, which is a really geeky thing to want to do anyway). We should just follow that MSDN article and publish a nuget package people can reference and do whatever with

Kinda need this for loading config

I have no excuse for this one

Realized that I'm a bit of a dum and we don't need a GetConfiguration but we do need a SetConfiguration

Help

• Force all IConfigurationContract implementers to be INotifyPropertyChanged (it might be a bit of a hassle to get the pipeline generator to work with INPC itself so we might just add an event instead)
• Remove IConfigurationContract.Entries; we will use reflection to accomplish the same purpose
• Remove IHostContract.SaveConfiguration(IModuleContract) since config will be saved when the PropertyChanged event is raised
• Add IListContract<IConfigurationEntry> IHostContract.GetConfigurationEntries(IConfiguration)- This will transform the reflected-over properties/fields on the object into a collection of IConfigurationEntry and fill in extra properties on each entry with information obtained by attributes placed on the reflected-over properties/fields like DisplayAttribute, DescriptionAttribute, and CategoryAttribute (actual attributes we will use will be decided later).
• Add aforementioned metadata properties to, not only IConfigurationEntry, but other contract entries as well.

Any module that is activatable should already be initialized. Only disabled modules will have uninitialized instances

This will correspond to the already existing IMessageContract.MessageObjectType. This way we can have upfront validation to confirm if the node connection will work

IMessageContract.Text was included to allow developers to provide additional information attached to the object of the message. However, in hindsight, the practical uses of such a property are limited - if you need to send text, you can always make the object of the message a string - and it'll only further slow down the pipeline. Do we really need to include it in the contract?

The only contract that currently represents a module, which is also the add-in contract, only represents an individual instance of a module and its functionality. A contract that represents an actual module assembly, its intances, and its properties needs to be added to the assembly. Something similar to Start9.Host.Module's functionality

Modules can (preferably) return a FrameworkElement from this method that we will display inline in the host application, or null. If modules return null, they are expected to use their own mechanism to display their own configuration - for example, navigating to a new page inside their module's UI.

On a side note, this could raise dangerous stability concerns for us - modules normally shouldn't be able to bring down the host application, but running add-in code in the host process could end up doing that. We'll have to investigate preventative measures.

IModuleAssemblyContract was kinda made for this purpose