You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Cache class set the standard on how an formal adapter based class inside the framework looks like. Catalog already shares much of this formalism. Currently Logger, Auth and Session do not. We want to bring these classes on par with Cache. This will again bring us closer to homogeneous API design (for which the framework is well know for) and enable us to make changes to adapter based classes later easily in one go.
make specifying the configuration name a requirement
all methods take the configuration name as first parameter
when needed, classes may support true for name to operate on all configurations (see Catalog::read())
adapter methods should not return an implementation closure but simply execute immediately
per adapter filters are not supported anymore, instead the manager class’ methods should be filtered
abstract base Adapter class exists (see storage\cache\Adapter) and all class adapters inherit from it. This make creating adapters in userland a lot easier, as the base class is the documentation for which methods to implement.
Session to support multi-key operations for read/write/delete (see Cache)
The text was updated successfully, but these errors were encountered:
The Cache class set the standard on how an formal adapter based class inside the framework looks like. Catalog already shares much of this formalism. Currently Logger, Auth and Session do not. We want to bring these classes on par with Cache. This will again bring us closer to homogeneous API design (for which the framework is well know for) and enable us to make changes to adapter based classes later easily in one go.
The text was updated successfully, but these errors were encountered: