Hi Gokul, I also think your requirement is valid. If we can use a generic set of visualization components such as pie charts and barcharts, it should be possible to reuse the existing visualization components to bind our data to them easily. In other words visualization component is a blueprint JS library. In USE we can pack some of such useful components out of the box. When someone wants (for e.g., BAM user) to bind data with metadata such as headings, axis names, themes etc. to a visualization component, he should be able to provide them (for example using a JSON object) and deploy a new artifact for the specific scenario. Then when we want to define a KPI, we only have to point to an existing visualization component and generate that JSON object which maps the specific use case. Then that generated component can be deployed in each dashboard.
* Maninda Edirisooriya* Software Engineer *WSO2, Inc. *lean.enterprise.middleware. *Blog* : http://maninda.blogspot.com/ *Phone* : +94 777603226 On Mon, Jul 29, 2013 at 11:32 AM, Balakrishnan Gokulakrishnan < [email protected]> wrote: > Hi all, > > The following is a report on the F2F meeting held with UES folks regarding > using UES gadgets in the BAM KPI implementation. Participants - Anjana, > Sinthuja, me, Ruchira, Madhuka, Praveena. > > For the BAM use case, it is required to represent the outcomes of KPI > definition via gadgets. For this purpose, we require the gadgets to be > customisable on a level such that multiple users can share a specific > variation of a gadget, with new users(added after gadget creation) being > able to see the custom gadget from the start. Options for customisation may > include labels for axes, titles and so on. For instance, it should be > possible for a barchart gadget to exist as "sales-barchart" and > "marketing-barchart" at the same time. > > Currently, UES gadgets are rendered based on the gadget XML available on > the file system and any preferences that have been defined. The parameters > may be of two types: user preferences and module preferences. User > preferences are specified by the user and may contain information such as > gadget placement etc. and are specific to that particular user. Module > preferences are tied to the gadget itself (via its source) and are not > meant to be changed dynamically. > > Since there is no intermediate level (such as a copy in the registry) in > which a gadget is stored so that there could be more than one > representation of the same gadget, we have decided to go with spawning > variations of gadgets for each customisation for the time being. > Specifically, we will need to perform the following actions: > > -Add a gadget and create a new page/site > -Add a gadget to a pre-existing page/site. > > It is our intention to go with the JS APIs used by UES for the above > functions. @UES Team please provide us with details on the APIs and their > usage for the above. @All please add anything that I may have > missed/misinterpreted. > > Thanks, > Gokul. > -- > *Balakrishnan Gokulakrishnan* > Software Engineer, > WSO2, Inc.; http://wso2.com > > Twitter: http://twitter.com/gokulbs > Mobile: +94775935789 > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
