Generalization of the project information structure

[javagl]

^{Parts of this had originally been in a comment in anyother PR. But this PR was now narrowed down to the UI changes, so it may make more sense to summarize the points about the "data model" here:}

I think that the IProjectInfo is the central place that will have to be reviewed and possibly changed in order to generalize the project explorer as to become an "Ecosystem Explorer".

The id, name, description and link fields are generic enough to be applicable to basically everything, so they can probably remain as they are.

The other fields are already specific for software projects, and maybe even specific for glTF. Some of them have already been part of some discussion - for example, task might be changed to keywords...

In view of #88 , there would be entirely different properties - probably something like author and conference or publisher (nah, not all the possible BibTex properties, but maybe some of them...).

Now, the specific properties are currently "linked" to the UI part - throughout the code, without any abstraction: Starting at the IProjectInfo, they also appear in IUpdateFiltersAction, various functions, down to the tailwind.config.js, where the background color of one button is stored via { theme: { extend: { colors: { filter: { task: "#ffdac1", ... } } } } .... This makes it difficult to generalize anything, and every change (even just renaming task to keyword) would affect every part of the code (and I don't know how someone should find that tailwind config entry - it took me a while to figure out where this color comes from...).

I'm not sure about the possibilities or "best practices" for generalizing the UI-specific part, but maybe that can be decided later. Starting from the "modeling side", one could imagine structures like these:

interface IProjectInfo {
  id: number;
  name: string;
  description?: string;
  link?: string;
}
interface ISoftwareProjectInfo extends IProjectInfo {
  license?: ProjectLicense[];
  type?: ProjectType[];
  language?: ProjectLanguage[];
}
interface IArticleProjectInfo extends IProjectInfo {
  authors?: string[];
  publisher?: string[];
  language?: string[]; // Not the programming language here, of course :-) 
  ...
}
// Maybe even an "IGltfSoftwareProjectInfo extends ISoftwareProjectInfo"...

These properties could, very roughly speaking, correspond to the "database schema columns". Then, it would be necessary to be able to access these properties programmatically (and not with instanceof). I thought that it would be great to have something that describes the structure of entries similar to a JSON schema:

"entryStructure": {
    "name": { 
        "type": "string",
        "description": "The name of the project that will be displayed in the title"
     }
    "description": { 
        "type": "string",
        "description": "The description that will appear in the detail view"
     },
     ...
     "inputs": { 
        "type": "string[]",
        "description": "An array of strings that are the file extensions of input file formats"
     },
}

and basically make the IProjectInfo generic enough to be able to define the structure of an IProjectInfo with such a file. (And ... maybe this file could also have a "backgroundColorForTagFilterButton": "0xCAFEBABE" for each entry...)

One could probably make some simplifying assumptions for mapping this to the UI. For example, one could require that each property is just represented as an array of strings. Even if it is something like a publicationYear for an "Article": Modeling this as a string[1] looks quirky, but far less than trying to encode and process(!) arbitrary type information generically.

[javagl]

A first pass for this generalization has been drafted in #154

Based on the state that is described there, here are a few more specific questions (even though some of them have been mentioned above already)

• Should the value type always be string[]?
  There could be value types that are just a single string, or a number, or even a number[] array. Iff there should be any functionality that is "type specific" in this regard, it might be necessary to create a more sophisticated solution. Think about a property like gitHubStars : number, and an option to sort by this, or even computing statistics like min/max/avg for some property...
• Where and how to define the properties?
  Currently, they are hard-coded as a set of strings, called ProjectProperties.
• How to define the usage of the properties?
  Specifically: It is currently possible to filter by some of these properties, but not by all of them. This is also hard-coded right now, via ProjectFilterProperties.
• Should properties always be 'flat', or should they be allowed to be 'structured types'?
  Something like a 'date' could be modeled as three properties, year,month,day, or as a class Date { year, month, day }.
• How to model relations with this structure?
• How to map this to a persistence layer?

Many of these questions are related to the idea of a "schema-like" description of the project structure. The complexity of the actual solution for that will depend on the answers to the questions above. I think that we could get pretty far with a simple schema definition. But while fleshing that out, the topic of persistence should be kept in mind. (For example: We could probably add type information to such a schema. But how will that type information be reflected in the database?). Related to that: I stumbled over https://github.com/typeorm/typeorm , which may be worth a closer look. But I assume that we'd try to keep the IProjectInfo structure for the UI (and simple client-side operations), and try to keep that separate from the persistence layer as far as reasonably possible.

@weegeekps Maybe you want to add your thoughts, or have a short look at the PR (even though it is an early draft)

[javagl]

I noticed that the generalization has not been applied at

glTF-Project-Explorer/src/components/ProjectCard.tsx

Line 27 in f76f70e

{shouldShowSection(project.task) && (

: The project card should refer to the ProjectProperties, in order to find out the properties that are supposed to be displayed in the bullet point lists. I'll update that soon, and check whether there are other places affected by the generalization.