Skip to main content

The FDB App in Vue

In the last installment, we thought we could clone a folder tree and get a working project, but...no. Vue likes to be in charge. The vue create fdb command line works perfectly, thankyouverymuch.

So, we turn to our UI design and find that it breaks down into Views and Components quite easily.

Like the Todo app from the tutorial, our layout has a common Header consisting of 3 nav buttons and a Search Component.

Views


  • ListView - headlines a list of films, people, or companies with a filter box. See them all at first (we have 3000+ people), then type until you see the one you want. Also includes an Add button.
  • RecordView - the headline for a film or person form. The form looks like a display until you click, when the edit box appears. If you clicked the Add button, this will be an empty form. Otherwise, it will show a single record. There are 3 tabs, but the second and third tabs show relationships and are not editable.
  • ResultsView - Displays the results of a Search, grouped by Films, People, and Companies. A filter box refines the search.

Components

  • Header - 3 nav buttons, Search
    • Search box - Enter = perform search
  • List - title, add button, filter text box, sort order controls
    • ItemList - Films or People
      • Item -Film or Person
    • CompanyTable - Editable table of companies (2 fields)
  • Record - title, set of 3 tabs, images, cancel button, add/update button
    • Tab1 is a form that displays basic fields for Film or Person
    • Tab2 is more fields from that form (Film)
    • Tab3 is a static display
    • Tab4 is a form that displays basic fields for Person
    • Tab2 is a static display
    • Tab3 is a static display
  • SearchResults - 3 lists, basically
  • AddCompany - Pop-up dialog

Router

Back to the tutorial, because I think we have to load another package/dependency. We could use npm, but the tutorial uses vue ui. In the Plugins page, there are buttons for adding vuex and vue-router. Adding vue-router overwrites the App.vue file
  • The Nav buttons are:
    • Film DB (Home) - / [ListView for films]
    • People - /people [ListView for people]
    • Companies - /companies [ListView for companies]
  • Clicking a Film or Person in the list switches to
    • Film - /film [RecordView for film]
    • Person - /person [RecordView for person]
  • Clicking the Add button
    • Home (Films): Film with 0 id
    • People (People): Person with 0 id
    • Companies: Displays AddCompany dialog
  • Clicking the Update button (Film and Person records only)
    • Processes the update and returns to the Film or Person page
  • Clicking the Cancel button (Film and Person records only)
    • Re-fetches the record and re-displays the page
  • Enter when the Search box is not empty and has the focus
    • Goes to /results





Comments

Popular posts from this blog

CSS for Tables

Tables still have a place--for tabular data. Duh. Such as the Companies table in FDB. But I had to remember the CSS around tables. First, the basic structure: table   thead     tr       th   tbody     tr       td Table border-collapse: { separate (default) | collapse } border-spacing: { #both | #horiz #vert } - default is 1px empty-cells: { show (default) | hide } table-layout: { auto (default) | fixed } - fixed is like !important for widths For a responsive table, put it inside a container (e.g., div) with overflow-x: auto; Width, height, border can be applied to table, th and td--not tr, thead or tbody. Cells th and td tags. CSS doesn't seem to like naked th and td. Prefer table td or table th selectors. text-align: { left | center | top } vertical-align: { top | bottom | middle } padding (margin doesn't do anything; use border-spacing) border-bottom: - for just horizontal lines between rows Rows For a mouse-over to select whole rows at a time: tr:hov

A JSON Db Product?

The last post "solved" the problem of many-to-many table joins by papering over the association table with a RESTful JSON interface. As long as we're using JSON, we might as well take advantage of multi-valued table cells. I'm naturally wondering where this leads. JSON identifiers and types and SQL identifiers and types overlap so much that their intersection is a useful subset. Camel-case fields in string, number, bool flavors. Many-to-many occurs often in the world: Students in Classes Actors in Films (musicians on recorded songs) Parts in Assemblies Customers and Products (joined by Orders) The generalized description is that a Table requires a unique identifier for each row. Tables list students, actors, films, customers, and so on.  An Association Table is has two or more foreign keys that match unique identifiers in other tables. The knowledge of how a FK maps to a specific Table is baked in--we wouldn't want a "table name" column.

GraphQL is the many-to-many solution

Exactly! Regular readers of this blog (me) will appreciate my stumbling attempts to pre-define a REST interface that supports many-to-many interfaces. GET a class, for example, and the return includes an array of the students in that class. In this context, we don't want a full Student record, just the Student's name and Id, for example. With a REST interface, the server writer has to guess how to abbreviate the Student record. GraphQL fixes that. The front end requests just the data it wants. If we want a list of the students in a class and the assigned roommates for that student...we can do that! A lot of my prototype REST service is hardwired--not single tables, so much, but the many-to-many stuff certainly. There was a certain amount of work implementing the simple router ("/table/recordno"). GraphQL means throwing a lot of that away, but I can see immediately that GraphQL's approach is what I want. My schema tables (implementing INSERT and UPDATE) look