Open
Conversation
… type safety This refactor modernizes the Barcode Lookup Provider system to improve extensibility, type safety, and maintainability: Core Architecture Changes: - Made LookupProvider abstract with required methods (getName, getDescription, getConfigKey) to enforce compile-time contracts for all providers - Replaced hardcoded provider list with dynamic provider registry in config-dist.php (LOOKUP_PROVIDERS constant) for easier addition of new providers - Implemented getProviders() factory method in BarcodeLookup to dynamically load providers from configuration Provider Interface Improvements: - Added getConfigHtml() method for providers to define their own configuration UI - Added getConfigFieldId() to identify main config field for dynamic enable/disable - Added saveSettings() hook for custom provider save logic - Added setId()/getId() for unique provider identification - Unified enablement check to single isEnabled() method Settings UI Enhancements: - Moved provider-specific configuration fields from settings.php into respective provider classes (better separation of concerns) - Implemented generic JavaScript handler for toggling config fields based on provider enablement checkbox - Improved UI layout with proper vertical stacking of provider description and config fields Code Quality: - Removed all require_once statements for individual providers from LookupProvider base class (now loaded dynamically) - Added explicit type casting for EditFieldBuilder output to satisfy Psalm - Updated Psalm baseline to reflect resolved type issues - Improved error messages to use getName() instead of property access This refactor maintains backward compatibility while making it significantly easier to add new lookup providers - developers now only need to: 1. Create a new provider class extending LookupProvider 2. Implement required abstract methods 3. Add entry to LOOKUP_PROVIDERS in config-dist.php
…nfiguration options and database defaults.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is based on the work I did in #285
That allows the user to use webhooks to look up products. Those could be make.com / n8n automations etc.
Each webhook is expected to accept a barcode query param with the scanned barcode.
Each webhook is expected to return a JSON object like this:
If more than one lookup is present the first one is the suggested one, the others are treated as BBuddy Federation alt names.
Webhooks are queried from top to bottom and the providers concludes once it gets the first non-empty response.
That again adds flexibility to introduce new lookup providers in much easier fashion :)