Change way templates are uniquely identified #58

Closed
neocotic opened this Issue Jan 25, 2012 · 2 comments

Comments

Projects
None yet
1 participant
@neocotic
Member

neocotic commented Jan 25, 2012

Using names to unique identify templates has never been ideal but I've just stuck with it instead of rethinking. Since this is the full release I'd like to sort this out now, even if it introduces greater risk.

Concept

  • Templates are now uniquely identified using a new, randomly generated, key property
  • Keys of predefined templates avoid conflicts and allow exportation by using the key structure PREDEFINED.00001
  • All cases where a template is retrieved based on its name should be changed to reference its key instead (unless required to support compatibility with older versions - in which case duplicate the functionality for keys)
  • toolbarTemplateName option tag should be changed to toolbarKey and store the templates key instead of name while, during the version update, deriving any previously defined template and storing its key
  • Description of the toolbarKey option tag in the guide should be updated
  • Generate a new key when adding a new template for the first time or importing a custom template from an older version
  • When updating versions or importing a predefined template from an older version, map the names of known predefined templates to their static keys
  • Description of the popular complex tag in the guide should remove the mention of the name property
  • popular needs to be changed to hold the key of the most popular template instead of its name
  • Try to consider all possibilities!

Hash Generator

max   = 0xfffff
min   = 0x10000
parts = []
parts.push new Date().getTime()
parts.push Math.floor(Math.random() * (max - min + 1)) + min
parts[i] = part.toString 16 for part, i in parts
parts.join('.').toUpperCase()

Which should output something like 13514DABC0F.A46C0

@ghost ghost assigned neocotic Jan 25, 2012

neocotic added a commit that referenced this issue Jan 27, 2012

neocotic added a commit that referenced this issue Jan 27, 2012

neocotic added a commit that referenced this issue Jan 27, 2012

neocotic added a commit that referenced this issue Jan 27, 2012

neocotic added a commit that referenced this issue Jan 27, 2012

neocotic added a commit that referenced this issue Jan 30, 2012

@neocotic

This comment has been minimized.

Show comment
Hide comment
@neocotic

neocotic Jan 30, 2012

Member

This seems to be implemented but I still need to test version updates and import/export functionality thoroughly.

Member

neocotic commented Jan 30, 2012

This seems to be implemented but I still need to test version updates and import/export functionality thoroughly.

@neocotic

This comment has been minimized.

Show comment
Hide comment
@neocotic

neocotic Feb 13, 2012

Member

I'm happy with the results and I'm going to close this now after fixing some issues surrounding export/import functionality.

However, I feel it's worth mentioning that, if a custom template is imported from a previous version (earlier than 1.0.0) more than once, it will be duplicated as there's no way of knowing it's exactly the same as the old name field is discarded after being imported.

Member

neocotic commented Feb 13, 2012

I'm happy with the results and I'm going to close this now after fixing some issues surrounding export/import functionality.

However, I feel it's worth mentioning that, if a custom template is imported from a previous version (earlier than 1.0.0) more than once, it will be duplicated as there's no way of knowing it's exactly the same as the old name field is discarded after being imported.

@neocotic neocotic closed this Feb 13, 2012

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