Carmel user interface issues

[adriatic]

Catalog admin deals with components - shown below:

where each component has a number of samples:

Our current task is to provide the means to assign a list tags (strings) to each component and each sample for each component.

The second task is to provide the ability to add more samples for any existing component (I do not believe that it would make sense to add new components in a way that is different from what we have now).

[adriatic]

@JeroenVinke comments

Instead of samples beloning to a category or component, we could instead assign a tag to each sample with the control name. A sample would then have an "autocomplete" tag or a "grid" tag. For the menu structure we could then manually define a selection of tags. When you click on a menu item (e.g. "Autocomplete"), it would show samples with the "autocomplete" tag. Ignore me if we are beyond the point of no return.

This information would then have to be defined per tag instead of per component. This could be quite interesting. Lets say that we have a sample with both a grid and an autocomplete control. Then users would like to see documentation (import tags, kendo API documentation url's, our own documentation) for both controls.

In the current setup the "a sample has a single category" datastructure is quite limiting and now that we will have an API and an admin app we can think outside of the box (finally 😄).

[adriatic]

@adriatic responds

We need to clear the air here as it seems to me that we do not see it the same way. I like the terms I am using so far - where the KendoUI bridge perceived as an SDK consists of 60+ Aurelia components, and each component has a number of samples.

In my view looking at just samples (think of names like basic use or binding to local data makes no sense: query "show me all samples with the name basic use" results with a collection of all components - a very useless result.

The current database I created assigns the component name as component's only tag only tag, where no sample has any pre-defind tag. Given that the database "initializer" is derived programmatically from the samples.json used as the "course of all truth in the bridge, we could also define some initial samples tags as well.

Please re-read your above text with this section in mind and see if we are getting closer

[adriatic]

@JeroenVinke writes

The current database I created assigns the component name as component's only tag only tag, where no sample has any pre-defind tag. Given that the database "initializer" is derived programmatically from the samples.json used as the "course of all truth in the bridge, we could also define some initial samples tags as well.

I understand, we have some work to do to create tags which should be a joy with an admin app

Please re-read your above text with this section in mind and see if we are getting closer

I would like to know what the problem was that would be solved by adding the component entity. Reason why I am so persistent is because I have ran into the limitation of categorizing samples by component/categories before, and I do not want us to make the same mistake again.

Specifically, I encountered these issues:

1. A sample may not belong to any component.
2. A samples may demonstrate multiple components
3. We define <require> statements on the category, which applies to all samples within this category. You aren't able to specify these things per sample.

So I worry that we will inherit the same limitations, hopefully you can put my mind at rest 😄

In my view looking at just samples (think of names like basic use or binding to local data makes no sense: query "show me all samples with the name basic use" results with a collection of all components - a very useless result.

I agree, so you need to be able to search more specifically (e.g. "basic use autocomplete"). Is this why the component entity was added? That's what i'd like to know, what are the problems that are solved by this component entity.

[adriatic]

@adriatic

It is possible that my model of the search that this database will make possible, is richer than what you have (after all we did not ever discuss the search issues). So, let me put your mind at ease by saying that components as entities may never appear in the search process - although that should not be prevented. My "hierarchical approach": component (which has it own tags) --> sample (which has its own tags) is solely restricted to the process of creating and editing tags on the catalog admin - it has no bearing on the search implemented in the catalog application itself.

The search sophistication is limited by the additional "navigation atttributes" (term used on the code first approach, which you may call "joins") and while it is safe to say that our initial version will be far from perfect, I would like to "put it up" as alpha, so we can get a lot more folks to help with that.

[adriatic]

This section describes the tagging process when there are no tags to be used as the basis for the search for the object to be tagged. Subsequently, we should use the existing tags for searching, removing the need for this two step search

Also note that this document discussed only the "Bridge Catalog application Editor" - using tags created here is a part of the Catalog itself.

This screenshot is taken for historical reasons as it depicts the applications current UI created using using razor, just to facilitate the database creation process

Let's define tagging process as a two steps process

1. Search for the object to tag
2. Edit (set/ update / delete) the tag(s)

Note that these operations parallel the SQL commands that are being created behind the scenes by ef core on the backend.

---

1. Search

Consists of two sequential steps:

Step 1 Select the bridge component

This could be done on two ways:

1.1 Explicit

Present the view with all components:

... and then select the sample from the list created after the component selection

1.2 Implicit

Use Autocomplete to locate the bridge component

Step 2 Select the sample for the selected component

[adriatic]

2. Edit

Initial state: Assuming that the user selected the autocomplete component Carmel backend delivers the following data (observe that the component already has the "autocomplete" tag set.)

  {
    "name": "Autocomplete",
    "created": "2017-03-05T14:00:46.743392Z",
    "componentTags": [
      {
        "id": 1,
        "cTag": "autocomplete"
      }
    ],
    "samples": [
      {
        "id": 248,
        "name": "with.bind",
        "created": "2017-03-05T14:00:46.743392Z",
        "gist": "2fa190db778824c2b406b10c673ae9ae",
        "sampleTags": []
      },
      {
        "id": 249,
        "name": "highlighting",
        "created": "2017-03-05T14:00:46.7443928Z",
        "gist": "078dec4fe353ff9214ef6d5ee0e091a7",
        "sampleTags": []
      },
      {
        "id": 250,
        "name": "value-binding",
        "created": "2017-03-05T14:00:46.7443928Z",
        "gist": "ba981cf9b774273a75bb6a4dedf21190",
        "sampleTags": []
      },
      {
        "id": 251,
        "name": "grouping",
        "created": "2017-03-05T14:00:46.7443928Z",
        "gist": "5da30e9c363cf37fe3e313476a65edb4",
        "sampleTags": []
      },
      {
        "id": 252,
        "name": "virtualization",
        "created": "2017-03-05T14:00:46.7443928Z",
        "gist": "1abf5f5fbb4d3e1306385506bc676aff",
        "sampleTags": []
      },
      {
        "id": 253,
        "name": "server-filtering",
        "created": "2017-03-05T14:00:46.7443928Z",
        "gist": "65f25b1fb2e07ec4e2749d21136650e7",
        "sampleTags": []
      },
      {
        "id": 254,
        "name": "events",
        "created": "2017-03-05T14:00:46.7443928Z",
        "gist": "625fc6a733b599fa9374d732ae5e696d",
        "sampleTags": []
      },
      {
        "id": 255,
        "name": "customizing-templates",
        "created": "2017-03-05T14:00:46.7443928Z",
        "gist": "f4755c3c68dab68260647851ff9e52a0",
        "sampleTags": []
      },
      {
        "id": 256,
        "name": "api",
        "created": "2017-03-05T14:00:46.7443928Z",
        "gist": "55999353554add4f866b26481f0ad555",
        "sampleTags": []
      },
      {
        "id": 257,
        "name": "basic-use",
        "created": "2017-03-05T14:00:46.7443928Z",
        "gist": "0ddb2e1d4ff26b988382c9150d4fc475",
        "sampleTags": []
      }
    ]
  }

Editing tags

This could be "dirt-simple" as the only restriction on the tag should be its uniqueness.

Editing samples

This function should support the full "CRUD" set of operations to be performed on the sample. For simplicity sake, let's begin with the same functionality that already exists in the bridge catalog app: