The Ed-Fi “Classic Dashboards” are no longer supported through the Ed-Fi Alliance. You can still receive support and maintenance through the Ed-Fi vendor community. Please look at any of the vendors’ dashboard solutions on the Registry of Ed-Fi Badges or the Ed-Fi Starter Kits if you are looking for a visualization solution to use with the Ed-Fi ODS. This documentation will remain available to assist existing Classic Dashboard implementers.
UI Developers' Guide - Application Conventions
The ASP.NET MVC framework is a convention-based framework. The Ed-Fi Dashboard application extends the MVC framework in a number of areas to make development easier and more elegant for the application’s primary use cases. For example, unless there is any special logic that needs to be applied beyond calling a service to retrieve a model, there is no need to add a controller. Similarly, requests for metric data are automatically handled based on the context of the matched route.
The details of these behaviors are described below.
Automatic Service Invocation
The MVC framework has been extended through the EdFiControllerFactory class to automatically create a closed generic controller (using ServicePassthroughController<TRequest,TResponse>) based on the “area” and “controller” data from the matched route. This scenario generally comes into play with the specialized pages (such as the “Overview” pages) and the metric drilldowns, eliminating the need for copious amounts of boilerplate controller code.
The application uses three conventions for matching an incoming web request to a service. It will match a request to a service if it finds:
- a service named “{area}{controller}Service” in any namespace.
- a service whose full name (including namespace) matches “.{area}.{controller}Service”.
- a service whose full name (including namespace) matches “.{area}.Detail.{controller}Service”.
If a matching service is found, the EdFiControllerFactory closes the generic ServicePassthroughController type with the request/response model types identified by reflecting on the service’s interface definition. With a concrete controller type in hand, the normal MVC processing proceeds. The ServicePassthroughController is instantiated and the Get action method calls the service and returns a ViewResult containing the response model. The MVC framework then proceeds with its standard view rendering logic to render the web page.
Automatic Metric Request Handling
The EdFiControllerFactory has also been extended to handle requests for metric data. The factory creates a DomainMetricController<TRequest> type closed with the metric request type which is derived from the “area” route data of the current request.
For example, a request to https://example.com/Districts/SomeSchoolDistrict/Metrics/Attendance-and-Discipline-123 would be matched (based on route definitions) to the “LocalEducationAgency” area. Once the non-generic DomainMetricController<T> type is identified (where, for example, T would be LocalEducationAgencyMetricInstanceSetRequest), the MVC framework reflects on the request model and automatically populates it based on the route data through its standard model binding behavior. Then the controller’s action is invoked, and it calls the DomainMetricService with the appropriate metric set request and returns a ViewResult containing the metric response model.