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