Hi Tanya,

I too have few comments.

1. Can we add data access mode parameter to the provider config as well? So
there can be a parameter named "mode" which will have either "push" or
"pull" values.

2. Like Suhu mentioned, we can derive the list of providers by iterating
over specific FS directory.
3. Can we merge wizard steps 3 and 4 together? Then user may instantly see
the preview of a chart whenever he makes some chart configuration.

4. Like Suho mentioned, we'll have to pass the schemaPropertyList to the
chats index.js and generate the config.json.

Regards,
Dunith


On Fri, Apr 29, 2016 at 9:42 PM, Sriskandarajah Suhothayan <s...@wso2.com>
wrote:

> Please see the comments inline.
>
> On Fri, Apr 29, 2016 at 7:52 PM, Tanya Madurapperuma <ta...@wso2.com>
> wrote:
>
>> Hi all,
>>
>> *Introduction*
>>
>> The purpose of this feature is to provide a framework to generate gadgets
>> where you can plug datasource providers and chart templates.
>>
>> For an example, you will be able to plug your RDBMS datasource, rest api
>> , csv file , real time datsources etc as pluggable providers.
>>
>> *Flow*
>>
>> Select datasource provider (stage 1) --> Configure datasource parameters
>> (stage 2) --> Configure chart parameters (stage 3) --> Preview gadget
>> (stage 4) --> Generate gadget (stage 5)
>>
>> *Proposed Architecuture*
>>
>> Provider developers can plug their providers to DS by adding their
>> respective provider into the designer.json
>>
>> *{*
>> *    ............*
>> *    "gadgetGeneration" :{*
>> *        "isCreateGadgetEnable": false,*
>> *        "providers": ["batch", "rdbms", "rest", "rt"]*
>> *    },*
>> *   ................*
>> *}*
>>
>> Can't we load this dynamically by scanning the files at server start?
>
> Provider implementation should be placed under
>> /portal/extensions/providers and should mainly contain 2 files.
>>
>>    - config.json - contains the expected configuration in the "Configure
>>    datasource parameters" stage 2
>>
>>         *example config*
>> *           {*
>>
>> *    "id":"rdbms",*
>> *    "name" : "Relational Database Source",*
>> *    "image" : "",*
>> *    "config" : [*
>> *        {*
>> *            "fieldLabel" : "Database URL",*
>> *            "fieldName" :"db_url",*
>> *            "fieldType" : "text",*
>> *            "defaultValue" : "",*
>> *            "isRequired" : true*
>> *        },*
>> *        {*
>> *            "fieldLabel" : "Username",*
>> *            "fieldName" :"username",*
>> *            "fieldType" : "text",*
>> *            "defaultValue" : "",*
>> *            "isRequired" : true*
>> *        },*
>> *        {*
>> *            "fieldLabel" : "Password",*
>> *            "fieldName" :"password",*
>> *            "fieldType" : "password",*
>> *            "defaultValue" : "",*
>> *            "isRequired" : true*
>> *        },*
>> *        {*
>> *            "fieldLabel" : " Database Driver",*
>> *            "fieldName" :"driver",*
>> *            "fieldType" : "dropDown",*
>> *            "valueSet" : [ ],*
>> *            "isRequired" : true*
>> *        },*
>> *        {*
>> *            "fieldLabel" : " Check Box",*
>> *            "fieldName" :"checkbox",*
>> *            "fieldType" : "checkbox",*
>> *            "isRequired" : true*
>> *        },*
>> *        {*
>> *            "fieldType" : "advanced",*
>> *            "partialName" : "myPartial"*
>> *        }*
>> *    ]*
>> *} *
>>
>> The configuration UI will be dynamically generated for the data types
>> text-box, checkbox, password field and drop-down. And a provider can plug
>> his own UI blocks as partials when there are advanced fields.
>>
>>
>>    - index.js - implements the provider api for
>>       - validateData (providerConfig)
>>          - To validate the inputs provided at the stage 2
>>          - providerConfig will be key value pairs of provided field
>>          names and values
>>       - getSchema (providerConfig)
>>          - Returns the list of column names and their data types of the
>>          configured data provider
>>       - getData (providerConfig,schemaPropertyList)
>>          - schemaPropertyList  will be list of column names selected at
>>          stage 3
>>
>>
>> IMO the index.js should have a getConfigInfo() which will return the
> config.json which the UI will be plotted against, this is because for batch
> and realtime we have to pre populate the tables/stream.
> I think the validation of data can be part of getSchema()/generateSchema().
>
> Similarly chart templates can also be plugged via configuring at
>> designer.json
>> Chart template mplementations also goes under
>> /portal/extensions/chart-templates and have 2 main files.
>>
>>
>>    - config.json - contains the fields that needs to be populated at
>>    stage 3
>>
>>         *example config*
>>
>> *{*
>> *    "id":"lineChart",*
>> *    "name" : "Line Chart",*
>> *    "config": [*
>> *        {*
>> *            "fieldLabel": "X axis",*
>> *            "fieldName": "x",*
>> *            "fieldType": "String",*
>> *            "fieldValue" : ["$COLUMN_NAMES"]*
>> *        },*
>> *        {*
>> *            "fieldLabel": "Y axis",*
>> *            "fieldName": "y",*
>> *            "fieldType": "Int",*
>> *            "fieldValue" : ["$COLUMN_NAMES"]*
>> *        },*
>> *        {*
>> *            "fieldLabel": "Chart Colour",*
>> *            "fieldName": "colour",*
>> *            "fieldType": "String"*
>> *        }*
>> *    ]*
>>
>> *}*
>>
>> If the first element of field value is * ["$COLUMN_NAMES"]  *,it will
>> populate the list of column names retrieved getSchema method of provider
>> api.
>>
>>
>>    - index.js - implements the chart template api for
>>    - draw (chartConfig, data)
>>          - responsible for plotting the chart/gadget
>>          - chartConfig will be key value pairs of chart configurations
>>          provided at stage 3
>>          - data will be the actual data retrieved by calling getData
>>          method of provider api
>>
>>
>> Here too we have to pass the schemaPropertyList to the chats index.js and
> generate the config.json, because for different type of charts we should be
> able to generate appropriate chat configs based on the schema, and
> validation of chart input can be done at the draw().
>
>
>> Appreciate your input on the above approach.
>>
>> Thanks,
>> Tanya
>>
>> --
>> Tanya Madurapperuma
>>
>> Senior Software Engineer,
>> WSO2 Inc. : wso2.com
>> Mobile : +94718184439
>> Blog : http://tanyamadurapperuma.blogspot.com
>>
>
>
>
> --
>
> *S. Suhothayan*
> Technical Lead & Team Lead of WSO2 Complex Event Processor
> *WSO2 Inc. *http://wso2.com
> * <http://wso2.com/>*
> lean . enterprise . middleware
>
>
> *cell: (+94) 779 756 757 <%28%2B94%29%20779%20756%20757> | blog:
> http://suhothayan.blogspot.com/ <http://suhothayan.blogspot.com/>twitter:
> http://twitter.com/suhothayan <http://twitter.com/suhothayan> | linked-in:
> http://lk.linkedin.com/in/suhothayan <http://lk.linkedin.com/in/suhothayan>*
>



-- 
Regards,

Dunith Dhanushka,
Senior Software Engineer
WSO2 Inc,

Mobile - +94 71 8615744
Blog - dunithd.wordpress.com <http://blog.dunith.com>
Twitter - @dunithd <http://twitter.com/dunithd>
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to