PHPackages rickselby/laravel-request-field-types - PHPackages - PHPackages [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register) 1. [Directory](/) 2. / 3. [Utility & Helpers](/categories/utility) 4. / 5. rickselby/laravel-request-field-types AbandonedArchivedLibrary[Utility & Helpers](/categories/utility) rickselby/laravel-request-field-types ===================================== Allow definitions of common input field types for requests 3.8.0(2y ago)15.2k[1 PRs](https://github.com/rickselby/laravel-request-field-types/pulls)MITPHPCI passing Since Nov 25Pushed 5mo ago1 watchersCompare [ Source](https://github.com/rickselby/laravel-request-field-types)[ Packagist](https://packagist.org/packages/rickselby/laravel-request-field-types)[ RSS](/packages/rickselby-laravel-request-field-types/feed)WikiDiscussions main Synced 2mo ago READMEChangelog (10)Dependencies (3)Versions (22)Used By (0) Laravel Request Field Types =========================== [](#laravel-request-field-types) [![PHP 7.0+](https://camo.githubusercontent.com/98e06ab279ef7d8f5dc610b12861b445a427f985f0ced740b6982d8fac4b3fe8/68747470733a2f2f696d672e736869656c64732e696f2f62616467652f7068702d372e302532422d626c75652e737667)](https://camo.githubusercontent.com/98e06ab279ef7d8f5dc610b12861b445a427f985f0ced740b6982d8fac4b3fe8/68747470733a2f2f696d672e736869656c64732e696f2f62616467652f7068702d372e302532422d626c75652e737667)[![Build Status](https://camo.githubusercontent.com/493bcdc36c6f9e463b495241e807794a4d5c31e5ac25aa16527cff9930312f98/68747470733a2f2f696d672e736869656c64732e696f2f7472617669732f7269636b73656c62792f6c61726176656c2d726571756573742d6669656c642d74797065732e737667)](https://travis-ci.org/rickselby/laravel-request-field-types)[![SensioLabs Insight](https://camo.githubusercontent.com/09c445ff5dc9338972c838fefde9d8756d09433d30d20ccb4229270e72cf6096/68747470733a2f2f696d672e736869656c64732e696f2f73656e73696f6c6162732f692f30363563333264652d313134322d343934332d623565642d6235636536373731656338612e737667)](https://insight.sensiolabs.com/projects/065c32de-1142-4943-b5ed-b5ce6771ec8a)[![Code Coverage](https://camo.githubusercontent.com/d3666c523a8f8590cc952a32ec589761700e6e7b4d4d7fc46c5a2729bd5940a6/68747470733a2f2f696d672e736869656c64732e696f2f636f6465636f762f632f6769746875622f7269636b73656c62792f6c61726176656c2d726571756573742d6669656c642d74797065732e737667)](https://codecov.io/gh/rickselby/laravel-request-field-types)[![Software License](https://camo.githubusercontent.com/074b89bca64d3edc93a1db6c7e3b1636b874540ba91d66367c0e5e354c56d0ea/68747470733a2f2f696d672e736869656c64732e696f2f62616467652f6c6963656e73652d4d49542d627269676874677265656e2e737667)](LICENSE) A way of defining common input field types in a central location and use them among all requests in your app. **NB: 3.x passes tests but I haven't tried it 'for real' yet; I will do so at some point and may write better tests...** Laravel Request Field TypesLaravelPHP**3.x**5.6+7.1.3+[2.x](https://github.com/rickselby/laravel-request-field-types/tree/2.x)5.4 – 5.57.0+Installing ---------- [](#installing) ``` $ composer require rickselby/laravel-request-field-types ``` Under Laravel >=5.5, the service provider will be automatically registered. Terminology ----------- [](#terminology) 'Field' is used as two different terms here; I hope I've been clear throughout the documentation: - **Field Type** - e.g. date, name, email... - **Input Field** - the fields posted as part of a request Defining field types -------------------- [](#defining-field-types) Each field must implement `RickSelby\LaravelRequestFieldTypes\InterfacesFieldTypeInterface`. `RickSelby\LaravelRequestFieldTypes\BaseFieldType` implements the interface and sets up common functions, and is a good starting place to implementing your own fields. Two things need implementing from the `BaseFieldType`: - `rules()` - the default rules for an input field - `setMessagesFor($inputField)` - define any custom messages for the input field An example field is included (DateFieldType). Using field types in requests ----------------------------- [](#using-field-types-in-requests) Start by extending `RickSelby\LaravelRequestFieldTypes\FieldTypesRequest`instead of `Illuminate\Foundation\Http\FormRequest`. Then, two functions need defining: - **defineRules()** - **defineMessages()** There is no need to define `rules()` and `messages()`; these are managed within the class. ### `defineRules()` [](#definerules) Instead of adding rules to an array in `rules()`, we can define them using functions here. For a defined field types, use `setInputsFor()`: ``` $this->setInputsFor(DateFieldType::class, ['start_date', 'end_date']); // Passing a key => value pair allows extra rules to be added to an input field; $this->setInputsFor(DateFieldType::class, ['start_date' => 'required']); // Keyed and non-keyed field names can be mixed as required $this->setInputsFor(DateFieldType::class, ['start_date' => 'required', 'end_date']); ``` For other fields, rules can be set directly with `setRules()`: ``` $this->setRules('otherfield', ['required', 'numeric']); ``` #### Ordering [](#ordering) The request keeps track of the order rules are set, and returns the rules in the given order, so the validation messages are returned in the desired order. It is possible to override the field order, if preferred: ``` $this->setFieldOrder(['field1', 'field2'...]); ``` ### `defineMessages()` [](#definemessages) Custom messages for defined field types' default rules can be set in the field type. Other messages can be set for rules using `setMessage()` ``` $this->setMessage('start_date.required', 'A start date must be provided.'); ``` Modifying the request data -------------------------- [](#modifying-the-request-data) *(This is probably a contentious way of modifying input, but it makes sense to me...)* Say we have a date field. The input field knows what format will be generated, and the request will know what format to validate. Where does it get converted for use in the rest of the app? Do we need to define the date format elsewhere as well, or can this be handled in the request? Since the request knows about the expected input formats, it seems the right place to modify (valid) data for use in the rest of the app. The supplied `DateFieldType` does this; the `mapAfterValidationFunction` will be run on all input fields set for this field type once validation has suceeded but before the validation returns. If you need to do more complex alterations to the request data, the `modifyInputAfterValidation` function can be overridden directly. ...but why? ----------- [](#but-why) This was mostly driven by the desire to modify the request data. Starting with a date field - must I define the date format in every request? Can I have a single base request that others extend from, and I define it there? Can I convert the input to a carbon instance before it is returned to the app? Then, other fields fell into the same pattern - other inputs that could be modified to a better format for use in the app. The base request for the app became large and unwieldy, and thus this class was born. Perhaps it is overkill, even for defining common field types within an app. ### Health Score 41 — FairBetter than 89% of packages Maintenance48 Moderate activity, may be stable Popularity19 Limited adoption so far Community10 Small or concentrated contributor base Maturity72 Established project with proven stability Bus Factor1 Top contributor holds 93.8% of commits — single point of failure How is this calculated?**Maintenance (25%)** — Last commit recency, latest release date, and issue-to-star ratio. Uses a 2-year decay window. **Popularity (30%)** — Total and monthly downloads, GitHub stars, and forks. Logarithmic scaling prevents top-heavy scores. **Community (15%)** — Contributors, dependents, forks, watchers, and maintainers. Measures real ecosystem engagement. **Maturity (30%)** — Project age, version count, PHP version support, and release stability. ### Release Activity Cadence Every ~127 days Total 19 Last Release 790d ago Major Versions 1.1.1 → 2.02017-12-04 2.x-dev → 3.02018-05-19 ### Community Maintainers ![](https://www.gravatar.com/avatar/6cc8910980f053d8ceb2e9d938427cf03ae509884763a10f916b4eef5591934f?d=identicon)[rickselby](/maintainers/rickselby) --- Top Contributors [![rickselby](https://avatars.githubusercontent.com/u/1564517?v=4)](https://github.com/rickselby "rickselby (90 commits)")[![dependabot[bot]](https://avatars.githubusercontent.com/in/29110?v=4)](https://github.com/dependabot[bot] "dependabot[bot] (4 commits)")[![StyleCIBot](https://avatars.githubusercontent.com/u/11048387?v=4)](https://github.com/StyleCIBot "StyleCIBot (2 commits)") ### Code Quality TestsPHPUnit ### Embed Badge ![Health badge](/badges/rickselby-laravel-request-field-types/health.svg) ``` [![Health](https://phpackages.com/badges/rickselby-laravel-request-field-types/health.svg)](https://phpackages.com/packages/rickselby-laravel-request-field-types) ``` ### Alternatives [wireui/wireui TallStack components 1.8k1.3M16](/packages/wireui-wireui)[livewire/volt An elegantly crafted functional API for Laravel Livewire. 4195.3M84](/packages/livewire-volt)[ramonrietdijk/livewire-tables Dynamic tables for models with Laravel Livewire 21147.4k](/packages/ramonrietdijk-livewire-tables) PHPackages © 2026 [Directory](/)[Categories](/categories)[Trending](/trending)[Changelog](/changelog)[Analyze](/analyze)