| [ Index ] |
PHP Cross Reference of Unnamed Project |
[Source view] [Print] [Project Stats]
The base module provides the Base class, which objects requiring attribute and custom event support can extend. The module also provides two ways to reuse code - It augments Base with the Plugin.Host interface which provides plugin support and also provides the BaseCore.build method which provides a way to build custom classes using extensions.
| File Size: | 845 lines (30 kb) |
| Included or required: | 0 times |
| Referenced: | 0 times |
| Includes or requires: | 0 files |
| BaseCore(cfg) X-Ref |
| The BaseCore class, is the lightest version of Base, and provides Base's basic lifecycle management and ATTRS construction support, but doesn't fire init/destroy or attribute change events. BaseCore also handles the chaining of initializer and destructor methods across the hierarchy as part of object construction and destruction. Additionally, attributes configured through the static <a href="#property_BaseCore.ATTRS">ATTRS</a> property for each class in the hierarchy will be initialized by BaseCore. Classes which require attribute support, but don't intend to use/expose attribute change events can extend BaseCore instead of Base for optimal kweight and runtime performance. **3.11.0 BACK COMPAT NOTE FOR COMPONENT DEVELOPERS** Prior to version 3.11.0, ATTRS would get added a class at a time. That is: <pre> for each (class in the hierarchy) { Call the class Extension constructors. Add the class ATTRS. Call the class initializer Call the class Extension initializers. } </pre> As of 3.11.0, ATTRS from all classes in the hierarchy are added in one `addAttrs` call before **any** initializers are called. That is, the flow becomes: <pre> for each (class in the hierarchy) { Call the class Extension constructors. } Add ATTRS for all classes for each (class in the hierarchy) { Call the class initializer. Call the class Extension initializers. } </pre> Adding all ATTRS at once fixes subtle edge-case issues with subclass ATTRS overriding superclass `setter`, `getter` or `valueFn` definitions and being unable to get/set attributes defined by the subclass. It also leaves us with a cleaner order of operation flow moving forward. However, it may require component developers to upgrade their components, for the following scenarios: 1. It impacts components which may have `setter`, `getter` or `valueFn` code which expects a superclass' initializer to have run. This is expected to be rare, but to support it, Base now supports a `_preAddAttrs()`, method hook (same signature as `addAttrs`). Components can implement this method on their prototype for edge cases which do require finer control over the order in which attributes are added (see widget-htmlparser for example). 2. Extension developers may need to move code from Extension constructors to `initializer`s Older extensions, which were written before `initializer` support was added, had a lot of initialization code in their constructors. For example, code which acccessed superclass attributes. With the new flow this code would not be able to see attributes. The recommendation is to move this initialization code to an `initializer` on the Extension, which was the recommendation for anything created after `initializer` support for Extensions was added. param: {Object} cfg Object with configuration property name/value pairs. |
| Generated: Thu Aug 11 10:00:09 2016 | Cross-referenced by PHPXref 0.7.1 |