Hi Sajith, Thank you for your reply. Please find my responses inline.
On Mon, Jun 13, 2016 at 1:26 AM, SajithAR Ariyarathna <sajit...@wso2.com> 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 "<gadget_name>-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 <gadget-name> 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 <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/ > -- 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
