Hi Dunith,
On Mon, May 2, 2016 at 6:54 AM, Dunith Dhanushka <dun...@wso2.com> wrote:
> 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"
>
IMO gadget creator doesn't need the flexibility to decide the mode, hence
we don't need to provide mode as a provider config element. Rather we can
have a method in the index.js of provider as getMode().
But provider can add the poll interval to the provider config if he allows
user to configure it.
> 2. Like Suhu mentioned, we can derive the list of providers by iterating
> over specific FS directory.
>
Please see my comment for Suho's mail.
> 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.
>
+1
>
> 4. Like Suho mentioned, we'll have to pass the schemaPropertyList to the
> chats index.js and generate the config.json.
>
+1
>
> Regards,
> Dunith
>
> Thanks,
Tanya
>
> 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>
>
--
Tanya Madurapperuma
Senior Software Engineer,
WSO2 Inc. : wso2.com
Mobile : +94718184439
Blog : http://tanyamadurapperuma.blogspot.com
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
