Hi all,
We had a discussion again regarding this and please find the modified notes
below.
Provider api (index.js) needs to implement the following functions.
- validate(providerConfig)
- same as described before - is to validate the user input for
provider configuration
- getConfig()
- This will require the existing config.json and push any dynamic fields
that needs to be populated in the UI. If not will return the
config.json as
it is.
- getMode()
- This will return whether the data provider supports polling or pushing
- getSchema(providerConfig)
- This will take user filled in provider configuration and return all
the column names and all column types
- getData(providerConfig, schema, limit)
- schema - will take the full table schema returned from getSchema
method
- limit is to get the number of records required
- registerCallBackforPush(providerConfig, schema)
- used when the mode is push
Chart api (index.js) will also have a similar set of functions to provider
api.
- getConfig(schema)
- will take the schema returned from getSchema function of provider api
and return the config to be populated in the chart configuration UI
- validate(chartConfig)
- similar to provider api, will validate the user input for chart
configuration
- isProviderRequired()
- To be used provider configs need to be skipped in the generation
framework
- draw (chartConfig, schema, data)
- Return the gadget content
- update(data)
@ Manu : +1 for fetching from FS by default and to have ignore list in the
config.
Thanks,
Tanya
On Mon, May 2, 2016 at 10:06 AM, Tanya Madurapperuma <ta...@wso2.com> wrote:
> 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
>
--
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
