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 "<gadget_name>-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 <[email protected]>
wrote:
> Hi Manu,
>
> On Wed, Jun 8, 2016 at 8:40 PM, Manuranga Perera <[email protected]> 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 : [email protected]
>>
>> _______________________________________________
>> Architecture mailing list
>> [email protected]
>> 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
> [email protected]
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
--
Sajith Janaprasad Ariyarathna
Software Engineer; WSO2, Inc.; http://wso2.com/
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
