-
Notifications
You must be signed in to change notification settings - Fork 0
Object model
Brainstorming
For models I want to start simple and not bloat them with what we think we'll need until we need it -- up to a certain point. We haven't imported any data yet, and there isn't yet a lot of code that will be affected if we make changes at this point. We still have a lot of freedom to change models.
A lot of fields are freeform text -- they will stay freeform text unless some structure is called for.
Right now I have these in an app named supportingmaterials because I wanted a general
name for the concept. Is that illnamed?
Questions
- Are the models good, bad, poorly named?
- What information would you want to include, justify your answer
- Revisit taxonomies
- Do not go crazy defining taxonomies.
- Do we want to manage taxonomies? (no, it is a headache.)
- What conventions were followed in creation of the taxonomies? (hopefully not none)
First pass at this was defined by what metadata is available from scraping the old site.
- corresponding_author: one to one, Member. is a user. will be able to edit
- collaborators: many to many, Collaborator. not users
- supporting materials, one to many
- status: determines visibility
- title: freeform text
- abstract: freeform text
- document optional. filefield
- journal: optional. freeform text (illnamed, journal is too specific)
- article_url: optional
- slug: text that is constrained to ascii letters, numbers, underscores, dashes
- tags: optional. for tagging system
- legacy id: optional (for being able to preserve legacy urls)
First pass at this was defined by what metadata is available from scraping the old site.
This was defined for the most simple version, which would be a person uploading files without any indication of type at all. Eventually there will be code, data, parameters, outputs. Maybe this model should get killed.
- status: determines visibility
- companion_article: many to one, CompanionArticle
- name: freeform text
- archive_file: optional. regardless of whether we link to an external repo, we might want our own copy because external repos can vanish. obviously everything isn't going to be a file, but see opening paragraph. for now, we have some proof-of-concept pages from the legacy site, and all they have are files.
- explanatory text: optional. freeform text
- materials_url: optional.
- tags: optional. tagging system.
- user: one to one to django user
- status: determines visibility
- public name: optional. freeform text
- website: optional
- byline: optional. freeform text. (could be used for affiliations, titles, etc.)
- biography: optional. freeform text.
- gravatar_email: optional. private. works with gravatar avatar system. we could add our own avatar system later.
- tags: optional. for tagging system.
Going to drop this, but wanted a simple as possible way to list short news items at the very first. I think a news system should be richer than this.
- newsbrief: plain text field
- publication_date: date time field
- question: plain text
- answer: plain text
- uses the django flatpages model. probably we'd want something richer at some point.