Expand Template functionality

[iliawx]

Is your feature request related to a problem? Please describe.
I would like to extend the Template struct functionality and wanted to get your advice on the best way to organize the code for it:

1. Would like to restrict minting of Dappies from a template by introducing a retired flag, similar to what the TopShot did.
2. Would like to keep track how many Dappies were minted for each Template.
3. Would like to set a maximum number of Dappies that can be minted for each Template.

Describe the solution you'd like
Here are the most obvious solutions based on CryptoKitties and TopShot codebases:

1. Add the retired flag to the Template struct.
   However, the side effect of it would be passing that information to the Dappy since the data field on a Dappy is a Template.

2. A common approach seems to be a dictionary of totals per Template. For example:

access(self) var mintCountPerTemplate: {UInt32: UInt32}

However, the Template struct itself seems to be a more logical place to keep track of the minted Dappies count.

3. Add the maxQuantity flag to the Template struct itself similar to the suggested place for the retired flag above.
   However, the same problem as in 1 above. That information will be passed on to the Dappy via data and that's not a good place for it.

Describe alternatives you've considered

Solution 1: Introduce a DappyData struct and move all the current Template fields there. Also, add template-specific fields to the Template struct.

public struct DappyData {
    pub let templateID: UInt32
    pub let dna: String
    pub let name: String
    pub let price: UFix64
...
}

pub struct Template {
    pub let templateID: UInt32
    pub let data: DappyData
    pub let maxQuantity: UInt32
    access(self) retired: Bool
    access(self) mintCount: UInt32
...
}

pub resource Dappy {
    pub let id: UInt64  // Global unique NFT ID
    pub let serialNumber: UInt32  // Based on number of Dappies minted with this template
    pub let data: DappyData
...
}

Solution 2:

pub struct Template {
    pub let templateID: UInt32
    pub let dna: String
    pub let name: String
    pub let price: UFix64
    pub let maxQuantity: UInt32
    access(self) retired: Bool
    access(self) mintCount: UInt32
...
}
pub resource Dappy {
    pub let id: UInt64  
    pub let templateID: UInt32
    pub let serialNumber: UInt32
...
}

These are the two alternative solutions for all 3 points above. However, I'm afraid I'm overlooking something and would like your opinion on it. For example,

1. I understand that having the access(self) access modifier for both retired and mintCount fields keeps them secure so nobody can do something like:

DappyContract.templates[templateID]!.retired = true

However, what would be the best way to update these values for Admins only then? Could you point me to some examples?

2. As a side effect of Solution 1 I would need to introduce the dappyDatas dictionary to keep track of data for all Dappies. I would like to avoid doing so.

Could you please provide your opinion on the best way to restructure the code based on the Template functionality expansion I've described above?

Additional context
Thanks for putting together CryptoDappy project and, especially, recording videos and explaining how everything fits together. I'm just trying to find the best place to ask questions similar to the ones above and I hope this is it.

[bebner]

Hey @iliawx!

First of all, thanks very much for your proposal here, I think this is a great addition and like to encourage you to work on it.

1. From my point of view, I think it would make sense to implement the retired flag to the template itself, accepting the side effect of passing that data to the Dappy.
2. I'd stick with the other obvious solutions, using the mintCountPerTemplate at the contract level.
3. For now, I would advise against a maximum number for the Dappies, just because many people will mint different Dappies for testing purposes. Focussing on ideas no. 1 & 2 might be better here.

For the admin to be able to change this, you will have to add a method to the admin resource, e.g. setRetiredStatus or retireDappyTemplate. Anyone who has the Admin template can then call these methods and essentially retire the Dappy.

Some more inspiration: We'd probably also need some Frontend-logic to show if a Dappy is retired or hide it in this case. Any chance you could come up with an idea here?

Again, thanks for driving this community project further 🙏 👍

Best,
Ben