How to organise the Driver interface?

[stephenharris]

As noted via e-mail, the Driver acts as an interface for communication between Behat and WordPress (creating, deleting, asserting properties of) content/users/options/terms etc.

The Driver, therefore, could grow quite large. One suggestion is to compartmentalize each WordPress 'entity' (content, users, etc) So rather than:

$driver->createTerm()
$driver->createContent()

it would be

$driver->term->create()
$driver->content->create()

I don't foresee any reason to be able to swap out, say, the $driver-term instance, but this would at least allow us to group methods which are logically consistent, and keep classes smaller.

[paulgibbs]

Broadly, yes. Not sure of the implementation. Thinking out loud, DriverInterface would have to be split up into (terrible name but) DriverInterfacePart. Each Part would have stubbed methods for CRUD-actions.

DriverInterface would remain with bootstrap methods/constructor. It'd need an array or something to store the DriverInterfaceParts (class properties would probably be OK, like you've implied, would end up with lots, though!). We can use dependency injection to have Symfony create these and pass to constructor (I don't know how to do that 100%, still learning about Symphony and DI, but i've done it before elsewhere in this project)

[paulgibbs]

I think it's time to sort this out. I still agree with your suggestions. My thoughts:

• I think the Driver class will contain an array of DriverCollections (all names placeholder!!).
• Probably use magic functions to allow this->[content]->create() (if possible?).
• An individual DriverCollection would represent e.g. "term" or "content".
• Existing DriverInterface - add methods for CRUD.
• DriverCollection implements the existing DriverInterface.

That keeps the main Driver class very light as we would use an array to store all Collections.

[paulgibbs]

I have started having a stab at this.

[paulgibbs]

See #79

[paulgibbs]

done.