Skip to content
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

Refactor configuration variables #4

Closed
6 tasks done
inakianduaga opened this issue Jan 11, 2015 · 0 comments
Closed
6 tasks done

Refactor configuration variables #4

inakianduaga opened this issue Jan 11, 2015 · 0 comments
Labels

Comments

@inakianduaga
Copy link
Owner

Drivers should have API for configurable properties (basePath for file/AwsS3, S3 bucket/credentials for AwsS3, etc.

That way each model can configure the driver instance it uses in whatever way it wants. The alternative is to provide a config key on the model that is passed to the driver and the driver uses that for configuring itself

Update:

  • Remove Model reference from the drivers (single-responsability, the driver shouldn't have to give a crap about what the model is).
    • Move the storage setPath update to the actual boot observer method.
  • Add abstract driver implementation
    • Extract the generateStoragePath method which is always the same
  • Add storageDriverConfigKey property on the trait, that's the only property we will need to set on the model so the driver/adaptor can be integrated.
  • Add a setConfigKey() method to the driver interface (& abstract implementation)
  • On boot method of trait, add after parent::boot() a
$storageDriver = app(StorageDriver::class)->setConfigKey($this->storageDriverConfigKey); 
Use this on the creating/deleting methods (remember to pass the variable to the lambda function)  
  • Move the $binaryPathDBField from the trait to a config property, that way we use only a single key to reference to the config, and everything else is read from there.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant