Re: [Architecture] Modification of the gadget generation wizard's extension structure

[Tanya Madurapperuma]

Hi Sajith,

Thank you for your reply. Please find my responses inline.

On Mon, Jun 13, 2016 at 1:26 AM, SajithAR Ariyarathna 
wrote:

> Hi Tanya,
>
> I like to express few suggestions regarding the gadget structure.
>
> *Generated gadget structure*
>>
>> └── test_gadget
>> ├── conf.json
>> ├── gadget-controller.jag
>> ├── gadget.json
>> ├── index.png
>> ├── index.xml
>> ├── libs
>> │   └── vendorName_version
>> │   └── [ js_css_images_etc_as_same_as_vendor_ships ]
>> ├── css
>> │   └── line-chart.css
>> └── js
>> ├── core
>> │   ├── gadget-core.js
>> │   ├── line-chart-api.js
>> │   └── provider-api.js
>> └── line-chart.js
>>
>
> Self-descriptive names.
>
> File names should reflect their role, task & purpose in the gadget. It
> makes the learning curve very short & easy for a new comer (support dev).
> For example; "conf.json" clearly indicates that it is a configuration file.
> In contrast "index.png", "index.xml" are not good descriptive name. IMO
> their names should be changed to be more descriptive.
>
> +1 We can rename index.png to thumbnail.png and index.xml to gadget.xml to
reflect their functionality.


> Less generic names & more unique names.
>
> Files with generic names can impair the developer experience. For example;
> if the developers has opened 10 gadgets in his IDE project, then there will
> be 10 "gadget-controller.jag" files. Working with 10 files that has the
> same name is a tedious task. Instead of generic "gadget-controller.jag"
> name, we can use a unique name like "-controller.jag". With
> that name, 10 gadgets will have controller JAGs with 10 different names.
>
> -1 Apart from common third party libraries, gadget is a self contained
entity. So all the files that require for a particular gadget to render is
inside its  folder. So IMO renaming gadget-controller.jag file
is unnecessary as it clearly reflects the usage of the file.

> Clear separation between configuration files, executing files (server-side
> & client-side), & resources.
>
> In the above gadget structure, both "index.png" (a resource) &
> "gadget-controller.jag" (a server-side executable) files reside in the same
> directory. Directory structure doesn't separate them clearly. I like to
> propose a structure like this,
>
> └── test_gadget
>
> ├── conf*<-- configuration files in here*
> ├── server *<-- server side files*
> └── client   *<-- clent-side files*
>   ├── js
>|   └── core
>   ├── css
>   └── libs
>
> -1 IMO your point is valid for an entity like an application where there
are number of files which we need to identify as server side and client
side. But a gadget is a very light weight entity and IMO introducing client
side and server side separation for a gadget is making simple things
complex.

Thanks,
Tanya

>
> Thanks.
>
> On Thu, Jun 9, 2016 at 4:38 PM, Sinthuja Ragendran 
> wrote:
>
>> Hi Manu,
>>
>> On Wed, Jun 8, 2016 at 8:40 PM, Manuranga Perera  wrote:
>>
>>> 1) We had a chat about how we can use gadget parameters instead of
> generation, have you guys considered that approach?
>
> We have cases like database credentials which should not be shown to
 the user and should not be editable from the gadget properties. Further we
 also need a model that gadget should be greeted by some privileged user and
 used by others, so the gadget generation is the appropriate model to handle
 this.

>>>  I thought we can come up with a way to attach permissions to the
>>> params, so they can be hidden depending on the user. (this will help us
>>> generally not just for gadget gen case)
>>>
>>
>> Yeah, initially i also thought we can go with such an approach. But then
>> there are some dynamic params that you need to populate based on the
>> previous selection that you have done. Ie, for example if it's batch
>> data/realtime/rdbms then the form params that you need to display is
>> different for each. If we are going to have such capabilities then it's
>> equal to have wizard apporach, and I don't really see much difference.
>>
>> Anyhow our objective was to create a framework, where you can plug any
>> data providers and chart types easily and generate the gadget. With this we
>> also have removed the dependency of analytics gadget generation part from
>> the carbon-dashboards repo, and people can have their own providers and
>> chart types, in their repo and they can include that in the build time to
>> get only into their product.
>>
>> Thanks,
>> Sinthuja.
>>
>> Edit/ Re-generate function is not supported yet.
>
> 2) The issues is, with this model it will be harder to support that
> even in the future. At least we should serialize all the parameters with
> the generated gadget.
>
 Editing is something we can achieve with very little effort, if we
 store all the properties that we have passed i

Re: [Architecture] Modification of the gadget generation wizard's extension structure

[SajithAR Ariyarathna]

Hi Tanya,

I like to express few suggestions regarding the gadget structure.

*Generated gadget structure*
>
> └── test_gadget
> ├── conf.json
> ├── gadget-controller.jag
> ├── gadget.json
> ├── index.png
> ├── index.xml
> ├── libs
> │   └── vendorName_version
> │   └── [ js_css_images_etc_as_same_as_vendor_ships ]
> ├── css
> │   └── line-chart.css
> └── js
> ├── core
> │   ├── gadget-core.js
> │   ├── line-chart-api.js
> │   └── provider-api.js
> └── line-chart.js
>

Self-descriptive names.

File names should reflect their role, task & purpose in the gadget. It
makes the learning curve very short & easy for a new comer (support dev).
For example; "conf.json" clearly indicates that it is a configuration file.
In contrast "index.png", "index.xml" are not good descriptive name. IMO
their names should be changed to be more descriptive.

Less generic names & more unique names.

Files with generic names can impair the developer experience. For example;
if the developers has opened 10 gadgets in his IDE project, then there will
be 10 "gadget-controller.jag" files. Working with 10 files that has the
same name is a tedious task. Instead of generic "gadget-controller.jag"
name, we can use a unique name like "-controller.jag". With
that name, 10 gadgets will have controller JAGs with 10 different names.


Clear separation between configuration files, executing files (server-side
& client-side), & resources.

In the above gadget structure, both "index.png" (a resource) &
"gadget-controller.jag" (a server-side executable) files reside in the same
directory. Directory structure doesn't separate them clearly. I like to
propose a structure like this,

└── test_gadget

├── conf*<-- configuration files in here*
├── server *<-- server side files*
└── client   *<-- clent-side files*
  ├── js
   |   └── core
  ├── css
  └── libs


Thanks.

On Thu, Jun 9, 2016 at 4:38 PM, Sinthuja Ragendran 
wrote:

> Hi Manu,
>
> On Wed, Jun 8, 2016 at 8:40 PM, Manuranga Perera  wrote:
>
>> 1) We had a chat about how we can use gadget parameters instead of
 generation, have you guys considered that approach?

 We have cases like database credentials which should not be shown to
>>> the user and should not be editable from the gadget properties. Further we
>>> also need a model that gadget should be greeted by some privileged user and
>>> used by others, so the gadget generation is the appropriate model to handle
>>> this.
>>>
>>  I thought we can come up with a way to attach permissions to the params,
>> so they can be hidden depending on the user. (this will help us generally
>> not just for gadget gen case)
>>
>
> Yeah, initially i also thought we can go with such an approach. But then
> there are some dynamic params that you need to populate based on the
> previous selection that you have done. Ie, for example if it's batch
> data/realtime/rdbms then the form params that you need to display is
> different for each. If we are going to have such capabilities then it's
> equal to have wizard apporach, and I don't really see much difference.
>
> Anyhow our objective was to create a framework, where you can plug any
> data providers and chart types easily and generate the gadget. With this we
> also have removed the dependency of analytics gadget generation part from
> the carbon-dashboards repo, and people can have their own providers and
> chart types, in their repo and they can include that in the build time to
> get only into their product.
>
> Thanks,
> Sinthuja.
>
> Edit/ Re-generate function is not supported yet.

 2) The issues is, with this model it will be harder to support that
 even in the future. At least we should serialize all the parameters with
 the generated gadget.

>>> Editing is something we can achieve with very little effort, if we store
>>> all the properties that we have passed in the UI in a config file within
>>> the gadget then we can simply load that to the gadget generation wizard
>>> when we need to modify the gadget.
>>>
>> Ya, that's what I also meant by serialize. But in that case the UX is
>> broken compared to the parameter method, since the user still has to go
>> though the wizard again, and you can't see the values from the left panel.
>>
>> --
>> With regards,
>> *Manu*ranga Perera.
>>
>> phone : 071 7 70 20 50
>> mail : m...@wso2.com
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> *Sinthuja Rajendran*
> Technical Lead
> WSO2, Inc.:http://wso2.com
>
> Blog: http://sinthu-rajan.blogspot.com/
> Mobile: +94774273955
>
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>

Re: [Architecture] Modification of the gadget generation wizard's extension structure

[Sinthuja Ragendran]

Hi Manu,

On Wed, Jun 8, 2016 at 8:40 PM, Manuranga Perera  wrote:

> 1) We had a chat about how we can use gadget parameters instead of
>>> generation, have you guys considered that approach?
>>>
>>> We have cases like database credentials which should not be shown to the
>> user and should not be editable from the gadget properties. Further we also
>> need a model that gadget should be greeted by some privileged user and used
>> by others, so the gadget generation is the appropriate model to handle
>> this.
>>
>  I thought we can come up with a way to attach permissions to the params,
> so they can be hidden depending on the user. (this will help us generally
> not just for gadget gen case)
>

Yeah, initially i also thought we can go with such an approach. But then
there are some dynamic params that you need to populate based on the
previous selection that you have done. Ie, for example if it's batch
data/realtime/rdbms then the form params that you need to display is
different for each. If we are going to have such capabilities then it's
equal to have wizard apporach, and I don't really see much difference.

Anyhow our objective was to create a framework, where you can plug any data
providers and chart types easily and generate the gadget. With this we also
have removed the dependency of analytics gadget generation part from the
carbon-dashboards repo, and people can have their own providers and chart
types, in their repo and they can include that in the build time to get
only into their product.

Thanks,
Sinthuja.

Edit/ Re-generate function is not supported yet.
>>>
>>> 2) The issues is, with this model it will be harder to support that even
>>> in the future. At least we should serialize all the parameters with the
>>> generated gadget.
>>>
>> Editing is something we can achieve with very little effort, if we store
>> all the properties that we have passed in the UI in a config file within
>> the gadget then we can simply load that to the gadget generation wizard
>> when we need to modify the gadget.
>>
> Ya, that's what I also meant by serialize. But in that case the UX is
> broken compared to the parameter method, since the user still has to go
> though the wizard again, and you can't see the values from the left panel.
>
> --
> With regards,
> *Manu*ranga Perera.
>
> phone : 071 7 70 20 50
> mail : m...@wso2.com
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Sinthuja Rajendran*
Technical Lead
WSO2, Inc.:http://wso2.com

Blog: http://sinthu-rajan.blogspot.com/
Mobile: +94774273955
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Modification of the gadget generation wizard's extension structure

[Tanya Madurapperuma]

On Thu, Jun 9, 2016 at 1:10 AM, Manuranga Perera  wrote:

> 1) We had a chat about how we can use gadget parameters instead of
>>> generation, have you guys considered that approach?
>>>
>>> We have cases like database credentials which should not be shown to the
>> user and should not be editable from the gadget properties. Further we also
>> need a model that gadget should be greeted by some privileged user and used
>> by others, so the gadget generation is the appropriate model to handle
>> this.
>>
>  I thought we can come up with a way to attach permissions to the params,
> so they can be hidden depending on the user. (this will help us generally
> not just for gadget gen case)
>
> Edit/ Re-generate function is not supported yet.
>>>
>>> 2) The issues is, with this model it will be harder to support that even
>>> in the future. At least we should serialize all the parameters with the
>>> generated gadget.
>>>
>> Editing is something we can achieve with very little effort, if we store
>> all the properties that we have passed in the UI in a config file within
>> the gadget then we can simply load that to the gadget generation wizard
>> when we need to modify the gadget.
>>
> Ya, that's what I also meant by serialize. But in that case the UX is
> broken compared to the parameter method, since the user still has to go
> though the wizard again, and you can't see the values from the left panel.
>
As Suho said with this model we store all the user inputs for provider
configuration and chart configuration in a  json file (conf.json), so if
required we can provider an UI option for the *priviledged* users to edit
those properties in the future. So that user doesn't have to go through the
wizard again.

Thanks,
Tanya

>
> --
> With regards,
> *Manu*ranga Perera.
>
> phone : 071 7 70 20 50
> mail : m...@wso2.com
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
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

Re: [Architecture] Modification of the gadget generation wizard's extension structure

[Manuranga Perera]

>
> 1) We had a chat about how we can use gadget parameters instead of
>> generation, have you guys considered that approach?
>>
>> We have cases like database credentials which should not be shown to the
> user and should not be editable from the gadget properties. Further we also
> need a model that gadget should be greeted by some privileged user and used
> by others, so the gadget generation is the appropriate model to handle
> this.
>
 I thought we can come up with a way to attach permissions to the params,
so they can be hidden depending on the user. (this will help us generally
not just for gadget gen case)

Edit/ Re-generate function is not supported yet.
>>
>> 2) The issues is, with this model it will be harder to support that even
>> in the future. At least we should serialize all the parameters with the
>> generated gadget.
>>
> Editing is something we can achieve with very little effort, if we store
> all the properties that we have passed in the UI in a config file within
> the gadget then we can simply load that to the gadget generation wizard
> when we need to modify the gadget.
>
Ya, that's what I also meant by serialize. But in that case the UX is
broken compared to the parameter method, since the user still has to go
though the wizard again, and you can't see the values from the left panel.

-- 
With regards,
*Manu*ranga Perera.

phone : 071 7 70 20 50
mail : m...@wso2.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Modification of the gadget generation wizard's extension structure

[Sriskandarajah Suhothayan]

On Wed, Jun 8, 2016 at 3:31 PM, Manuranga Perera  wrote:

> Hi Tanya, Sinthuja,
>
> 1) We had a chat about how we can use gadget parameters instead of
> generation, have you guys considered that approach?
>
> We have cases like database credentials which should not be shown to the
user and should not be editable from the gadget properties. Further we also
need a model that gadget should be greeted by some privileged user and used
by others, so the gadget generation is the appropriate model to handle
this.


> Edit/ Re-generate function is not supported yet.
>
> 2) The issues is, with this model it will be harder to support that even
> in the future. At least we should serialize all the parameters with the
> generated gadget.
>
> Editing is something we can achieve with very little effort, if we store
all the properties that we have passed in the UI in a config file within
the gadget then we can simply load that to the gadget generation wizard
when we need to modify the gadget.

Regards
Suho

> --
> With regards,
> *Manu*ranga Perera.
>
> phone : 071 7 70 20 50
> mail : m...@wso2.com
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 

*S. Suhothayan*
Technical Lead & Team Lead of WSO2 Complex Event Processor
*WSO2 Inc. *http://wso2.com
* *
lean . enterprise . middleware


*cell: (+94) 779 756 757 | blog: http://suhothayan.blogspot.com/
twitter: http://twitter.com/suhothayan
 | linked-in:
http://lk.linkedin.com/in/suhothayan *
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Modification of the gadget generation wizard's extension structure

[Manuranga Perera]

Hi Tanya, Sinthuja,

1) We had a chat about how we can use gadget parameters instead of
generation, have you guys considered that approach?

Edit/ Re-generate function is not supported yet.

2) The issues is, with this model it will be harder to support that even in
the future. At least we should serialize all the parameters with the
generated gadget.

-- 
With regards,
*Manu*ranga Perera.

phone : 071 7 70 20 50
mail : m...@wso2.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Modification of the gadget generation wizard's extension structure

[Tanya Madurapperuma]

@ Manu :
Edit/ Re-generate function is not supported yet. The initial plan was to
have a gadget generation tool which is similar to what was there in DAS but
with extension points to plug providers and chart templates.

@ Jerad :
Please see my inline comments.
On Wed, Jun 8, 2016 at 10:04 AM, Jerad Rutnam  wrote:

> Hi Tanya,
>
> Few more suggestions for the offline chat we had previously, what if we do
> below changes?
>
> *Chart template structure*
>
> └── line-chart
> ├── api.js
> ├── config.json
> ├── chart-libs - *libs **[template folder could be something other
> than a chart type. e.g. Map, Widget]*
> │   └── vendorName_version
> │   └── [ js_css_images_etc_as_same_as_vendor_ships ]
> ├── css
> │   └── line-chart.css
> └── js
> └── line-chart.js
>
>
> *Generated gadget structure*
>
> └── test_gadget
> ├── conf.json
> ├── gadget-controller.jag
> ├── gadget.json
> ├── index.png
> ├── index.xml
> ├── chart-libs - *libs **[this folder can have any third party
> libraries, not only chart libraries]*
> │   └── vendorName_version
> │   └── [ js_css_images_etc_as_same_as_vendor_ships ]
> ├── css
> │   └── line-chart.css
> └── js
> ├── core-js - *core **[we are already in js folder - so we can
> take out the js part]*
> │   ├── gadget-core.js
> │   ├── line-chart-api.js
> │   └── provider-api.js
> └── line-chart.js
>
>
> And in chart *config.json*: What if we have file extensions along with
> the file name? Any reason to remove it?
>
> "*imports*": {
> "js": ["vendorName_version/common*.js*"],
> "css": ["vendorName_version/common*.css*"]
> },
> "*shared_imports*": { *[indicates users that all these are shared
> imports]*
> "js": ["vendorName_version/d3.min*.js*", "vendorName_version/vega
> *.js*", "line-chart*.js*"],
> "css": ["vendorName_version/graph*.css*, line-chart*.css*"]
> }
>
> Shouldn't this be other way round? First one should be shared_imports
(fetched from /portal/libs/ ) and second one will be imports (inside chart
template folder)

>
> WDYT? This will make it more generic. So we can avoid restricting to the
> term "chart".
>
>
> Cheers!
> Jerad
>
>
> On Tue, Jun 7, 2016 at 5:49 PM, Tanya Madurapperuma 
> wrote:
>
>> Hi all,
>>
>> Thank you for your inputs.
>>
>> @ Dakshika :
>> Based on your input following modifications were made.
>>
>> *Chart template structure*
>>
>> └── line-chart
>> ├── api.js
>> ├── config.json
>> ├── chart-libs
>> │   └── vendorName_version
>> │   └── js_css_images_etc_as_same_as_vendor_ships
>> ├── css
>> │   └── line-chart.css
>> └── js
>> └── line-chart.js
>>
>>
>> *Generated gadget structure*
>>
>> └── test_gadget
>> ├── conf.json
>> ├── gadget-controller.jag
>> ├── gadget.json
>> ├── index.png
>> ├── index.xml
>> ├── chart-libs
>> │   └── vendorName_version
>> │   └── js_css_images_etc_as_same_as_vendor_ships
>> ├── css
>> │   └── line-chart.css
>> └── js
>> ├── core-js
>> │   ├── gadget-core.js
>> │   ├── line-chart-api.js
>> │   └── provider-api.js
>> └── line-chart.js
>>
>>
>> *Folder structure for storing common libs*
>>
>> portal
>>   |── libs
>>
>>   ├── vendorName_version
>>   │   ├── 
>>
>>
>> *Changes to the existing model*
>>
>>- common libs will reside inside portal/libs/
>>
>> *chart config.json*
>>
>> "common": {
>> "js": ["vendorName_version/common"],
>> "css": ["vendorName_version/common"]
>> },
>> "chart": {
>> "js": ["vendorName_version/d3.min", "vendorName_version/vega",
>> "line-chart"],
>> "css": ["vendorName_version/graph, line-chart"]
>> }
>>
>> "common" is for libs fetched from /portal/libs
>> "chart" is for both chart specfic libs inside js folder of chart template
>> and chart-libs that are coming from vendors.
>>
>> So with the change suggested by Dakshika we will have to specify the
>> directory path of chart-libs in the config.json (ex:
>>  "vendorName_version/d3.min" )
>> But if it is a chart specific js file (in this example line-chart.js)
>> specifying the file name is enough.
>>
>> In the gadget xml of the generated gadget we will be using the relative
>> path for libs fetched from /portal/libs.
>>
>> @ Suho : Yes, the gadgets generated via old wizard will still work, I was
>> worried about the consistency between old gadgets and new gadgets generated
>> via the wizard. As per the offline chat we had, no obligations from IOT
>> side.
>>
>> Thanks,
>> Tanya
>>
>> --
>> Tanya Madurapperuma
>>
>> Senior Software Engineer,
>> WSO2 Inc. : wso2.com
>> Mobile : +94718184439
>> Blog : http://tanyamadurapperuma.blogspot.com
>>
>> On Tue, Jun 7, 2016 at 3:53 PM, Dakshika Jayathilaka 
>> wrote:
>>
>>> Hi All,
>>>
>>> IMO it's better if we can maintain third-party libraries as a separate
>>> entity. U

Re: [Architecture] Modification of the gadget generation wizard's extension structure

[Dakshika Jayathilaka]

Hi All,

Ideally, we need to provide an option to re-edit once they generated. AFAIK
we don't have that option yet.

Regards,

*Dakshika Jayathilaka*
PMC Member & Committer of Apache Stratos
Associate Technical Lead
WSO2, Inc.
lean.enterprise.middleware
0771100911

On Tue, Jun 7, 2016 at 11:34 PM, Manuranga Perera  wrote:

> How would a user modify or regenerate with slight change?
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Modification of the gadget generation wizard's extension structure

[Manuranga Perera]

How would a user modify or regenerate with slight change?
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Modification of the gadget generation wizard's extension structure

[Tanya Madurapperuma]

Hi Manu,

On Tue, Jun 7, 2016 at 8:05 PM, Manuranga Perera  wrote:

> Hi Tanya,
>
> 1) Are we really generating gadgets, though the wizard or generating
> JSONs? (I personally don't like the former, as we have discussed before)
>
We are generating the gadget not JSONs.

>
> 2) If we are generating, which files are dynamic generated Vs. which files
> are copies? I think it should be possible to figure out by looking at files.
>
You can find the template that we use now at [1]. Rest of the files will be
directly copied from the chart or provider template.

[1]
https://github.com/wso2/carbon-dashboards/tree/master/apps/portal/templates/gadgets/gadget-generation-templates


Thanks,
Tanya

>
> On Tue, Jun 7, 2016 at 5:41 AM, Tanya Madurapperuma 
> wrote:
>
>> Hi all,
>>
>> During an offline discussion with Jerad following modification were
>> suggested regarding the directory structure of the extension model. All
>> these changes are subjected to js and css file locations.
>>
>> *Chart template structure*
>>
>> |── line-chart
>>   │   ├── css
>>   │   │   └── line-chart.css
>>   │   └── js
>>   │   ├── d3.min.js
>>   │   ├── vega.js
>>   │   └── VizGrammar.min.js
>>|── config.json
>>   ├── api.js
>>
>>
>> *Changes to the existing model*
>>
>>- rename index.js to api.js
>>- rename chart-libs folder to js
>>- have a css folder in the same level
>>
>>
>> *Generated gadget structure*
>>
>> └── test_gadget
>> │   │   ├── conf.json
>> │   │   ├── css
>> │   │   │   └── line-chart.css
>> │   │   ├── gadget-controller.jag
>> │   │   ├── gadget.json
>> │   │   ├── index.png
>> │   │   ├── index.xml
>> │   │   └── js
>> │   │   ├── core
>> │   │   │   ├── gadget-core.js
>> │   │   │   ├── line-chart-api.js
>> │   │   │   └── provider-api.js
>> │   │   ├── d3.min.js
>> │   │   ├── vega.js
>> │   │   └── VizGrammar.min.js
>>
>>
>> *Changes to the existing model*
>>
>>- Instead of the *chart-libs* folder inside *js* folder, have a *core
>>*folder inside *js *folder and place chart specific js files in js
>>folder
>>
>>
>> *Folder structure for storing common libs*
>>
>> portal
>>   |── gadget-commons
>>
>>├── css
>>│   └── common.css
>>└── js
>>└── common.js
>>
>>
>> *Changes to the existing model*
>>
>>- Now we have common libs inside portal/libs/common-chart-libs/
>>
>> *chart config.json*
>>
>> "common": {
>> "js": ["common"],
>> "css": ["common"]
>> },
>> "chart": {
>> "js": ["d3.min", "vega", "VizGrammar.min"],
>> "css": ["line-chart"]
>> }
>>
>> *existing config.json*
>>
>> "common-libs" : ["wso2gadgets","chart-utils"],
>> "chart-libs" : ["d3.min","vega","VizGrammar.min"]
>>
>> I think this model is cleaner and intuitive than the exiting model.
>> AFAIK existing wizard is only used for IOT analytics. If there are no
>> concerns from them shall we move to this new model?
>>
>> @ Suho, Dunith : WDYT ? Will this incur lot of changes from IOT side?
>> Appreciate your input.
>>
>> Thanks,
>> Tanya
>>
>> --
>> 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
>>
>>
>
>
> --
> With regards,
> *Manu*ranga Perera.
>
> phone : 071 7 70 20 50
> mail : m...@wso2.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

Re: [Architecture] Modification of the gadget generation wizard's extension structure

[Manuranga Perera]

Hi Tanya,

1) Are we really generating gadgets, though the wizard or generating JSONs?
(I personally don't like the former, as we have discussed before)

2) If we are generating, which files are dynamic generated Vs. which files
are copies? I think it should be possible to figure out by looking at files.

On Tue, Jun 7, 2016 at 5:41 AM, Tanya Madurapperuma  wrote:

> Hi all,
>
> During an offline discussion with Jerad following modification were
> suggested regarding the directory structure of the extension model. All
> these changes are subjected to js and css file locations.
>
> *Chart template structure*
>
> |── line-chart
>   │   ├── css
>   │   │   └── line-chart.css
>   │   └── js
>   │   ├── d3.min.js
>   │   ├── vega.js
>   │   └── VizGrammar.min.js
>|── config.json
>   ├── api.js
>
>
> *Changes to the existing model*
>
>- rename index.js to api.js
>- rename chart-libs folder to js
>- have a css folder in the same level
>
>
> *Generated gadget structure*
>
> └── test_gadget
> │   │   ├── conf.json
> │   │   ├── css
> │   │   │   └── line-chart.css
> │   │   ├── gadget-controller.jag
> │   │   ├── gadget.json
> │   │   ├── index.png
> │   │   ├── index.xml
> │   │   └── js
> │   │   ├── core
> │   │   │   ├── gadget-core.js
> │   │   │   ├── line-chart-api.js
> │   │   │   └── provider-api.js
> │   │   ├── d3.min.js
> │   │   ├── vega.js
> │   │   └── VizGrammar.min.js
>
>
> *Changes to the existing model*
>
>- Instead of the *chart-libs* folder inside *js* folder, have a *core 
> *folder
>inside *js *folder and place chart specific js files in js folder
>
>
> *Folder structure for storing common libs*
>
> portal
>   |── gadget-commons
>
>├── css
>│   └── common.css
>└── js
>└── common.js
>
>
> *Changes to the existing model*
>
>- Now we have common libs inside portal/libs/common-chart-libs/
>
> *chart config.json*
>
> "common": {
> "js": ["common"],
> "css": ["common"]
> },
> "chart": {
> "js": ["d3.min", "vega", "VizGrammar.min"],
> "css": ["line-chart"]
> }
>
> *existing config.json*
>
> "common-libs" : ["wso2gadgets","chart-utils"],
> "chart-libs" : ["d3.min","vega","VizGrammar.min"]
>
> I think this model is cleaner and intuitive than the exiting model.
> AFAIK existing wizard is only used for IOT analytics. If there are no
> concerns from them shall we move to this new model?
>
> @ Suho, Dunith : WDYT ? Will this incur lot of changes from IOT side?
> Appreciate your input.
>
> Thanks,
> Tanya
>
> --
> 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
>
>


-- 
With regards,
*Manu*ranga Perera.

phone : 071 7 70 20 50
mail : m...@wso2.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Modification of the gadget generation wizard's extension structure

[Tanya Madurapperuma]

Hi all,

Thank you for your inputs.

@ Dakshika :
Based on your input following modifications were made.

*Chart template structure*

└── line-chart
├── api.js
├── config.json
├── chart-libs
│   └── vendorName_version
│   └── js_css_images_etc_as_same_as_vendor_ships
├── css
│   └── line-chart.css
└── js
└── line-chart.js


*Generated gadget structure*

└── test_gadget
├── conf.json
├── gadget-controller.jag
├── gadget.json
├── index.png
├── index.xml
├── chart-libs
│   └── vendorName_version
│   └── js_css_images_etc_as_same_as_vendor_ships
├── css
│   └── line-chart.css
└── js
├── core-js
│   ├── gadget-core.js
│   ├── line-chart-api.js
│   └── provider-api.js
└── line-chart.js


*Folder structure for storing common libs*

portal
  |── libs

  ├── vendorName_version
  │   ├── 


*Changes to the existing model*

   - common libs will reside inside portal/libs/

*chart config.json*

