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