As discussed offline. There are pros and cons in both approaches. If you
provide this feature as a Carbon component, you will have to work with the
old jQuery version married to the ui.core. Since your UI is going to be
rich with widgets and charts, there is a possibility to run in to
conflicts. But you can also try to name your files in the component end
with _ajaxprocessor.jsp and not let the Carbon default template and
libraries load. With this approach AFAIK you can inherit the security and
avoid the possibility of conflicts. Having a weird file name will be a con
in this approach.

If you create a separate jaggery web app, of cause you will have to deal
with authentication. Since our new UI framework is there, please try to use
that in your development [1].

1 - https://github.com/manuranga/fuse

thanks,
Chanaka

On Mon, Mar 16, 2015 at 2:06 PM, Isuru Perera <[email protected]> wrote:

> Hi all,
>
> I'm working on a simple UI for Metrics visualization. Few days back, we
> released the first version of WSO2 Carbon Metrics [1], which can send
> output to CSV files, database via JDBC & JMX.
>
> For the Metric Visualization, we will be using the data from database.
> Hence the UI application will be tightly coupled with JDBC and JDBC
> reporting must be enabled.
>
> *User Stories*
>
> As a user, I want to:
>
>    - view metrics data in a timeseries chart with a configurable time
>    period.
>    - compare different metrics.
>    - compare metrics from multiple sources.
>    - save the charts and display those later.
>
> I will send the UI Wire-frames soon.
> *Main Components*
>
>    - REST API - This will be an Apache CXF application. The REST APIs
>    will get the data via JDBC. The responses will be in JSON format.
>    - Metrics UI - This is the main dashboard, which will get data from
>    REST APIs. Metrics UI needs server side processing for loading/storing
>    dashboards etc. Hence the application can be developed as a Carbon UI
>    component or a Jaggery application. The IGViz library [2] will be used for
>    charts.
>
>
> *Concerns*
>
> Both REST API and Metrics UI need authentication & authorization. I
> haven't decided the best way to authenticate REST APIs in Apache CXF
> application. Any suggestions?
>
> For Metrics UI, we need a login page. As I have seen from other
> applications, if we use Jaggery, we need to create separate login pages and
> manage security within the application. For example, API Manager Jaggery
> applications have implemented login pages. The APP Manager uses SSO for
> login. In order to use SSO, we need to use additional Identity Server
> features.
>
> If we create Metrics UI as a Carbon UI Component, we don't have to worry
> about securing the application and we can use existing authorization
> mechanisms for Carbon UI components.
>
> Since Metrics UI is a simple application, I think a Carbon UI component
> approach might be better than creating a separate application in Jaggery.
>
> Please let me know any suggestions/feedback.
>
> Thanks!
>
> [1] https://github.com/wso2/carbon-metrics/tree/v1.0.0
> [2] http://mail.wso2.org/mailarchive/dev/2015-March/044631.html
>
> --
> Isuru Perera
> Senior Software Engineer | WSO2, Inc. | http://wso2.com/
> Lean . Enterprise . Middleware
>
> about.me/chrishantha
>



-- 
Chanaka Jayasena
Senior Software Engineer; WSO2, Inc.;  http://wso2.com/
email: [email protected]; cell: +94 77 785 5565
blog: http://chanaka3d.blogspot.com
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to