-
Notifications
You must be signed in to change notification settings - Fork 359
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
Composed ILS Driver #3112
Composed ILS Driver #3112
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As the primary maintainer of MultiBackend, I imagine that this work may be of interest to @EreMaijala, so I've asked for a review from him (though I don't think there's a huge rush to complete it).
I also don't object to the name of CombinedDriver, but I wonder if something like ComposedDriver might be slightly more descriptive, since if I understand correctly, the purpose of this driver is to create a single interface by composing functionality from multiple places. Just a thought!
I'll give this a closer look myself after the 9.1 release process is wrapped up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is an interesting development that provides a nice layer of flexibility to the ILS drivers! I didn't see any major issues, so I've commented on some minor ones.
I think that the default return values will need the most work. It might also make sense to make defaultCall throw an ILS exception by default unless instructed otherwise. This would eliminate the need to specify the default return values for cases where no suitable default is not available (or, make it more difficult to return an invalid value by accident).
@demiankatz I renamed the driver to ComposedDriver. @EreMaijala I think you are right about throwing exceptions instead of default return values. Since calling driver methods that are not supported should either not be possible or otherwise should be an error. I removed the default return values and now always an exception is thrown. |
Thanks, @ThoWagen -- I've renamed this PR to match the new name of the driver itself. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me! Just one more nit to pick in a comment. :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, @ThoWagen and @EreMaijala! I gave this another look and found a few minor things to make suggestions about.
Once these are addressed, I think it's ready to merge, but I'm curious whether you think this should be included in release 9.1 or if it's safer to delay to 10.0 due to the significant refactoring of MultiBackend? I'm thinking that a 9.1 release is probably safe, since @EreMaijala is the primary user of MultiBackend and has approved this, but I'm happy to wait if either of you would prefer.
config/vufind/ComposedDriver.ini
Outdated
;drivers_config_path = private | ||
|
||
; Definition of all the used drivers in the form <DriverName> = <DriverClass> | ||
; The name of config file for a driver needs te be the same <DriverName> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Typos -- should be "to be the same as"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed
config/vufind/ComposedDriver.ini
Outdated
; The format is: support_keys["<DriverName"] = "<key1>,<key2>,...,<keyN>" | ||
|
||
; Here are some examples how a configuration could look like for a combination of DAIA and PAIA | ||
; but it most likely wont work with the Demo driver |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"examples of how" might read a little better. "wont" should be "won't". I'm not entirely sure I understand why the Demo driver won't work, or why that is mentioned here (driver2 is not set to Demo in the example above).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fixed. I also explained why the Demo driver won't work.
* @param \VuFind\Config\PluginManager $configLoader Configuration loader | ||
* @param PluginManager $dm ILS driver manager | ||
*/ | ||
public function __construct( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since the configLoader and driverManager are dependencies of the base class, I think you could move this constructor there. I realize that MultiBackend has a different signature, but you could still move this constructor into the base class, and then simplify the MultiBackend constructor to call parent::__construct with the appropriate parameters.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
@@ -1530,7 +1530,7 @@ function ($loc) use ($excluded) { | |||
* @param array $holdInfo Contains most of the same values passed to | |||
* placeHold, minus the patron data. | |||
* | |||
* @return int | |||
* @return int|null |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
?int
might be more concise here (though I suspect you copied this from Aleph, so if you prefer to keep it consistent with that, I have no objection).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did this since @EreMaijala suggested to standardize it here: #3112 (comment)
It looks like it is done like this in a lot of places. So, I don't think this this violates any code style rules. But if you prefer ?int
I can change this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Feel free to leave it alone for now -- since it's consistent with other things, there's no need to change it. I think in the long term I'd prefer the ?
syntax instead of the |null
syntax since it is more concise -- but fixing that should probably become a separate project, and it's best to back it up with some kind of style checker if we make that decision. All out of scope for what you're doing here. :-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't mean to imply that you should use int|null
as ?int
is indeed better, though I also value keeping the docs of same function consistent. Perhaps we could also add more interfaces and use @inheritDoc
to avoid copy-pasting and ensure that the method definitions don't diverge.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The problem with inheritDoc is that php codesniffer doesn't support it properly, so we'd either need to disable comment validation or ignore lots of errors. I wish this would get addressed, but I think it's a very hard problem to solve based on the way codesniffer works.
@@ -1231,7 +1171,7 @@ protected function getSourceFromParams( | |||
* | |||
* @param string $source The source name of the driver to get. | |||
* | |||
* @return mixed On success a driver object, otherwise null. | |||
* @return mixed On success a driver object, otherwise null. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Out of scope for this PR, but maybe something @EreMaijala should consider in a follow-up -- I see that $source can be false-y based on the code below, but the comment and type here don't seem to reflect that.
module/VuFind/tests/unit-tests/src/VuFindTest/ILS/Driver/AbstractMultiDriverTest.php
Outdated
Show resolved
Hide resolved
It is absolutely fine for me if it is included in 10.0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, @ThoWagen -- this looks good to me. I've just made one small edit to add a missing word in a comment.
If @EreMaijala wants to include this in release 9.1, he's welcome to hit the merge button. Otherwise, I'll merge this as soon as we're done with work on release 9.1.
(Setting a 10.0 milestone to be sure this doesn't get forgotten if it isn't merged sooner). |
This new ILS Driver can be used to combine multiple other ILS Drivers. It allows to define multiple drivers for different driver methods and for many methods support drivers can be configured that provide additional information.
Here are some possible use cases for this:
However, the driver does not support MultiILS for login. So currently one can only combine one driver that provides patronLogin with drivers that don't use patron information. An exception to this is when the other drivers can use the patron information of the driver that is used for the patronLogin. But this could be implemented in the future if it is required .
This driver was heavily inspired by the Multibackend driver. Much of the code both drivers have in common was moved into the new AbstractMultiDriver class.
To understand how the driver is supposed to work it might be a good idea to first look into the unit-tests for it.