Skip to content

Latest commit

 

History

History
323 lines (279 loc) · 13.7 KB

TODO.md

File metadata and controls

323 lines (279 loc) · 13.7 KB
Raw

TODO

RestEndpoint Model

  • trigger an event in fetch() that short-circuits if a listener returns a RestEndpointEntity, and return it if stopped().
  • Test and write delete() functionality

DB-Connected Model

  • Test createService() functionality
  • Test and write a listener for RestEndpointModel::fetch that will check for the ResourceClass inside the api-tools configuration. The event should pass both the discovered RestEndpointEntity as well as the application configuration. If db-connected configuration is found, create a DBConnectedRestEndpointEntity and return it.
  • Test and write updateService() functionality
  • Test and write delete() functionality

RestModel Resource

  • In create(), detect the type of RestEndpoint being sent based on features. If the data includes a table_name, pass it on to the DbConnectedRestEndpointModel.
  • In patch(), first fetch() the RestEndpoint, and based on the type, determine which model to pass it to.
  • Implement delete(), and do it similar to patch().

Documentation

  • Add api-tools-documentation as a required dependency of api-tools
  • Add a settings screen for api-tools-documentation
    • Capture route endpoint for docs
    • Allow specifying a ContentNegotiation selector for the route endpoint

Admin UI Improvements

Technical improvements

  • Integrate Bower into workflow
  • Integrate Grunt into workflow
  • Refactor application into one controller/directive/filter/service per file. (Although multiple related directives may be in the same file.)
  • Switch to ui-router
  • Switch to angular-ui-bootstrap
  • Remove Hyperagent (in favor of either $http, $resource, or Restangular)
  • Add unit tests
  • Add end-to-end tests

General

  • Have a consistent color scheme.

    • It should be consistent with the Laminas, Laminas, and/or Laminas API Tools website color scheme. This should pull through to the panel titles, sidebars, table highlights, etc.

    • Related: button colors need to be consistent throughout, and based on actions. Etay's suggestions:

      • blue for "create" actions
      • green for "save" or "update" actions
        • use consistent verbiage -- either "save" or "update", but not both
      • make cancel buttons just plain text or white
      • confirmation for destructive actions should be red

  • Consistency in form layouts. All forms should have the same layout, either left/right, or stacked. Buttons should always be in the same place (and to the right is preferred).

  • For the lists with collapsible panes:

    • clicking anywhere on the bar should do the collapse/expand action
    • if the title is editable, use a double-click to activate that
    • put the "remove" icon to the right, with an "edit" icon to its left (if editable); these icons should only be visible on hover.

  • Every section - db adapters, authentication, rest services, etc. - should have a title in its main pane.

  • Icons

    • Consider using icons instead of text badges for different resources
    • have a glossary of these somewhere.

  • Every resource should be addressable, to allow linking to them directly.

  • The topnav should have "Settings" and "APIs" items. The latter may be okay as a dropdown with the various APIs available.

  • Consider adding breadcrumbs, to make it clear the relation/hierarchy of the current active item.

  • Consider having search inside the tool, to allow surfacing the various resources quickly. This may require having tags/descriptions/etc. for each resource that can be queried.

  • Check the modal dialogs to ensure they never fill more than 80% of the screen; the content in them should be scrollable.

  • Make flash messages positional - have them as close to the action as possible. Consider disabling the button that was clicked and/or changing to a "working" status (or spinner).

  • Create a real dashboard only after all features are complete. This should be an area that has documentation and/or links to docs, buttons for first actions, etc. Potentially, it could also list APIs, or list APIs missing services, etc.

  • "Remove" dialogs

    • "Remove" dialogs should be color-coded. Red, thicker border, potentially pink or faded red background, and red "remove" or confirm button.
    • Remove word "successful" from flash message
    • Maybe move flash message to replace the item removed?

  • Consider doing some browser and/or screen size detection, and popping up a modal dialog when suboptimal platforms are detected in order to warn the user.

"Dashboard"

  • Breadcrumbs: "Settings"
  • Title: Settings
  • This should actually be titled "Settings" (or "Application-wide Settings"), and should not be the main dashboard.

DB Adapters

  • Breadcrumbs: "Settings -> DB Adapters"
  • Title: Database Adapters
  • Add a page title, and navigation breadcrumbs: "Settings -> DB Adapters"
  • Make this more wizard-like. When you choose to create a DB adapter, first select the adapter type you wish to create, and then expose the options necessary for that adapter type. (Do this like we did with validator and filter options.)
    • Show on the right what fields are required, so the user has a visual cue.
  • Make all adapters addressable
    • Make edit state for each adapter addressable
  • Changes to collapse items:
    • remove "DB Adapter" text label; instead, use an icon with a hover title.
    • remove tabbed view
    • "view" mode by default
    • "edit" button in titlebar, visible only on hover, to toggle view mode to "edit"
    • Edit form should have a "cancel" button
      • to return to "view" mode
      • revert any changes.
      • Cancel button should just be text (think iOS7).
    • Edit form: same style as REST/RPC service edit forms
    • "remove" dialog
      • should be color-coded. Red, thicker border, potentially pink or faded red background, and red "remove" or confirm button.
      • Remove word "successful" from flash message
      • Maybe move flash message to replace the item removed?

Authentication

  • Breadcrumbs: "Settings -> Authentication"
  • Title: Authentication
  • Add a page title, and navigation breadcrumbs: "Settings -> Authentication"
  • Be explicit: "Select ONE of the authentication methods below for your application"
  • Remove the words "Setup" and "Authentication" from the buttons
    • Make sure they stack nicely when on narrower screens, or stack always
  • Make edit state addressable
  • Details screen:
    • Have "Edit | Remove" buttons on title bar, visible on hover
    • Clicking "edit" switches to an edit form; otherwise a "view"
    • Edit form
      • should have a "cancel" button to return to "view" mode
      • revert any changes.
      • Cancel button should just be text (think iOS7).
    • Edit form: same style as REST/RPC service edit forms
    • "remove" dialog
      • should be color-coded. Red, thicker border, potentially pink or faded red background, and red "remove" or confirm button.
      • Remove word "successful" from flash message
      • Maybe move flash message to replace the item removed?

APIs

  • Breadcrumbs: "APIs"
  • Title: APIs
  • Create a landing page for APIs
    • List all APIs, and link to them.
    • Potentially provide the API description for each, when present
    • Consider having badges:
      • Green or similar for APIs that appear to have complete information
      • Red for APIs that may need additional configuration to be complete
        • Hover dialog that would link to action items, such as documentation
    • "Create API" goes on this page. It should be a form, and always present (no need to click a button to make the form appear).

API Screen

  • Breadcrumbs: "APIs -> {API name}"
  • Title: {API Name} API (latter in a different color; gray?)
  • Display API description, if available. Otherwise, have dummy text. Double click of text allows you to edit, and displays "cancel" and "save" buttons.
  • Versioning
    • Allow specifying version identifier
      • This may require some changes in the backend, as we have to do some normalization between version identifiers and namespace!
  • Sidebar Organize so that the most important items are first
    • Overview
    • REST Services
      • Add a green checkmark if we have any REST services
      • Add a red X if no services (of EITHER type) are defined
      • No badge if none defined, but RPC services are defined
    • RPC Services
      • Add a green checkmark if we have any RPC services
      • Add a red X if no services (of EITHER type) are defined
      • No badge if none defined, but REST services are defined
    • Authorization
  • Link to each service; do not just list
    • Each service individually
    • Specific tab in the service
    • View vs Edit state for the tab
  • If no services:
    • "You have not yet created any services; would you like to?" and do a modal
    • "Would you like to?" and do a modal drop down in place.
    • Red badge! (and, conversely, green badge or check mark if services exist!)

REST/RPC Services

  • Breadcrumbs: "APIs -> {API Name} -> (REST|RPC) Services"
  • Title: REST|RPC Services
  • If no services:
    • "You have not yet created any services; would you like to?" and do a modal drop down in place.
  • Allow addressing services. Addressing them will expand the specific collapse box and focus it.
    • Ideally, also allow addressing each tab inside the collapse box, and, potentially, whether or not the state is view or edit
  • Naming
    • Consider allowing the ability to configure a name for each service
    • have a method for normalizing the name in the UI based on rules. Thus, Status\V1\Rest\Status\Controller becomes just Status in the UI.
  • Collapse lists
    • remove "(REST|RPC) Service" text label; instead, use icons with hover titles.
    • "view" mode by default
    • "edit" button in titlebar, visible only on hover, to toggle view mode to "edit" (far right)
    • "remove" button in titlebar, visible only on hover, to display "remove" dialog (farthest right)
    • Tabs within:
      • View mode:
        • Settings
        • Fields
        • Documentation
        • Source Code
      • Edit mode:
        • Settings
        • Fields
        • Documentation
    • Edit forms
      • should have a "cancel" button to return to "view" mode
      • revert any changes.
      • Cancel button should just be text (think iOS7).
    • "remove" dialog
      • should be color-coded. Red, thicker border, potentially pink or faded red background, and red "remove" or confirm button.
      • Remove word "successful" from flash message
      • Maybe move flash message to replace the item removed?
  • View/Edit
    • Have collapse sections of grouped settings
    • Potentially red X/green check to denote completeness of sections
    • Consider a "validate" button; i.e., validate that the settings will work prior to submitting
    • Put "plain text" descriptions next to each HTTP method (Andi's suggestion):
      • GET (read)
      • POST (create)
      • PATCH (partial update)
      • PUT (update/replace)
      • DELETE (remove)
  • Fields
    • Have a separate "view" mode, and make the display simpler for it
    • single click to collapse/expand; double-click to edit field name
    • "remove" button in titlebar, visible only on hover, to display "remove" dialog (farthest right)
    • "add option" button should be blue (or whatever color we use for create), and only show on hover. Put to left of "remove".
    • Use a standard "move" icon for the filters/validators (DONE)
    • Consistent icon size, regardless of nesting
    • Required:
      • Remove "?" from "Required?"
      • Make box smaller
      • Use a toggle instead of a checkbox
    • Options:
      • Use toggles for boolean values
    • "Add" dialogs
      • Frame all "Add" dialogs with a thicker line so as to draw attention to them.
      • "Add ..." buttons should disappear while the form is available
      • "Add ..." forms should be removed once an item is created
    • Make all "add" buttons display on hover over the specific panel only
  • Source Code viewer
    • Check to ensure that the dialog never grows more than 80% of the screen height, and is internally scrollable.

Authorization

  • Breadcrumbs: "APIs -> {API Name} -> Authorization"
  • Title: Authorization
  • See note about normalized names under REST/RPC services; use those names in this table.
  • Move "Save" out of the table; perhaps rename to "Update" (but whatever is used, use it consistently)
  • Add a "Cancel" button
    • to the left of "Save"
    • revert any changes made.
  • Lighten colors on the top and right
  • Change checkboxes
    • Minimum: disable checkboxes for any methods that are not enabled for a given service.
    • Potentially allow toggling; clicking on a disabled one would also enable that method for the service.
      • column/row toggles should never do this, however!