"common": {
"js": ["vendorName_version/common"],
"css": ["vendorName_version/common"]
},
"chart": {
"js": ["vendorName_version/d3.min", "vendorName_version/vega",
"line-chart"],
"css": ["vendorName_version/graph, line-chart"]
}

"common" is for libs fetched from /portal/libs
"chart" is for both chart specfic libs inside js folder of chart template
and chart-libs that are coming from vendors.

So with the change suggested by Dakshika we will have to specify the
directory path of chart-libs in the config.json (ex:
 "vendorName_version/d3.min" )
But if it is a chart specific js file (in this example line-chart.js)
specifying the file name is enough.

In the gadget xml of the generated gadget we will be using the relative
path for libs fetched from /portal/libs.

@ Suho : Yes, the gadgets generated via old wizard will still work, I was
worried about the consistency between old gadgets and new gadgets generated
via the wizard. As per the offline chat we had, no obligations from IOT
side.

Thanks,
Tanya

-- 
Tanya Madurapperuma

Senior Software Engineer,
WSO2 Inc. : wso2.com
Mobile : +94718184439
Blog : http://tanyamadurapperuma.blogspot.com

On Tue, Jun 7, 2016 at 3:53 PM, Dakshika Jayathilaka 
wrote:

> Hi All,
>
> IMO it's better if we can maintain third-party libraries as a separate
> entity. Usually, most of the third party libs have their own dependencies
> (ex: some CSS files refer images/ fonts ). If we place them separately it's
> hard to identify relevant dependency at a glance.
>
>  At the same time, I would like to propose to have library version as
> well. This will really useful if someone wants to upgrade third-party lib
> etc.
>
> Regards,
>
> *Dakshika Jayathilaka*
> PMC Member & Committer of Apache Stratos
> Senior Software Engineer
> WSO2, Inc.
> lean.enterprise.middleware
> 0771100911
>
> On Tue, Jun 7, 2016 at 3:11 PM, Tanya Madurapperuma 
> wrote:
>
>> Hi all,
>>
>> During an offline discussion with Jerad following modification were
>> suggested regarding the directory structure of the extension model. All
>> these changes are subjected to js and css file locations.
>>
>> *Chart template structure*
>>
>> |── line-chart
>>   │   ├── css
>>   │   │   └── line-chart.css
>>   │   └── js
>>   │   ├── d3.min.js
>>   │   ├── vega.js
>>   │   └── VizGrammar.min.js
>>|── config.json
>>   ├── api.js
>>
>>
>> *Changes to the existing model*
>>
>>- rename index.js to api.js
>>- rename chart-libs folder to js
>>- have a css folder in the same level
>>
>>
>> *Generated gadget structure*
>>
>> └── test_gadget
>> │   │   ├── conf.json
>> │   │   ├── css
>> │   │   │   └── line-chart.css
>> │   │   ├── gadget-controller.jag
>> │   │   ├── gadget.json
>> │   │   ├── index.png
>> │   │   ├── index.xml
>> │   │   └── js
>> │   │   ├── core
>> │   │   │   ├── gadget-core.js
>> │   │   │   ├── line-chart-api.js
>> │   │   │   └── provider-api.js
>> │   │   ├── d3.min.js
>> │   │   ├── vega.js
>> │   │   └── VizGrammar.min.js
>>
>>
>> *Changes to the existing model*
>>
>>- Instead of the *chart-libs* folder inside *js* folder, have a *core
>>*folder inside *js *folder and place chart specific js files in js
>>folder
>>
>>
>> *Folder structure for storing common libs*
>>
>> portal
>>   |── gadget-commons
>>
>>├── css
>>│   └── common.css
>>└── js
>>└── common.js
>>
>>
>> *Changes to the existing model*
>>
>>- Now we have common libs inside portal/libs/common-chart-libs/
>>
>> *chart config.json*
>>
>> "common": {
>> "js": ["common"],
>> "css": ["common"]
>> },
>> "chart": {
>> "js": ["d3.min", "vega", "VizGrammar.min"],
>> "css": ["line-chart"]
>> }
>>
>> *existing config.json*
>>
>> "common-libs" : ["wso2ga

Re: [Architecture] Modification of the gadget generation wizard's extension structure

[Dakshika Jayathilaka]

Hi All,

IMO it's better if we can maintain third-party libraries as a separate
entity. Usually, most of the third party libs have their own dependencies
(ex: some CSS files refer images/ fonts ). If we place them separately it's
hard to identify relevant dependency at a glance.

 At the same time, I would like to propose to have library version as well.
This will really useful if someone wants to upgrade third-party lib etc.

Regards,

*Dakshika Jayathilaka*
PMC Member & Committer of Apache Stratos
Senior Software Engineer
WSO2, Inc.
lean.enterprise.middleware
0771100911

On Tue, Jun 7, 2016 at 3:11 PM, Tanya Madurapperuma  wrote:

> Hi all,
>
> During an offline discussion with Jerad following modification were
> suggested regarding the directory structure of the extension model. All
> these changes are subjected to js and css file locations.
>
> *Chart template structure*
>
> |── line-chart
>   │   ├── css
>   │   │   └── line-chart.css
>   │   └── js
>   │   ├── d3.min.js
>   │   ├── vega.js
>   │   └── VizGrammar.min.js
>|── config.json
>   ├── api.js
>
>
> *Changes to the existing model*
>
>- rename index.js to api.js
>- rename chart-libs folder to js
>- have a css folder in the same level
>
>
> *Generated gadget structure*
>
> └── test_gadget
> │   │   ├── conf.json
> │   │   ├── css
> │   │   │   └── line-chart.css
> │   │   ├── gadget-controller.jag
> │   │   ├── gadget.json
> │   │   ├── index.png
> │   │   ├── index.xml
> │   │   └── js
> │   │   ├── core
> │   │   │   ├── gadget-core.js
> │   │   │   ├── line-chart-api.js
> │   │   │   └── provider-api.js
> │   │   ├── d3.min.js
> │   │   ├── vega.js
> │   │   └── VizGrammar.min.js
>
>
> *Changes to the existing model*
>
>- Instead of the *chart-libs* folder inside *js* folder, have a *core 
> *folder
>inside *js *folder and place chart specific js files in js folder
>
>
> *Folder structure for storing common libs*
>
> portal
>   |── gadget-commons
>
>├── css
>│   └── common.css
>└── js
>└── common.js
>
>
> *Changes to the existing model*
>
>- Now we have common libs inside portal/libs/common-chart-libs/
>
> *chart config.json*
>
> "common": {
> "js": ["common"],
> "css": ["common"]
> },
> "chart": {
> "js": ["d3.min", "vega", "VizGrammar.min"],
> "css": ["line-chart"]
> }
>
> *existing config.json*
>
> "common-libs" : ["wso2gadgets","chart-utils"],
> "chart-libs" : ["d3.min","vega","VizGrammar.min"]
>
> I think this model is cleaner and intuitive than the exiting model.
> AFAIK existing wizard is only used for IOT analytics. If there are no
> concerns from them shall we move to this new model?
>
> @ Suho, Dunith : WDYT ? Will this incur lot of changes from IOT side?
> Appreciate your input.
>
> Thanks,
> Tanya
>
> --
> 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

Re: [Architecture] Modification of the gadget generation wizard's extension structure

[Sriskandarajah Suhothayan]

Gadget generation API  is orthogonal to the usage API and we are not
changing the usage API, hence gadget created via old generation tools will
still work.

Regards
Suho

On Tue, Jun 7, 2016 at 3:34 PM, Rajith Vitharana  wrote:

> Hi Tanya,
>
> On Tue, Jun 7, 2016 at 3:21 PM, Tanya Madurapperuma 
> wrote:
>
>> Hi Rajith,
>>
>> We have not done any GA release, not even an Alpha release of the product
>> with this, but a component repo release.
>>
> Still if this is a API change to a component which we already released to
> public, I feel we have to think of those aspects as well. (Conflicts
> happens only if some one is going to use it, hence kind of taking a chance
> doing such release, if we can't 100% sure no one will going to use that) or
> else we may need to provide migration (support when/if) needed. Just my two
> cents :)
>
> Thanks,
>
> --
> Rajith Vitharana
>
> Software Engineer,
> WSO2 Inc. : wso2.com
> Mobile : +94715883223
> Blog : http://lankavitharana.blogspot.com/
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 

*S. Suhothayan*
Technical Lead & Team Lead of WSO2 Complex Event Processor
*WSO2 Inc. *http://wso2.com
* *
lean . enterprise . middleware


*cell: (+94) 779 756 757 | blog: http://suhothayan.blogspot.com/
twitter: http://twitter.com/suhothayan
 | linked-in:
http://lk.linkedin.com/in/suhothayan *
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Modification of the gadget generation wizard's extension structure

[Rajith Vitharana]

Hi Tanya,

On Tue, Jun 7, 2016 at 3:21 PM, Tanya Madurapperuma  wrote:

> Hi Rajith,
>
> We have not done any GA release, not even an Alpha release of the product
> with this, but a component repo release.
>
Still if this is a API change to a component which we already released to
public, I feel we have to think of those aspects as well. (Conflicts
happens only if some one is going to use it, hence kind of taking a chance
doing such release, if we can't 100% sure no one will going to use that) or
else we may need to provide migration (support when/if) needed. Just my two
cents :)

Thanks,

-- 
Rajith Vitharana

Software Engineer,
WSO2 Inc. : wso2.com
Mobile : +94715883223
Blog : http://lankavitharana.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Modification of the gadget generation wizard's extension structure

[Tanya Madurapperuma]

Hi Rajith,

We have not done any GA release, not even an Alpha release of the product
with this, but a component repo release.

Thanks,
Tanya

On Tue, Jun 7, 2016 at 3:17 PM, Rajith Vitharana  wrote:

> Hi Tanya,
>
> On Tue, Jun 7, 2016 at 3:11 PM, Tanya Madurapperuma 
> wrote:
>
>> Hi all,
>>
>> During an offline discussion with Jerad following modification were
>> suggested regarding the directory structure of the extension model. All
>> these changes are subjected to js and css file locations.
>>
>> *Chart template structure*
>>
>> |── line-chart
>>   │   ├── css
>>   │   │   └── line-chart.css
>>   │   └── js
>>   │   ├── d3.min.js
>>   │   ├── vega.js
>>   │   └── VizGrammar.min.js
>>|── config.json
>>   ├── api.js
>>
>>
>> *Changes to the existing model*
>>
>>- rename index.js to api.js
>>- rename chart-libs folder to js
>>- have a css folder in the same level
>>
>>
>> *Generated gadget structure*
>>
>> └── test_gadget
>> │   │   ├── conf.json
>> │   │   ├── css
>> │   │   │   └── line-chart.css
>> │   │   ├── gadget-controller.jag
>> │   │   ├── gadget.json
>> │   │   ├── index.png
>> │   │   ├── index.xml
>> │   │   └── js
>> │   │   ├── core
>> │   │   │   ├── gadget-core.js
>> │   │   │   ├── line-chart-api.js
>> │   │   │   └── provider-api.js
>> │   │   ├── d3.min.js
>> │   │   ├── vega.js
>> │   │   └── VizGrammar.min.js
>>
>>
>> *Changes to the existing model*
>>
>>- Instead of the *chart-libs* folder inside *js* folder, have a *core
>>*folder inside *js *folder and place chart specific js files in js
>>folder
>>
>>
>> *Folder structure for storing common libs*
>>
>> portal
>>   |── gadget-commons
>>
>>├── css
>>│   └── common.css
>>└── js
>>└── common.js
>>
>>
>> *Changes to the existing model*
>>
>>- Now we have common libs inside portal/libs/common-chart-libs/
>>
>> *chart config.json*
>>
>> "common": {
>> "js": ["common"],
>> "css": ["common"]
>> },
>> "chart": {
>> "js": ["d3.min", "vega", "VizGrammar.min"],
>> "css": ["line-chart"]
>> }
>>
>> *existing config.json*
>>
>> "common-libs" : ["wso2gadgets","chart-utils"],
>> "chart-libs" : ["d3.min","vega","VizGrammar.min"]
>>
>> I think this model is cleaner and intuitive than the exiting model.
>> AFAIK existing wizard is only used for IOT analytics. If there are no
>> concerns from them shall we move to this new model?
>>
> If we have released a version with earlier method, there may be people
> using it in future(even though only IOT is using that for now) so it's
> better to think of a migration process as well. Or else proper
> documentation and ask not to use earlier version (which I feel is not a
> good thing)
>
> Thanks,
>
> --
> Rajith Vitharana
>
> Software Engineer,
> WSO2 Inc. : wso2.com
> Mobile : +94715883223
> Blog : http://lankavitharana.blogspot.com/
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
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

Re: [Architecture] Modification of the gadget generation wizard's extension structure

[Rajith Vitharana]

Hi Tanya,

On Tue, Jun 7, 2016 at 3:11 PM, Tanya Madurapperuma  wrote:

> Hi all,
>
> During an offline discussion with Jerad following modification were
> suggested regarding the directory structure of the extension model. All
> these changes are subjected to js and css file locations.
>
> *Chart template structure*
>
> |── line-chart
>   │   ├── css
>   │   │   └── line-chart.css
>   │   └── js
>   │   ├── d3.min.js
>   │   ├── vega.js
>   │   └── VizGrammar.min.js
>|── config.json
>   ├── api.js
>
>
> *Changes to the existing model*
>
>- rename index.js to api.js
>- rename chart-libs folder to js
>- have a css folder in the same level
>
>
> *Generated gadget structure*
>
> └── test_gadget
> │   │   ├── conf.json
> │   │   ├── css
> │   │   │   └── line-chart.css
> │   │   ├── gadget-controller.jag
> │   │   ├── gadget.json
> │   │   ├── index.png
> │   │   ├── index.xml
> │   │   └── js
> │   │   ├── core
> │   │   │   ├── gadget-core.js
> │   │   │   ├── line-chart-api.js
> │   │   │   └── provider-api.js
> │   │   ├── d3.min.js
> │   │   ├── vega.js
> │   │   └── VizGrammar.min.js
>
>
> *Changes to the existing model*
>
>- Instead of the *chart-libs* folder inside *js* folder, have a *core 
> *folder
>inside *js *folder and place chart specific js files in js folder
>
>
> *Folder structure for storing common libs*
>
> portal
>   |── gadget-commons
>
>├── css
>│   └── common.css
>└── js
>└── common.js
>
>
> *Changes to the existing model*
>
>- Now we have common libs inside portal/libs/common-chart-libs/
>
> *chart config.json*
>
> "common": {
> "js": ["common"],
> "css": ["common"]
> },
> "chart": {
> "js": ["d3.min", "vega", "VizGrammar.min"],
> "css": ["line-chart"]
> }
>
> *existing config.json*
>
> "common-libs" : ["wso2gadgets","chart-utils"],
> "chart-libs" : ["d3.min","vega","VizGrammar.min"]
>
> I think this model is cleaner and intuitive than the exiting model.
> AFAIK existing wizard is only used for IOT analytics. If there are no
> concerns from them shall we move to this new model?
>
If we have released a version with earlier method, there may be people
using it in future(even though only IOT is using that for now) so it's
better to think of a migration process as well. Or else proper
documentation and ask not to use earlier version (which I feel is not a
good thing)

Thanks,

-- 
Rajith Vitharana

Software Engineer,
WSO2 Inc. : wso2.com
Mobile : +94715883223
Blog : http://lankavitharana.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] Modification of the gadget generation wizard's extension structure

[Tanya Madurapperuma]

Hi all,

During an offline discussion with Jerad following modification were
suggested regarding the directory structure of the extension model. All
these changes are subjected to js and css file locations.

*Chart template structure*

|── line-chart
  │   ├── css
  │   │   └── line-chart.css
  │   └── js
  │   ├── d3.min.js
  │   ├── vega.js
  │   └── VizGrammar.min.js
   |── config.json
  ├── api.js


*Changes to the existing model*

   - rename index.js to api.js
   - rename chart-libs folder to js
   - have a css folder in the same level


*Generated gadget structure*

└── test_gadget
│   │   ├── conf.json
│   │   ├── css
│   │   │   └── line-chart.css
│   │   ├── gadget-controller.jag
│   │   ├── gadget.json
│   │   ├── index.png
│   │   ├── index.xml
│   │   └── js
│   │   ├── core
│   │   │   ├── gadget-core.js
│   │   │   ├── line-chart-api.js
│   │   │   └── provider-api.js
│   │   ├── d3.min.js
│   │   ├── vega.js
│   │   └── VizGrammar.min.js


*Changes to the existing model*

   - Instead of the *chart-libs* folder inside *js* folder, have a
*core *folder
   inside *js *folder and place chart specific js files in js folder


*Folder structure for storing common libs*

portal
  |── gadget-commons

   ├── css
   │   └── common.css
   └── js
   └── common.js


*Changes to the existing model*

   - Now we have common libs inside portal/libs/common-chart-libs/

*chart config.json*

"common": {
"js": ["common"],
"css": ["common"]
},
"chart": {
"js": ["d3.min", "vega", "VizGrammar.min"],
"css": ["line-chart"]
}

*existing config.json*

"common-libs" : ["wso2gadgets","chart-utils"],
"chart-libs" : ["d3.min","vega","VizGrammar.min"]

I think this model is cleaner and intuitive than the exiting model.
AFAIK existing wizard is only used for IOT analytics. If there are no
concerns from them shall we move to this new model?

@ Suho, Dunith : WDYT ? Will this incur lot of changes from IOT side?
Appreciate your input.

Thanks,
Tanya

-- 
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