Rethink the sink API, make it more fluent about cshell HOT 4 CLOSED

If your moving over to ScriptCS as your underlying runtime engine and planning in allowing CShell modules to be loaded via nuget maybe you would want to integrate them with ScriptCS modules/script packs.

This would allow developers to be able to simply extend and depend on those data renders when running in both ScriptCS at the commnad line and CShell.

On the command line the module might just dump to file system but when hosted in CShell it would open in a tab and display the data.

from cshell.

@tocsoft, I do like that idea. I'm looking into ScriptCs modules right now. Where are they normally installed? Are in the install dir of ScriptCS itslef?

I've been thinking for a while how to allow scripts to run on command line. I like the idea of sinks supporting writing their output to the file system instead of opening a tab. For some sinks this might be a bit hard to do. But it could be optional for a sink developer to support command line execution.

from cshell.

disclaimer: no expert on scriptcs

Believe they are designed to be loaded up from Nuget packages and normally scriptcs handles loading them all in and registering themselves into its pipeline.

How I would approach it would be provide a series of script packs for the sinks.

Each script pack could expose its own set of extension methods and they all take a dependency on ISink and allow the runtime to provide the implementation (allowing you to swap it out when hosted in CShell).

The Api could look something as simple as;

interface ISink
{
    /// <remarks> 
    /// data must implement one of 
    /// ISinkDataFileSave or ISinkDataUIControl
    /// </remarks>
    bool Display(ISinkData data);
}

interface ISinkData 
{
    string Name { get; }
}

interface ISinkDataFileSave : ISinkData
{
    string FileExtension { get; }
    void Save(Stream streamToSaveto);
}

interface ISinkDataUIControl : ISinkData
{
    void Render(UIControl controlToAppendTo);
}

This allows each sink to be pretty much standalone.

And giving them the power to optionally render to screen or file system. (screen being a noop on the command line or it could write a text file using a well known pattern telling the user that it needs to be run from cshell to access this output).

Additionally sink extension methods should (by conventions) should always require a name to be provided (to be used as either the tab name and/or the file name).

from cshell.

I moved the sinks to external modules, and simplified the sink API substantially.

Basically it boils down to:
ISink Implmentation
Some static extension methods for syntactic sugar.

See the sink projects.

from cshell.