{"id":24488065,"url":"https://github.com/talpx1/laravel-registry","last_synced_at":"2025-07-28T17:05:23.215Z","repository":{"id":272050749,"uuid":"915369370","full_name":"Talpx1/laravel-registry","owner":"Talpx1","description":"Easy registry management for Laravel","archived":false,"fork":false,"pushed_at":"2025-02-07T23:55:58.000Z","size":278,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":1,"default_branch":"main","last_synced_at":"2025-03-15T00:13:28.566Z","etag":null,"topics":["laravel","laravel-package","registry"],"latest_commit_sha":null,"homepage":"","language":"PHP","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/Talpx1.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG.md","contributing":null,"funding":".github/FUNDING.yml","license":"LICENSE.md","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null},"funding":{"buy_me_a_coffee":"talp1"}},"created_at":"2025-01-11T17:05:47.000Z","updated_at":"2025-02-07T23:56:02.000Z","dependencies_parsed_at":"2025-01-11T18:35:26.478Z","dependency_job_id":"a3d560ba-13de-40b4-97c9-70c950bb0f58","html_url":"https://github.com/Talpx1/laravel-registry","commit_stats":null,"previous_names":["talpx1/laravel-registry"],"tags_count":0,"template":false,"template_full_name":"spatie/package-skeleton-laravel","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Talpx1%2Flaravel-registry","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Talpx1%2Flaravel-registry/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Talpx1%2Flaravel-registry/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Talpx1%2Flaravel-registry/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/Talpx1","download_url":"https://codeload.github.com/Talpx1/laravel-registry/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":243663585,"owners_count":20327306,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["laravel","laravel-package","registry"],"created_at":"2025-01-21T16:18:12.834Z","updated_at":"2025-03-15T00:13:37.253Z","avatar_url":"https://github.com/Talpx1.png","language":"PHP","funding_links":["https://buymeacoffee.com/talp1","https://buymeacoffee.com/talp1)!"],"categories":[],"sub_categories":[],"readme":"# Laravel Registry\n\nTODO: yet to publish  \n[![Latest Version on Packagist](https://img.shields.io/packagist/v/talp1/laravel-registry.svg)](https://packagist.org/packages/talp1/laravel-registry)\n[![Total Downloads](https://img.shields.io/packagist/dt/talp1/laravel-registry.svg)](https://packagist.org/packages/talp1/laravel-registry)  \n\n[![GitHub Tests Action Status](https://img.shields.io/github/actions/workflow/status/Talpx1/laravel-registry/run-tests.yml?branch=main\u0026label=tests)](https://github.com/Talpx1/laravel-registry/actions?query=workflow%3Arun-tests+branch%3Amain)\n[![GitHub Code Style Action Status](https://img.shields.io/github/actions/workflow/status/Talpx1/laravel-registry/fix-php-code-style-issues.yml?branch=main\u0026label=code%20style)](https://github.com/Talpx1/laravel-registry/actions?query=workflow%3A\"Fix+PHP+code+style+issues\"+branch%3Amain)  \n\n[![Hire Me](https://img.shields.io/badge/hire_me-available!-lime)](mailto:hello@simonecerruti.com)\n[![Support](https://img.shields.io/badge/support-thanks_\u003c3-magenta)](https://buymeacoffee.com/talp1)\n\nEasy registry management for Laravel\n\nNo need to create your own registry management anymore!  \nLaravel Registry ships with many features to help you profile companies, customers and people with all the necessary data such as email, phone number, socials...\n\n```php\n//TODO\nRegistry::create([\n    'type' =\u003e RegistryTypes::CUSTOMER\n])\n```\n\n## Support\n\n[\u003cimg src=\"https://martinaway.com/wp-content/uploads/2023/08/Buy-me-a-coffee.png\" /\u003e](https://buymeacoffee.com/talp1)\n\nI'm a self-employed solo developer, trying to make cool and hopefully useful pieces of software.  \nIf you are a company or you used this package in one of your projects, please consider [supporting me](https://buymeacoffee.com/talp1)!  \nThanks \u003c3\n\n## Installation\n\nYou can install the package via composer:\n\n```bash\ncomposer require talp1/laravel-registry\n```\n\nYou can publish and run the migrations with:\n\n```bash\nphp artisan vendor:publish --tag=\"laravel-registry-migrations\"\nphp artisan migrate\n```\n\nYou can publish the config file with:\n\n```bash\nphp artisan vendor:publish --tag=\"laravel-registry-config\"\n```\n\nThis is the contents of the published config file:\n\n```php\nreturn [\n    //TODO\n];\n```\n\n## Usage\n\n```php\n//TODO\n```\n## Phone number advanced support\n\nThis package does NOT include any phone number validation or formatting functionality.  \nIf you need to validate, format or perform more advanced checks on phone numbers, consider using a separate package such as [`propaganistas/laravel-phone`](https://github.com/Propaganistas/Laravel-Phone).\nThis decision was made to keep the package focused on its primary purpose of providing a registry system, and to avoid adding functionality that could be better handled by a separate package.\n\nExample of how to use `propaganistas/laravel-phone` with this package:\n```php\n$phone_number = $person-\u003ephone_numbers-\u003efirst()-\u003eprefixed;\n\n//helper phone() is form propaganistas/laravel-phone\nphone($phone_number)-\u003eformatE164();\nphone($phone_number)-\u003eformatForCountry(Countries::ITALY-\u003eiso3166Alpha2Code());\nphone($phone_number, Countries::ITALY-\u003eiso3166Alpha2Code())-\u003eformatInternational();\n```\nThis package only offers a basic `prefixed` attribute that formats a phone number with a country phone prefix, if any is specified. Like so: `+{country_prefix} {phone_number}`. This may be useful to better integrate with `propaganistas/laravel-phone`.\n\n## Database Design Choices\n\n### Primitive Types vs Foreign Keys/Enum Type Columns\n\nSome db columns like `phone_numbers.line_type`, `social_network_profiles.social_network`, ... are of primitive types.  \nOne could argue that, since their possible values are a finite set of values, they could be a separate table with a foreign key, or an enum type column, better enforcing db strictness and integrity.\nWhile that's true:\n- solution 1 (tables with FK) would generate A LOT of tables, causing the consumer application to have a rather messy and noisy db.  \n- solution 2 (enum type column) is not considered a best practice for scalability and future proofing. And since this package aims to be highly customizable and rather flexible, this seemed not the right way to go.  \n\nThe chosen solution relies on the fact that database consistency can be enforced at the application level, with proper validation, such as Laravel's [`enum` rule](https://laravel.com/docs/validation#rule-enum) or [`in` rule](https://laravel.com/docs/validation#rule-in).  \nExample:  \n```php\n//enum rule\n$input = ['social_network' =\u003e 'instagram'];\n\nValidator::make($input, [    \n    'social_network' =\u003e ['required', 'string', Rule::enum(SocialNetworks::class)],\n]);\n\n//in rule\n$input = ['phone_number_prefix' =\u003e '39'];\n\nValidator::make($input, [    \n    'phone_number_prefix' =\u003e ['required', 'numeric', Rule::in(Countries::allPhonePrefixes())],\n]);\n```\n### Violation of Normal Form Best Practices\nThe addresses table is NOT in normal form, as one could deduce the city and country from the postal code.  \nBut this would mean to create a table with all the postal codes for each city, and it would be HUGE and noisy. The same is true for an enum type column.  \nPlus it's possible, for the enum case, that there are 2 equals postal codes for different city, maybe in different countries, causing even more troubles. Not to mention performance etc.  \nSo in this case may be ok to violate NF best practices and enforce a good application-side validation on postal codes. In such case [`axlon/laravel-postal-code-validation`](https://github.com/axlon/laravel-postal-code-validation) may be of interest.\n\n### Purpose Aware Addresses\nEven if the addresses table should only know about addresses and not their function/\"purpose\", in the schema they still have the responsibility to store this info.  \nLet's take as an example a person residence address: this info could be stored in a dedicated column of the `people` table, maybe called `residence_address_id`, which would be a FK to the `addresses` table.  \nTheoretically everything would work, but this design would also introduce inefficiencies, a potential risk of inconsistent data input and, consequently, the associated added complexity for validation to avoid this possibility.  \nThis scenario arises from the fact that the addresses are tied to the \"owner\" via a polymorphic relationship.  \nSuppose we have an address table already populated with data. Nothing prevents us from assigning in our `residence_address_id` column of a person X, the id of an address belonging to a person Y who has nothing to do with our person X. The cause of this is the dual possibility of assigning a correlation between `address` and `person`, once via the polymorphic relationship in the `addresses` table (address belongs to person), another time in the `residence_address_id` column of the `people` table (the person has a residential address, although at a relationship level it would be more correct to say that the person belongs to the address)\nWe should therefore take the trouble, at a software validation level, to make sure that the address belongs to person X before assigning it to him.  \nNow that we have analyzed the problems of inconsistency and complexity, let's look at the problem of inefficiency.\nTo create the record for the residential address in the `addresses` table, we need to define who owns that address (due to the polymorphic relationship). So first we should create the person, with the `residence_address_id` column set to null. Now we can create the address, then edit the person record and insert the id of the newly created address into the `residence_address_id` column. For a total of 3 steps.  \nThe solution adopted, that is to make the addresses aware of their purpose (such as a residence), solves the problems mentioned.\nIn fact, now there is no longer the possibility of defining a double correlation between `address` and `person`, as the `residence_address_id` column does not exist. Consequently, once the person has been created, we can create their residential address, specifying the purpose of this address, precisely, as a residence, without worrying about having to carry out complex validation checks. For a total of 2 steps.  \nIn addition we had an advantage in scalability and flexibility, as we can now define new addresses with different purposes for that person (e.g. a private office) without having to modify the migration of the `people` table and add a column for each 'purpose' of address.  \nThe disadvantage is that, to ensure that a person cannot have multiple residential addresses assigned, we will have to do some validation on the software side.  \nBy having the `purpose` column of the address table `nullable` (in case an address has no particular purpose), this design should be robust and flexible enough for most cases. For more advanced eventualities, it is always possible to modify the migration.\n\n## Testing\n\n```bash\ncomposer test\n```\n\n## Changelog \n\nPlease see [CHANGELOG](CHANGELOG.md) for more information on what has changed recently.\n\n## Contributing\n\nPlease see [CONTRIBUTING](CONTRIBUTING.md) for details.\n\n## Security Vulnerabilities\n\nPlease review [our security policy](../../security/policy) on how to report security vulnerabilities.\n\n## Credits\n\n-   [Simone Cerruti (Talp1)](https://github.com/Talpx1)\n-   [All Contributors](../../contributors)\n\n## License\n\nThe MIT License (MIT). Please see [License File](LICENSE.md) for more information.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Ftalpx1%2Flaravel-registry","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Ftalpx1%2Flaravel-registry","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Ftalpx1%2Flaravel-registry/lists"}