Binders

[jim-parry]

I am sensing a pattern emerging ... something (class/methods) to bind an implementation to a manipulatable object, for any number of the third party things the community would like to see, eg

• manipulator(string imageFilename?, string discriminator) : Manipulator, which would have methods per the OP
• template(string viewFilename?, string discriminator): Template, which could have methods like FuelCMS' Parser (?)
• authenticator(string discriminator): Authenticator, with suitable methods

I am not hung on on the signatures ... they could just as well be

• bind(string discriminator, string suitableObject?), to return a handle to a tool, or to a tool bound to a specific object.

Not sure how well this would work, but it seems to be a good fit for image manipulation.
Come to think of it, this is like the database adapters, hmmm.
Our job would be to build the binder and prescribe the manipulation interface, and the community could provide bindings, whether they made it into the core framework or not.
I suspect many of the bindings would result in composer dependencies, which some in the community object to.

[lonnieezell]

I'm a little confused by the examples, but it seems like that's what we're already doing with Services and class interfaces. Some packages, like database, logging, and session, make use of different factory/driver scenarios based on their specific needs.

This is basically what you're describing right? And I have no idea what the "manipulator" one is referencing, honestly. Maybe something I missed on the forums.

[jim-parry]

That is what we are doing with the CI components, sort of. The notion I present extends that to external packages - a way to select from a group based on a "discriminator", which could be a keyword (eg ImageMagick) or an extension (*.png) ... I'm not too clear on that. The "manipulator" is my silly notion of the name that an Image Manipulator interface might be given.

The notion also provides for perfoming such bindings on the fly. Rather than tailoring Services to provide a specific class for every request for a component, I see being able to somehow lookup the appropriate adapter, and return an instance of it, possible bound to the object that it would manipulate.

There were some examples of such a notion on the forum and in some of the other issue threads here, hence my suggesting a pattern that we might exploit.

We have talked about not building such components into CI4, but we have also talked about providing an easy way to integrate them ^^
We have talked about abstracting the interfaces to CI components (done) and where possible to groups of third party packages (eg template engines, image manipulators or authenticators ^^).

[jim-parry]

I'm going to shelve this for now ... I need to express myself better, and this is not needed for phase 2.

[lonnieezell]

Ah, ok. We can discuss later. I guess my initial thought on it is a config file with $available_handlers array, and then the Image library (or whatever) is basically a factory that returns the correctly instantiated class. Which could be done per file extension, or with a default alias passed in, etc.

[jim-parry]

Agreed. FuelPHP's forge() does something like this for template engines, which sparked my imagination :-/
It definitely sounds like a factory pattern.