Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The plan below would allow separate all template comment related logic into one class and allow addition of new settings later if needed.

  1. create the "TemplateCommentParser" class, that: - 0.2h
    • would accept path to template as constructor argument
    • the "parse" method would return associative array of results
  2. add support for data types in the class:   - 0.5h
    • "string" - any string
    • "boolean" - true (when "yes"), false (
    when 
    • when "no"), exception otherwise
    • "integer" - as-as, when a positive integer, exception otherwise
    • "category_path" - would split value by "||" and trim each each element
  3. define supported settings and their data types as class properties  (similar to "Fields" array in unit config with "type" and "default") - 0.3h
  4. when template doesn't exist throw an exception   - 0.1h
  5. add "getDefaults" method, that will return an array (keys - field names, values - their default values) - 0.5h
  6. when no meta comment found, then return an empty array result of calling "getDefaults" method - 0.1h
  7. when meta comment found:   - 0.3h
    • if it's one line long, then return an
    empty array
    • result of calling "getDefaults" method
    • if it's invalid XML, then throw an exception
    • when unsupported setting found, then throw an exception
    • when supported setting found, but it has value unknown format, then throw an exception
  8. return parsing result (if some fields not present, then add them with their default values)
  9. delete "kThemesHelper::parseTemplateMetaInfo" in favor of using using "TemplateCommentParser::parse" method   - 0.5h

Quote: 2h2.5h*1.4=3h3.5h

Related Discussions

Related Tasks

Jira Legacy
serverSystem Jira
serverId513b375f-8291-3313-9d9f-704c39b1f915
keyINP-1553