Widgetizing the various wizards won't be targeted for 4.2 for sure . It would mostly be for some future release ..may be 4.3 or later since it would require pretty good amount of refactoring apart from a brand new implementation .
Thanks, Pranav -----Original Message----- From: SuichII, Christopher [mailto:chris.su...@netapp.com] Sent: Friday, June 14, 2013 12:00 AM To: dev@cloudstack.apache.org Subject: Re: UI Plugin Questions I'm using require.js to get some custom strings into the dictionary now, so I'll look into extending the plugin api to add internationalized string js files for plugins while I'm in there. Some helpers with the Infrastructure would be great, but maybe what I meant wasn't clear. We don't want to contribute a box (whatever they're being called) to the Infrastructure page. We want the main page of our tab to look just like the Infrastructure page but only with boxes that we create. I've got it working now, but it just involves creating the DOM elements by hand and manipulating the buttons on them. Can you be more specific with which release you were hoping to widgitize wizards? Next major release as in 4.2, 4.3 or 5.0. This would be a really helpful feature for our plugin, so if it's going to be a while, I would be more than happy to talk offline and see what I can do to begin working on this. Thanks for the quick replies! -- Chris Suich chris.su...@netapp.com NetApp Software Engineer Data Center Platforms Cloud Solutions Citrix, Cisco & Red Hat On 6/13/13 1:52 PM, "Brian Federle" <brian.fede...@citrix.com> wrote: >>> I know the infrastructure code is too huge to handle and that is why >>>all new features which would be developed would be developed in the >>>form of UI modules (Eg - CISCO asa 100 support / vnmcNetworkProvider >>>/ >>>VPC) . > >That is correct -- the infrastructure section handles a lot of central >parts of the CS API, so it needs a lot of custom code and UI flows. The >idea is to basically make a mini-API in the UI plugin framework for >extending specific sections, such as network service providers. If you >specify what you want to add to this section, I can add a set of helper >functions that will make it easier to write your plugin. > >I also plan to 'widgetize' the multi-step wizards for the next major >release, so that they can be applied to other features as easily as the >list view, detail view, etc. are. > >>> -Unquoted JSON values: Some will claim this is a bug on our side, >>>some would say it is a CS bug, so we'll see what people think... The >>>JSON spec says that numeric and boolean values do not need to be quoted. >>>However, throughout the UI code, values are taken from data providers >>>and directly checked like: > >>> if (value) { >>> // do something >>> } > >This is because, for the majority of cases the UI is checking for >null/not null (empty strings count as null); Boolean values are >actually a bit rare in most of the API in my experience. For example, >if no virtual machines are returned in a listVirtualMachines call, then >the response object will be null, so it is easier/more concise to check >it the above way. > >However, for other cases, we do use a converter as Pranav mentioned to >convert "true"/"false" string to a Boolean. > >-----Original Message----- >From: Pranav Saxena >Sent: Thursday, June 13, 2013 9:58 AM >To: dev@cloudstack.apache.org >Cc: Brian Federle >Subject: RE: UI Plugin Questions > >Please see comments inline - > >Thanks, >Pranav >-----Original Message----- >From: SuichII, Christopher [mailto:chris.su...@netapp.com] >Sent: Thursday, June 13, 2013 8:11 PM >To: dev@cloudstack.apache.org >Subject: UI Plugin Questions > >Hi everyone, first time poster here... > >I've started working on a UI Plugin and have come across a few things >I'd like to inquire about and run by some of you: > >-Internationalization: I see that the UI has a system for >internationalization, but I don't see a way for UI plugins to >contribute strings to the dictionary without baking their own or >copying the internationalization mechanism. Are there any plans to >dynamically include internationalized strings for a plugin? >[Pranav] - You are absolutely right in pointing that out that the >standard UI- plugin structure doesn't provide support for handling >internalization . But this would not be too tough a task since the need >would be to use the require.js framework to load the user's own >dictionary and update the existing dictionary.jsp with the new sets of >strings present in the user's own dictionary file. It seems , just >about tweaking and introducing the current UI plugin framework. In fact >that is how , the plugin code behaves and updates the existing code >when the plugin is loaded. > >-Wizard, Dashboard and Infrastructure-like Widgets: The list view and >detail view widgets are really cool and super easy to use. In our >plugin we'd like to be able to create our own wizard in a similar >fashion to the instance and zone wizards. We also really like the look >of the Infrastructure and Dashboard pages and would like to create >something similar as a landing page for our plugin. So far we've made a >Infrastrucute-like page by copying some of the code from the >Infrastructure page, but it's not all that pretty. Are there any plans >to abstract out some of the wizard creation logic from those two >wizards to create wizard widget and/or a widget like the Dashboard and >Infrastructure pages? > > >[Pranav] - If you observe carefully , the widget creation logic is >handled in the js files( zoneWizard.js/dashboard.js) present in the >UI-custom directory inside the UI folder and the other widgets like >listView.js /detailView.js but the triggering of the API calls and >invoking the widget framework functions is handled in the js files >present directly in the UI folder (eg system.js) . So ideally , we >already have a layer which is segregating the widget creation and >widget-invoking/API calls functionality . I know the infrastructure >code is too huge to handle and that is why all new features which would >be developed would be developed in the form of UI modules (Eg - CISCO >asa >100 support / vnmcNetworkProvider / VPC) . > > >-Unquoted JSON values: Some will claim this is a bug on our side, some >would say it is a CS bug, so we'll see what people think... The JSON >spec says that numeric and boolean values do not need to be quoted. >However, throughout the UI code, values are taken from data providers >and directly checked like: > >if (value) { > // do something >} > >This causes problems when value is 'false' or '0' (without the quotes). >The simpler solution may be to make our server quote all values >(including numerics and booleans), but I just wanted to bring up that >the UI code will not work despite input meeting the JSON standard. > >- We use a converter when you have values such as "false" or 0 being >sent in the JSON response. The converter is present in >sharedFucntions.js file which handles such cases . I am not sure if >this is what you expected to know or I misinterpreted your concern here . > >Thanks, >Chris >-- >Chris Suich >chris.su...@netapp.com >NetApp Software Engineer >Data Center Platforms - Cloud Solutions Cisco, Citrix & Red Hat > >-----Original Message----- >From: Pranav Saxena >Sent: Thursday, June 13, 2013 9:58 AM >To: dev@cloudstack.apache.org >Cc: Brian Federle >Subject: RE: UI Plugin Questions > >Please see comments inline - > >Thanks, >Pranav >-----Original Message----- >From: SuichII, Christopher [mailto:chris.su...@netapp.com] >Sent: Thursday, June 13, 2013 8:11 PM >To: dev@cloudstack.apache.org >Subject: UI Plugin Questions > >Hi everyone, first time poster here... > >I've started working on a UI Plugin and have come across a few things >I'd like to inquire about and run by some of you: > >-Internationalization: I see that the UI has a system for >internationalization, but I don't see a way for UI plugins to >contribute strings to the dictionary without baking their own or >copying the internationalization mechanism. Are there any plans to >dynamically include internationalized strings for a plugin? >[Pranav] - You are absolutely right in pointing that out that the >standard UI- plugin structure doesn't provide support for handling >internalization . But this would not be too tough a task since the need >would be to use the require.js framework to load the user's own >dictionary and update the existing dictionary.jsp with the new sets of >strings present in the user's own dictionary file. It seems , just >about tweaking and introducing the current UI plugin framework. In fact >that is how , the plugin code behaves and updates the existing code >when the plugin is loaded. > >-Wizard, Dashboard and Infrastructure-like Widgets: The list view and >detail view widgets are really cool and super easy to use. In our >plugin we'd like to be able to create our own wizard in a similar >fashion to the instance and zone wizards. We also really like the look >of the Infrastructure and Dashboard pages and would like to create >something similar as a landing page for our plugin. So far we've made a >Infrastrucute-like page by copying some of the code from the >Infrastructure page, but it's not all that pretty. Are there any plans >to abstract out some of the wizard creation logic from those two >wizards to create wizard widget and/or a widget like the Dashboard and >Infrastructure pages? > > >[Pranav] - If you observe carefully , the widget creation logic is >handled in the js files( zoneWizard.js/dashboard.js) present in the >UI-custom directory inside the UI folder and the other widgets like >listView.js /detailView.js but the triggering of the API calls and >invoking the widget framework functions is handled in the js files >present directly in the UI folder (eg system.js) . So ideally , we >already have a layer which is segregating the widget creation and >widget-invoking/API calls functionality . I know the infrastructure >code is too huge to handle and that is why all new features which would >be developed would be developed in the form of UI modules (Eg - CISCO >asa >100 support / vnmcNetworkProvider / VPC) . > > >-Unquoted JSON values: Some will claim this is a bug on our side, some >would say it is a CS bug, so we'll see what people think... The JSON >spec says that numeric and boolean values do not need to be quoted. >However, throughout the UI code, values are taken from data providers >and directly checked like: > >if (value) { > // do something >} > >This causes problems when value is 'false' or '0' (without the quotes). >The simpler solution may be to make our server quote all values >(including numerics and booleans), but I just wanted to bring up that >the UI code will not work despite input meeting the JSON standard. > >- We use a converter when you have values such as "false" or 0 being >sent in the JSON response. The converter is present in >sharedFucntions.js file which handles such cases . I am not sure if >this is what you expected to know or I misinterpreted your concern here . > >Thanks, >Chris >-- >Chris Suich >chris.su...@netapp.com >NetApp Software Engineer >Data Center Platforms - Cloud Solutions Cisco, Citrix & Red Hat
