Card Data convention vs. configuration

[armahillo]

"Convention":
Card data would have a set list of acceptable attributes (whitelisted) that would be implemented in the layout. This would allow for a much more precise and slick looking layout in the export (both formats). The downside is that we would be constraining ourselves to a smaller creative space, and the script would require modification to add additional data properties.

"Configuration":
This is the approach currently adopted (mostly) -- users can put whatever the heck they want in the YML file, the only fields sort of required are the name (defaults to "unknown" I think) and quantity (defaults to 1). Everything else gets dumped into a Key:Value pairing in the textbox. This affords maximum flexibility in fields, but makes the cards a little less pretty.

Thoughts? Should there be some additional fields that are canonized into the template?

For example, if we were handling MTG cards:

• mana_cost
• flavor text
• description
• power_toughness
• card_type
• color

Obviously those are a little specific. More generally:

• cost
• description
• type

might be adequate to cover most cards? These would not be required fields, they would just have pre-figured handlers for dealing with them (ie. cost always goes in the same place, type, description as well).

[justinburdett]

I think:

• name
• cost
• type
• description (or maybe "rules text"?)

are worthy of this distinction (so yeah, I agree)

This is maybe outside the scope of this issue, but it might be worth exploring how to easily support multiple templates defined either by type or some other designation? A Planeswalker in Magic has a very different template than a Creature, for example.

[armahillo]

Good point.

If only there was some way to easily codify a card layout.

One possibility would be to create a "Card" class that has "to_html" and "to_pdf" methods. Deck could then just have a collection of these objects. The calculations and other things done with @cards in the Template class could be refactored into the Card class to encapsulate that better.

We could then take the Card base class and dervice a variety of different Card types from it, that would bear different layout options.

Probably should do a "Card" module namespace instead... hm...