The first part of the site I plan to redo is the wall coverings section. Looking purely from a model schema view, the wall coverings fall under one of two baseline paper collections (China Wall and Caravan). Here is how I see the model for the collections looking (I am using shorthand here but it should be obvious how this will translate into an App Engine model definition).
BaseCollection:
"""A base paper collection (e.g. Caravan and China Wall)."""
name = String
one_liner = String
description = Text
Nothing fancy and covers the basic text needed for the collections. Now within each collection there are color lines and what I call "fancy" lines (i.e. paper lines with more than just color added). For the color lines (e.g. Imperial Scrolls), the model is very much like the BaseCollection model.
ColorLine:
"""A color line (e.g. Imperial Scrolls)."""
base_collection = Reference(BaseCollection)
name = String
one_liner = String
Beyond the reference to
BaseCollection there is really nothing special here. By adding the reference back to BaseCollection instances of the class will grow a colorline_set attribute the contains the models that reference that instance.But having some text to explain a color line is rather useless without the individual papers that make up a color line.
PaperColor:
"""A color of paper."""
name = String
picture = Blob
color_line = Reference(ColorLine)
With this model I will be able to store the scanned color samples of the paper and associate them with the proper color line. This will give me a
papercolor_set attribute on ColorLine instances, making it easy to generate those color swath pages.But all of this was the easy stuff. The tricky part is the fancy lines (e.g. Linea). For these fancy lines they are associated with a specific color line along with the customization options. Since my father has been in the wall covering business for over a decade and so far every fancy line they have has no more options than patterns and one other custom thing, I think I can handle those cases with three models.
Pattern:
"""A single instance of a pattern for a FancyLine (e.g. a single pattern
for Linea)."""
fancy_line = Reference(FancyLine)
name = String
picture = Blob
FancyOption:
"""An option for some paper (e.g. pen ink color)."""
name = String
description = Text (?)
# fancyline_set
# option_set
Option:
"""A single option for a FancyOption (e.g. slate pen color)."""
fancy_option = Reference(FancyOption)
picture = Blob
name = String
Pattern is an instance of a pattern for a fancy line. Since patterns are not shared I don't think a model to collect the patterns separately from a FancyLine instance is needed. As for FancyOption, I made that collecting model since it can be shared between lines (e.g. all the lines that use pens have the same color options since the same set of pens are used). Each option is thus covered by an Option instance which will store some scanned representation of the option.But this is where my rudimentary web site experience ends, and unfortunately there is more to do. I still have to have installation examples. I am thinking of doing a model that takes an upload of a full-size photo and auto-generates the thumbnail upon upload (should be easy with the images API from App Engine). Trick is then somehow pulling from these to show up in the sidebar of their respective paper line pages. I am thinking that adding a boolean to the model so that a simple filter for the photos with the boolean set to true will be enough to pull up the preferred installation photos for the main pages.
I also have to deal with the flame spread reports. There are only three of them: one for each base paper and one for a specific fancy line. That means dealing with the single outlier. I am tempted to make a model for the reports, have a blob for a PDF, and then having a generic reference in the model to the most generic line it represents. That way I can check if for each line if the instance has a
flamespread_set or whatever with an instance to know whether a special flame spread report exists.And then there are installation instructions which are in a similar spot as the flame spread reports.
I think all of these models cover what I need. Hopefully I have not generalized too much or painted myself in a corner. I don't think any of this will make adding or editing content by my father on his own too difficult (which is the entire reason I am redoing the site), especially if I make sure that the forms to change stuff is dead-simple.
And if I am doing something silly, please let me know.
