Skip to content

Thoughts on major pattern (etc) tables redesign.... #69

Description

@publicsphere

Forgive me if you had already suggested this! At any rate, I don't think we need a list of features for each pattern type (e.g. a Liberating Voices pattern, groupworks pattern) as I was envisioning. I think we need one long feature list (contained in a single table, pattern_feature) that includes feature_name, feature_id, feature_type (image, etc.), and title / notes (and maybe "aliases"?). It would be useful soon and is easily developed. This approach has some very useful traits, like being able to build new pattern type and view templates easily.) A feature_view table would have the features that were used within a pattern context and the order in which they were used. (view_id, feature_id, order) Also a views table that contained view-id and views_name / notes.

(I think that) we would still need a pattern_view table that would include pattern-view-id, pattern-id, view-id, and title / notes fields. (And regardless of whether a entry existed in that table, a pattern (or list of patterns) could use any view.)

Also, needed, a pattern set contains patterns using a pattern_set table. The patterns could be ordered in various specific ways a pattern_set_view table.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions