Annotating with Annotations

Editor's Notes

• #2: \n
• #3: \n
• #4: \n
• #5: \n
• #6: \n
• #7: Overview of how annotations are just descriptions of static resources. Like HTML syntax can describe text with bold, italic\n
• #8: Overview of how annotations are just descriptions of static resources. Like HTML syntax can describe text with bold, italic\n
• #9: phpDoc vs. Annotation: docs do not have influence in how a app runs.\nAnnotation by itself does not “act” its used to be acted on by another class.\n\nJust putting an annotation is not going to work, you need someone to act on it.\n
• #10: phpDoc vs. Annotation: docs do not have influence in how a app runs.\nAnnotation by itself does not “act” its used to be acted on by another class.\n\nJust putting an annotation is not going to work, you need someone to act on it.\n
• #11: Java: annotations since 2004, same syntax for javadocs and annotations\nRuntime uses reflection to read annnotations\nJavadoc Vs. Annotations: same as PHPDoc mentioned before\n
• #12: Java: annotations since 2004, same syntax for javadocs and annotations\nRuntime uses reflection to read annnotations\nJavadoc Vs. Annotations: same as PHPDoc mentioned before\n
• #13: Java: annotations since 2004, same syntax for javadocs and annotations\nRuntime uses reflection to read annnotations\nJavadoc Vs. Annotations: same as PHPDoc mentioned before\n
• #14: Java: annotations since 2004, same syntax for javadocs and annotations\nRuntime uses reflection to read annnotations\nJavadoc Vs. Annotations: same as PHPDoc mentioned before\n
• #15: Java: annotations since 2004, same syntax for javadocs and annotations\nRuntime uses reflection to read annnotations\nJavadoc Vs. Annotations: same as PHPDoc mentioned before\n
• #16: Java: annotations since 2004, same syntax for javadocs and annotations\nRuntime uses reflection to read annnotations\nJavadoc Vs. Annotations: same as PHPDoc mentioned before\n
• #17: Java: annotations since 2004, same syntax for javadocs and annotations\nRuntime uses reflection to read annnotations\nJavadoc Vs. Annotations: same as PHPDoc mentioned before\n
• #18: PHP has no support for Annotations.\n
• #19: PHP has no support for Annotations.\n
• #20: Pretend its the end of the talk.\n
• #21: Mentions stubbles and other engines.\nTie in D2 Annotation Engine and Gulherme as the author of both.\n
• #22: Mentions stubbles and other engines.\nTie in D2 Annotation Engine and Gulherme as the author of both.\n
• #23: Mentions stubbles and other engines.\nTie in D2 Annotation Engine and Gulherme as the author of both.\n
• #24: Mentions stubbles and other engines.\nTie in D2 Annotation Engine and Gulherme as the author of both.\n
• #25: Mentions stubbles and other engines.\nTie in D2 Annotation Engine and Gulherme as the author of both.\n
• #26: Mentions stubbles and other engines.\nTie in D2 Annotation Engine and Gulherme as the author of both.\n
• #27: Mentions stubbles and other engines.\nTie in D2 Annotation Engine and Gulherme as the author of both.\n
• #28: Mentions stubbles and other engines.\nTie in D2 Annotation Engine and Gulherme as the author of both.\n
• #29: Mentions stubbles and other engines.\nTie in D2 Annotation Engine and Gulherme as the author of both.\n
• #30: Mentions stubbles and other engines.\nTie in D2 Annotation Engine and Gulherme as the author of both.\n
• #31: Mentions stubbles and other engines.\nTie in D2 Annotation Engine and Gulherme as the author of both.\n
• #32: Mentions stubbles and other engines.\nTie in D2 Annotation Engine and Gulherme as the author of both.\n
• #33: Mentions stubbles and other engines.\nTie in D2 Annotation Engine and Gulherme as the author of both.\n
• #34: Mentions stubbles and other engines.\nTie in D2 Annotation Engine and Gulherme as the author of both.\n
• #35: Mentions stubbles and other engines.\nTie in D2 Annotation Engine and Gulherme as the author of both.\n
• #36: Mentions stubbles and other engines.\nTie in D2 Annotation Engine and Gulherme as the author of both.\n
• #37: Mentions stubbles and other engines.\nTie in D2 Annotation Engine and Gulherme as the author of both.\n
• #38: Mentions stubbles and other engines.\nTie in D2 Annotation Engine and Gulherme as the author of both.\n
• #39: Mentions stubbles and other engines.\nTie in D2 Annotation Engine and Gulherme as the author of both.\n
• #40: Mentions stubbles and other engines.\nTie in D2 Annotation Engine and Gulherme as the author of both.\n
• #41: Mentions stubbles and other engines.\nTie in D2 Annotation Engine and Gulherme as the author of both.\n
• #42: Mentions stubbles and other engines.\nTie in D2 Annotation Engine and Gulherme as the author of both.\n
• #43: Make a note that PHP does have a custom token for DOCBLOCKS so annotations are not in “documents” and docblocks are even stored in opcode caches.\n
• #44: Make a note that PHP does have a custom token for DOCBLOCKS so annotations are not in “documents” and docblocks are even stored in opcode caches.\n
• #45: Make a note that PHP does have a custom token for DOCBLOCKS so annotations are not in “documents” and docblocks are even stored in opcode caches.\n
• #46: Make a note that PHP does have a custom token for DOCBLOCKS so annotations are not in “documents” and docblocks are even stored in opcode caches.\n
• #47: Make a note that PHP does have a custom token for DOCBLOCKS so annotations are not in “documents” and docblocks are even stored in opcode caches.\n
• #48: Diferentiate between Marker Type and Parametrized type\n\nParameterized has more details and complex syntax , marker has no content or simple string syntax\n
• #49: Diferentiate between Marker Type and Parametrized type\n\nParameterized has more details and complex syntax , marker has no content or simple string syntax\n
• #50: Diferentiate between Marker Type and Parametrized type\n\nParameterized has more details and complex syntax , marker has no content or simple string syntax\n
• #51: Diferentiate between Marker Type and Parametrized type\n\nParameterized has more details and complex syntax , marker has no content or simple string syntax\n
• #52: \n
• #53: T_DOC_COMMENTS since PHP 5.3 - APC support\n\nDebugging is harder but really a problem.\nPerformance is much better with cache\n\nTesting: can be done by feeding annotation “action” service with populated entities for example\n
• #54: T_DOC_COMMENTS since PHP 5.3 - APC support\n\nDebugging is harder but really a problem.\nPerformance is much better with cache\n\nTesting: can be done by feeding annotation “action” service with populated entities for example\n
• #55: T_DOC_COMMENTS since PHP 5.3 - APC support\n\nDebugging is harder but really a problem.\nPerformance is much better with cache\n\nTesting: can be done by feeding annotation “action” service with populated entities for example\n
• #56: Pros:\n- Compare D1 to D2, you no longer need to extend an object to have persistence behaviour\n- 1 config file with 1000 objects vs. 1000 objects with all their own config\n
• #57: Pros:\n- Compare D1 to D2, you no longer need to extend an object to have persistence behaviour\n- 1 config file with 1000 objects vs. 1000 objects with all their own config\n
• #58: Pros:\n- Compare D1 to D2, you no longer need to extend an object to have persistence behaviour\n- 1 config file with 1000 objects vs. 1000 objects with all their own config\n
• #59: Pros:\n- Compare D1 to D2, you no longer need to extend an object to have persistence behaviour\n- 1 config file with 1000 objects vs. 1000 objects with all their own config\n
• #60: Pros:\n- Compare D1 to D2, you no longer need to extend an object to have persistence behaviour\n- 1 config file with 1000 objects vs. 1000 objects with all their own config\n
• #61: Pros:\n- Compare D1 to D2, you no longer need to extend an object to have persistence behaviour\n- 1 config file with 1000 objects vs. 1000 objects with all their own config\n
• #62: \n
• #63: \n
• #64: \n
• #65: So imagine you are planning a new entity, your mind usually puts a post it on it with all this information\nYou would then have to put persistance in one config, validation in another...\n\nNote how all validations rules are now in a single place.\nEasier to maintain, since its easier to analyse all aspects\n
• #66: So imagine you are planning a new entity, your mind usually puts a post it on it with all this information\nYou would then have to put persistance in one config, validation in another...\n\nNote how all validations rules are now in a single place.\nEasier to maintain, since its easier to analyse all aspects\n
• #67: So imagine you are planning a new entity, your mind usually puts a post it on it with all this information\nYou would then have to put persistance in one config, validation in another...\n\nNote how all validations rules are now in a single place.\nEasier to maintain, since its easier to analyse all aspects\n
• #68: So imagine you are planning a new entity, your mind usually puts a post it on it with all this information\nYou would then have to put persistance in one config, validation in another...\n\nNote how all validations rules are now in a single place.\nEasier to maintain, since its easier to analyse all aspects\n
• #69: So imagine you are planning a new entity, your mind usually puts a post it on it with all this information\nYou would then have to put persistance in one config, validation in another...\n\nNote how all validations rules are now in a single place.\nEasier to maintain, since its easier to analyse all aspects\n
• #70: So imagine you are planning a new entity, your mind usually puts a post it on it with all this information\nYou would then have to put persistance in one config, validation in another...\n\nNote how all validations rules are now in a single place.\nEasier to maintain, since its easier to analyse all aspects\n
• #71: So imagine you are planning a new entity, your mind usually puts a post it on it with all this information\nYou would then have to put persistance in one config, validation in another...\n\nNote how all validations rules are now in a single place.\nEasier to maintain, since its easier to analyse all aspects\n
• #72: So imagine you are planning a new entity, your mind usually puts a post it on it with all this information\nYou would then have to put persistance in one config, validation in another...\n\nNote how all validations rules are now in a single place.\nEasier to maintain, since its easier to analyse all aspects\n
• #73: So imagine you are planning a new entity, your imnd usually puts a post it on it with all this information\nYou would then have to put persistance in one config, validation in another...\n\nNote how all validations rules are now in a single place.\nEasier to maintain, since its easier to analyse all aspects\n
• #74: \n
• #75: Common uses for annotations in PHP\n\nPersistence, grouping, routing, docs, validation, filtering, expectations, API Generation\n
• #76: phpDoc uses just marker annotations which arguably are not annotations\nPHPUnit uses it for a long time\nnew frameworks have their own engines and D2 was Hibernate based.\n
• #77: Example from PHPUnit\n
• #78: Example from D2\n
• #79: Example from SF2\n
• #80: Example in Typo3\n
• #81: \n
• #82: So what do you need to have annotations in you application?\n
• #83: So what do you need to have annotations in you application?\n
• #84: So what do you need to have annotations in you application?\n
• #85: How annotations (text) become actual rules/objects.\nReflection to read, and annotation engine to parse and instantiate.\nNOTE: from here another service will use these annotations to “act” upon the code.\n
• #86: How annotations (text) become actual rules/objects.\nReflection to read, and annotation engine to parse and instantiate.\nNOTE: from here another service will use these annotations to “act” upon the code.\n
• #87: How annotations (text) become actual rules/objects.\nReflection to read, and annotation engine to parse and instantiate.\nNOTE: from here another service will use these annotations to “act” upon the code.\n
• #88: How annotations (text) become actual rules/objects.\nReflection to read, and annotation engine to parse and instantiate.\nNOTE: from here another service will use these annotations to “act” upon the code.\n
• #89: How annotations (text) become actual rules/objects.\nReflection to read, and annotation engine to parse and instantiate.\nNOTE: from here another service will use these annotations to “act” upon the code.\n
• #90: How annotations (text) become actual rules/objects.\nReflection to read, and annotation engine to parse and instantiate.\nNOTE: from here another service will use these annotations to “act” upon the code.\n
• #91: How annotations (text) become actual rules/objects.\nReflection to read, and annotation engine to parse and instantiate.\nNOTE: from here another service will use these annotations to “act” upon the code.\n
• #92: How annotations (text) become actual rules/objects.\nReflection to read, and annotation engine to parse and instantiate.\nNOTE: from here another service will use these annotations to “act” upon the code.\n
• #93: How annotations (text) become actual rules/objects.\nReflection to read, and annotation engine to parse and instantiate.\nNOTE: from here another service will use these annotations to “act” upon the code.\n
• #94: How annotations (text) become actual rules/objects.\nReflection to read, and annotation engine to parse and instantiate.\nNOTE: from here another service will use these annotations to “act” upon the code.\n
• #95: How annotations (text) become actual rules/objects.\nReflection to read, and annotation engine to parse and instantiate.\nNOTE: from here another service will use these annotations to “act” upon the code.\n
• #96: How annotations (text) become actual rules/objects.\nReflection to read, and annotation engine to parse and instantiate.\nNOTE: from here another service will use these annotations to “act” upon the code.\n
• #97: How annotations (text) become actual rules/objects.\nReflection to read, and annotation engine to parse and instantiate.\nNOTE: from here another service will use these annotations to “act” upon the code.\n
• #98: Some of the engines out there.\nZF2 has no docs or use yet.\nNotoj by Cesar Rodas is very new\nphpDocumentor has a new engine\nphp-annotations by Rasmus Schultz\n\n\nSome were abandoned along the way\n
• #99: No dependencies on any\nNotoj is very “microPHP”\nReming people of parameterized vs. marker\n\nD2 is the best support right now. With caching and the whole load\n
• #100: How the D2 Engine works .. a high overview.\nThe Reader gets the data from the class which is the parsed by the lexer and finally becomes instances. Which are cached and passed in the format of Metadata classes to your walker/action class\n\n
• #101: How the D2 Engine works .. a high overview.\nThe Reader gets the data from the class which is the parsed by the lexer and finally becomes instances. Which are cached and passed in the format of Metadata classes to your walker/action class\n\n
• #102: How the D2 Engine works .. a high overview.\nThe Reader gets the data from the class which is the parsed by the lexer and finally becomes instances. Which are cached and passed in the format of Metadata classes to your walker/action class\n\n
• #103: How the D2 Engine works .. a high overview.\nThe Reader gets the data from the class which is the parsed by the lexer and finally becomes instances. Which are cached and passed in the format of Metadata classes to your walker/action class\n\n
• #104: How the D2 Engine works .. a high overview.\nThe Reader gets the data from the class which is the parsed by the lexer and finally becomes instances. Which are cached and passed in the format of Metadata classes to your walker/action class\n\n
• #105: How the D2 Engine works .. a high overview.\nThe Reader gets the data from the class which is the parsed by the lexer and finally becomes instances. Which are cached and passed in the format of Metadata classes to your walker/action class\n\n
• #106: How the D2 Engine works .. a high overview.\nThe Reader gets the data from the class which is the parsed by the lexer and finally becomes instances. Which are cached and passed in the format of Metadata classes to your walker/action class\n\n
• #107: How the D2 Engine works .. a high overview.\nThe Reader gets the data from the class which is the parsed by the lexer and finally becomes instances. Which are cached and passed in the format of Metadata classes to your walker/action class\n\n
• #108: How the D2 Engine works .. a high overview.\nThe Reader gets the data from the class which is the parsed by the lexer and finally becomes instances. Which are cached and passed in the format of Metadata classes to your walker/action class\n\n
• #109: How the D2 Engine works .. a high overview.\nThe Reader gets the data from the class which is the parsed by the lexer and finally becomes instances. Which are cached and passed in the format of Metadata classes to your walker/action class\n\n
• #110: How the D2 Engine works .. a high overview.\nThe Reader gets the data from the class which is the parsed by the lexer and finally becomes instances. Which are cached and passed in the format of Metadata classes to your walker/action class\n\n
• #111: All examples are going to be from DMS\\Filter\n
• #112: All you really need is to implement a “Annotation” class and a Enforcer, a class that will be able to get an annotation and know what to do. i.e. call the “filterValue” method with the value from the object and replace the original value with the clean one.\n
• #113: All you really need is to implement a “Annotation” class and a Enforcer, a class that will be able to get an annotation and know what to do. i.e. call the “filterValue” method with the value from the object and replace the original value with the clean one.\n
• #114: All you really need is to implement a “Annotation” class and a Enforcer, a class that will be able to get an annotation and know what to do. i.e. call the “filterValue” method with the value from the object and replace the original value with the clean one.\n
• #115: All you really need is to implement a “Annotation” class and a Enforcer, a class that will be able to get an annotation and know what to do. i.e. call the “filterValue” method with the value from the object and replace the original value with the clean one.\n
• #116: All you really need is to implement a “Annotation” class and a Enforcer, a class that will be able to get an annotation and know what to do. i.e. call the “filterValue” method with the value from the object and replace the original value with the clean one.\n
• #117: All you really need is to implement a “Annotation” class and a Enforcer, a class that will be able to get an annotation and know what to do. i.e. call the “filterValue” method with the value from the object and replace the original value with the clean one.\n
• #118: All you really need is to implement a “Annotation” class and a Enforcer, a class that will be able to get an annotation and know what to do. i.e. call the “filterValue” method with the value from the object and replace the original value with the clean one.\n
• #119: All you really need is to implement a “Annotation” class and a Enforcer, a class that will be able to get an annotation and know what to do. i.e. call the “filterValue” method with the value from the object and replace the original value with the clean one.\n
• #120: All you really need is to implement a “Annotation” class and a Enforcer, a class that will be able to get an annotation and know what to do. i.e. call the “filterValue” method with the value from the object and replace the original value with the clean one.\n
• #121: All you really need is to implement a “Annotation” class and a Enforcer, a class that will be able to get an annotation and know what to do. i.e. call the “filterValue” method with the value from the object and replace the original value with the clean one.\n
• #122: All you really need is to implement a “Annotation” class and a Enforcer, a class that will be able to get an annotation and know what to do. i.e. call the “filterValue” method with the value from the object and replace the original value with the clean one.\n
• #123: All you really need is to implement a “Annotation” class and a Enforcer, a class that will be able to get an annotation and know what to do. i.e. call the “filterValue” method with the value from the object and replace the original value with the clean one.\n
• #124: All you really need is to implement a “Annotation” class and a Enforcer, a class that will be able to get an annotation and know what to do. i.e. call the “filterValue” method with the value from the object and replace the original value with the clean one.\n
• #125: All you really need is to implement a “Annotation” class and a Enforcer, a class that will be able to get an annotation and know what to do. i.e. call the “filterValue” method with the value from the object and replace the original value with the clean one.\n
• #126: All you really need is to implement a “Annotation” class and a Enforcer, a class that will be able to get an annotation and know what to do. i.e. call the “filterValue” method with the value from the object and replace the original value with the clean one.\n
• #127: All you really need is to implement a “Annotation” class and a Enforcer, a class that will be able to get an annotation and know what to do. i.e. call the “filterValue” method with the value from the object and replace the original value with the clean one.\n
• #128: Simple Annotation that needs no parameters (made simple on purpose)\nMention that parameters come in an array but we will explain later\nShow method of “action” in this case just a filter, could be any action or data\n
• #129: Simple Annotation that needs no parameters (made simple on purpose)\nMention that parameters come in an array but we will explain later\nShow method of “action” in this case just a filter, could be any action or data\n
• #130: Simple Annotation that needs no parameters (made simple on purpose)\nMention that parameters come in an array but we will explain later\nShow method of “action” in this case just a filter, could be any action or data\n
• #131: Simple Annotation that needs no parameters (made simple on purpose)\nMention that parameters come in an array but we will explain later\nShow method of “action” in this case just a filter, could be any action or data\n
• #132: Simple Annotation that needs no parameters (made simple on purpose)\nMention that parameters come in an array but we will explain later\nShow method of “action” in this case just a filter, could be any action or data\n
• #133: Simple Annotation that needs no parameters (made simple on purpose)\nMention that parameters come in an array but we will explain later\nShow method of “action” in this case just a filter, could be any action or data\n
• #134: Explain this simple “Enforcer” class\nIt only gets a single annotation from the reader\nIt makes the action described by the annotation happen.\n\n
• #135: Explain this simple “Enforcer” class\nIt only gets a single annotation from the reader\nIt makes the action described by the annotation happen.\n\n
• #136: Explain this simple “Enforcer” class\nIt only gets a single annotation from the reader\nIt makes the action described by the annotation happen.\n\n
• #137: Explain this simple “Enforcer” class\nIt only gets a single annotation from the reader\nIt makes the action described by the annotation happen.\n\n
• #138: DMS implements a Loader that loads all annotations and filters for “filter rules” since we have multiple classes\nDMS implements a walker that abstracts away reflection->makeAccessible and knows where to fin annotations (method/properties/etc..)\nFilter becomes a simple service that delegates actions.\n
• #139: DMS implements a Loader that loads all annotations and filters for “filter rules” since we have multiple classes\nDMS implements a walker that abstracts away reflection->makeAccessible and knows where to fin annotations (method/properties/etc..)\nFilter becomes a simple service that delegates actions.\n
• #140: DMS implements a Loader that loads all annotations and filters for “filter rules” since we have multiple classes\nDMS implements a walker that abstracts away reflection->makeAccessible and knows where to fin annotations (method/properties/etc..)\nFilter becomes a simple service that delegates actions.\n
• #141: DMS implements a Loader that loads all annotations and filters for “filter rules” since we have multiple classes\nDMS implements a walker that abstracts away reflection->makeAccessible and knows where to fin annotations (method/properties/etc..)\nFilter becomes a simple service that delegates actions.\n
• #142: DMS implements a Loader that loads all annotations and filters for “filter rules” since we have multiple classes\nDMS implements a walker that abstracts away reflection->makeAccessible and knows where to fin annotations (method/properties/etc..)\nFilter becomes a simple service that delegates actions.\n
• #143: DMS implements a Loader that loads all annotations and filters for “filter rules” since we have multiple classes\nDMS implements a walker that abstracts away reflection->makeAccessible and knows where to fin annotations (method/properties/etc..)\nFilter becomes a simple service that delegates actions.\n
• #144: DMS implements a Loader that loads all annotations and filters for “filter rules” since we have multiple classes\nDMS implements a walker that abstracts away reflection->makeAccessible and knows where to fin annotations (method/properties/etc..)\nFilter becomes a simple service that delegates actions.\n
• #145: DMS implements a Loader that loads all annotations and filters for “filter rules” since we have multiple classes\nDMS implements a walker that abstracts away reflection->makeAccessible and knows where to fin annotations (method/properties/etc..)\nFilter becomes a simple service that delegates actions.\n
• #146: DMS implements a Loader that loads all annotations and filters for “filter rules” since we have multiple classes\nDMS implements a walker that abstracts away reflection->makeAccessible and knows where to fin annotations (method/properties/etc..)\nFilter becomes a simple service that delegates actions.\n
• #147: DMS implements a Loader that loads all annotations and filters for “filter rules” since we have multiple classes\nDMS implements a walker that abstracts away reflection->makeAccessible and knows where to fin annotations (method/properties/etc..)\nFilter becomes a simple service that delegates actions.\n
• #148: DMS implements a Loader that loads all annotations and filters for “filter rules” since we have multiple classes\nDMS implements a walker that abstracts away reflection->makeAccessible and knows where to fin annotations (method/properties/etc..)\nFilter becomes a simple service that delegates actions.\n
• #149: DMS implements a Loader that loads all annotations and filters for “filter rules” since we have multiple classes\nDMS implements a walker that abstracts away reflection->makeAccessible and knows where to fin annotations (method/properties/etc..)\nFilter becomes a simple service that delegates actions.\n
• #150: DMS implements a Loader that loads all annotations and filters for “filter rules” since we have multiple classes\nDMS implements a walker that abstracts away reflection->makeAccessible and knows where to fin annotations (method/properties/etc..)\nFilter becomes a simple service that delegates actions.\n
• #151: DMS implements a Loader that loads all annotations and filters for “filter rules” since we have multiple classes\nDMS implements a walker that abstracts away reflection->makeAccessible and knows where to fin annotations (method/properties/etc..)\nFilter becomes a simple service that delegates actions.\n
• #152: DMS implements a Loader that loads all annotations and filters for “filter rules” since we have multiple classes\nDMS implements a walker that abstracts away reflection->makeAccessible and knows where to fin annotations (method/properties/etc..)\nFilter becomes a simple service that delegates actions.\n
• #153: DMS implements a Loader that loads all annotations and filters for “filter rules” since we have multiple classes\nDMS implements a walker that abstracts away reflection->makeAccessible and knows where to fin annotations (method/properties/etc..)\nFilter becomes a simple service that delegates actions.\n
• #154: DMS implements a Loader that loads all annotations and filters for “filter rules” since we have multiple classes\nDMS implements a walker that abstracts away reflection->makeAccessible and knows where to fin annotations (method/properties/etc..)\nFilter becomes a simple service that delegates actions.\n
• #155: the key is assumed to be the “defaultProperty”\n
• #156: the key is assumed to be the “defaultProperty”\n
• #157: the key is assumed to be the “defaultProperty”\n
• #158: the key is assumed to be the “defaultProperty”\n
• #159: the key is assumed to be the “defaultProperty”\n
• #160: the key is assumed to be the “defaultProperty”\n
• #161: the key is assumed to be the “defaultProperty”\n
• #162: the key is assumed to be the “defaultProperty”\n
• #163: \n
• #164: \n
• #165: \n
• #166: \n
• #167: \n
• #168: \n