New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to organise the Driver interface? #21

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

Comments

Projects
None yet
2 participants
@stephenharris
Collaborator

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

This comment has been minimized.

Owner

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

This comment has been minimized.

Owner

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

This comment has been minimized.

Owner

paulgibbs commented Mar 2, 2017

I have started having a stab at this.

@paulgibbs paulgibbs referenced this issue Mar 15, 2017

Closed

Driver interface organisation revamp #75

0 of 9 tasks complete
@paulgibbs

This comment has been minimized.

Owner

paulgibbs commented Apr 30, 2017

See #79

@paulgibbs paulgibbs referenced this issue Apr 30, 2017

Merged

Driver interface refactor #79

4 of 8 tasks complete
@paulgibbs

This comment has been minimized.

Owner

paulgibbs commented Apr 30, 2017

done.

@paulgibbs paulgibbs closed this Apr 30, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment