Skip to content
This repository has been archived by the owner. It is now read-only.

How to organise the Driver interface? #21

Closed
stephenharris opened this issue Jan 24, 2017 · 5 comments
Closed

How to organise the Driver interface? #21

stephenharris opened this issue Jan 24, 2017 · 5 comments

Comments

@stephenharris
Copy link
Collaborator

@stephenharris stephenharris commented Jan 24, 2017

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
Copy link
Owner

@paulgibbs paulgibbs commented Jan 24, 2017

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 paulgibbs added this to the 1.0 milestone Jan 24, 2017
@paulgibbs
Copy link
Owner

@paulgibbs paulgibbs commented Feb 19, 2017

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 paulgibbs self-assigned this Mar 2, 2017
@paulgibbs
Copy link
Owner

@paulgibbs paulgibbs commented Mar 2, 2017

I have started having a stab at this.

@paulgibbs paulgibbs mentioned this issue Mar 15, 2017
0 of 9 tasks complete
@paulgibbs
Copy link
Owner

@paulgibbs paulgibbs commented Apr 30, 2017

See #79

@paulgibbs paulgibbs mentioned this issue Apr 30, 2017
4 of 8 tasks complete
@paulgibbs
Copy link
Owner

@paulgibbs paulgibbs commented Apr 30, 2017

done.

@paulgibbs paulgibbs closed this Apr 30, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants