metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From merrimanr <>
Subject [GitHub] metron pull request #620: Metron-988: UI for viewing alerts generated by Met...
Date Mon, 17 Jul 2017 21:35:43 GMT
Github user merrimanr commented on a diff in the pull request:
    --- Diff: metron-interface/metron-alerts/src/app/service/data-source.ts ---
    @@ -0,0 +1,62 @@
    + * Licensed to the Apache Software Foundation (ASF) under one
    + * or more contributor license agreements.  See the NOTICE file
    + * distributed with this work for additional information
    + * regarding copyright ownership.  The ASF licenses this file
    + * to you under the Apache License, Version 2.0 (the
    + * "License"); you may not use this file except in compliance
    + * with the License.  You may obtain a copy of the License at
    + *
    + *
    + *
    + * Unless required by applicable law or agreed to in writing, software
    + * distributed under the License is distributed on an "AS IS" BASIS,
    + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    + * See the License for the specific language governing permissions and
    + * limitations under the License.
    + */
    +import {Observable} from 'rxjs/Rx';
    +import {Injectable} from '@angular/core';
    +import {Http} from '@angular/http';
    +import {Alert} from '../model/alert';
    +import {ColumnMetadata} from '../model/column-metadata';
    +import {ColumnNames} from '../model/column-names';
    +import {TableMetadata} from '../model/table-metadata';
    +import {SaveSearch} from '../model/save-search';
    +import {AlertsSearchResponse} from '../model/alerts-search-response';
    +import {SearchRequest} from '../model/search-request';
    +export abstract class DataSource {
    +  defaultHeaders: {'Content-Type': 'application/json', 'X-Requested-With': 'XMLHttpRequest'};
    +  constructor(protected http: Http) {}
    +  // Calls to fetch alerts
    +  abstract getAlerts(searchRequest: SearchRequest): Observable<AlertsSearchResponse>
    +  abstract getAlert(index: string, type: string, alertId: string): Observable<Alert>
    +  abstract updateAlertState(request: any): Observable<{}>
    +  // Calls to fetch default alert table column names and all the field names across all
    +  abstract getDefaultAlertTableColumnNames(): Observable<ColumnMetadata[]>
    +  abstract getAllFieldNames(): Observable<ColumnMetadata[]>
    +  // Calls to rename field names and to fetch the renamed field names
    +  abstract getAlertTableColumnNames(): Observable<ColumnNames[]>
    +  abstract saveAlertTableColumnNames(columns: ColumnNames[]): Observable<{}>
    +  // Calls to fetch and save alerts table settings like refresh interval, page size,
default selected table column names
    +  abstract getAlertTableSettings(): Observable<TableMetadata>
    --- End diff --
    Does this mean we will have one service for all calls to the REST api?  I don't think
it will evolve that way, at least from a REST perspective.  ES endpoints are likely to be
separate from endpoints that persist user session data (like saved searches) and will have
separate controllers and services in the REST application.
    Assuming that's true this should be split up to match the endpoints in the REST layer
once they are implemented.  I feel like it's much easier to understand this code base when
the services are well-organized, more granular, and match the REST services.  I don't think
it's critical to have it separate now and would be fine doing it later.

If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at or file a JIRA ticket
with INFRA.

View raw message