cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "SuichII, Christopher" <Chris.Su...@netapp.com>
Subject Re: UI Plugin Questions
Date Thu, 13 Jun 2013 18:30:09 GMT
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.suich@netapp.com
NetApp Software Engineer
Data Center Platforms ­ Cloud Solutions
Citrix, Cisco & Red Hat




On 6/13/13 1:52 PM, "Brian Federle" <Brian.Federle@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.Suich@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.suich@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.Suich@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.suich@netapp.com
>NetApp Software Engineer
>Data Center Platforms - Cloud Solutions
>Cisco, Citrix & Red Hat


Mime
View raw message