As a developer I would like to extend Sloth (perhaps with a plugin architecture) so I can add concepts and capabilities that are not currently available.
If the page/suite implemented an operational context interface that allowed 'fixture' resolutions to be defined by an appropriate plug-in then things like do fixtures could add their own custom resolvers within the page context. The resolvers would act like a stack with each deferring to its parent if it cannot resolve a name.
Type adapters could be implemented in a similar way. A type adapter would be constrained by scope (field type, field type & fixture type etc). These could be declared in the page in properties or dynamically by the loaded fixture adapters.
This would make the page a declarative framework that can be extended and more importantly provides a useful construct for maintaining state during test execution
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=635168
Originator: YES
Some implementation thoughts
If the page/suite implemented an operational context interface that allowed 'fixture' resolutions to be defined by an appropriate plug-in then things like do fixtures could add their own custom resolvers within the page context. The resolvers would act like a stack with each deferring to its parent if it cannot resolve a name.
Type adapters could be implemented in a similar way. A type adapter would be constrained by scope (field type, field type & fixture type etc). These could be declared in the page in properties or dynamically by the loaded fixture adapters.
This would make the page a declarative framework that can be extended and more importantly provides a useful construct for maintaining state during test execution