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
