I come from a codeigniter background(I know a bit overdue) and I have small issue in creating custom form validation rules in Laravel 5.2.
Many of the tutorials I checked suggested doing such in the route file and setting up a request file etc, but I still am confused.
My need is very simple.
I have product categories that have sub categories.
For each product category, there needs to have a default sub category.
So when creating sub categories i have a tick asking if that sub category is the default category.
I need the form validator to trigger false during form validation in the sub category creation process if an already created sub category has been selected as the default sub category for that category.
Below is the part of my code that contains the form validation section.
$attributeNames = array(
'category_id' => 'UOM Category Name',
'sub_category_name' => 'Sub Category Name',
'is_default' => 'Default'
);
$validator = Validator::make($request->all(), [
'category_id' => 'required',
'sub_category_name' => 'required|unique:sub_categories,sub_category_name',
'is_default' => 'required', //POSSIBLE TRIGGER GOES HERE. In CI the a custom function name went here
]);
$validator->setAttributeNames($attributeNames);
if ($validator->fails()) {
$response = new Response();
return $response->setStatusCode(400, $validator->errors());
} else {
//proceed with store
}
Sorry about bad english.
Also, I have seen that form validation is done on a FormRequest. Is this best practice?
Yes, form requests exist for this. You can create a new FormRequest with the command php artisan make:request CreateSubCategoryRequest, then add your rules:
/**
* Get the validation rules that apply to the request.
*
* #return array
*/
public function rules()
{
return [
'category_id' => 'required|exists:categories,id', // If you're making sure the parent category ID exists
'sub_category_name' => 'required|unique:sub_categories,sub_category_name',
'is_default' => 'required|boolean'
];
}
For your default subcategory validation, I believe what you're asking is how you can validate if the parent category already has a default subcategory (only allowing 1 default subcategory per main category). In that case, you should assign a default_subcategory_id field to your main category record instead of on each subcategory itself. Then add a relationship to the main category model for the default subcategory and check if it's null.
As always the laravel docs are your best friend https://laravel.com/docs/5.2/validation#validation-quickstart
You have multiple options on how to and where to validate your request. Best practice depends on your usecase.
However, for me mostly creating a request type for a specfific entity was the best thing. You can use the artisan command to create a new reqest
php artisan make:request CategoryRequest
// or whatever your entity is called
You will find the file in app/Http/Requests.
You have a rules function where you can just paste your rules you need to validate
return [
'category' => 'required|min:5'
];
To create a custom rule you can put this in your AppServiceProvider.php
public function boot()
{
// custom rule
Validator::extend('foo', function($attribute, $value, $parameters, $validator) {
return $value == 'foo';
});
}
Custom Validation Rules: https://laravel.com/docs/5.2/validation#custom-validation-rules
Related
I need to add some fields to prestashop product (HSN code and one more). I am very new to prestashop and there is no guide to do the same with latest build 1.7.
I have followed answers made on stackoverflow and I am able to show the form fields but unable to save and validate the value.
Here is the code snippet I have used (I preferred this because it uses the hooks).
use PrestaShopBundle\Form\Admin\Type\TranslateType;
use PrestaShopBundle\Form\Admin\Type\FormattedTextareaType;
use Symfony\Component\Form\Extension\Core\Type\TextareaType;
use Symfony\Component\Form\Extension\Core\Type\FormType;
public function hookDisplayAdminProductsExtra($params)
{
$productAdapter = $this->get('prestashop.adapter.data_provider.product');
$product = $productAdapter->getProduct($params['id_product']);
$formData = [
'ebay_reference' => $product->ebay_reference,
];
$formFactory = $this->get('form.factory');
$form = $formFactory->createBuilder(FormType::class, $formData)
->add('ebay_reference', TranslateType::class, array(
'required' => false,
'label' => 'Ebay reference',
'locales' => Language::getLanguages(),
'hideTabs' => true,
'required' => false
))
->getForm()
;
return $this->get('twig')->render(_PS_MODULE_DIR_.'MyModule/views/display-admin-products-extra.html.twig', [
'form' => $form->createView()
]) ;
}
public function hookActionAdminProductsControllerSaveBefore($params)
{
$productAdapter = $this->get('prestashop.adapter.data_provider.product');
$product = $productAdapter->getProduct($_REQUEST['form']['id_product']);
foreach(Language::getLanguages() as $language){
$product->ebay_reference[ $language['id_lang'] ] =
$_REQUEST['form']['ebay_reference'][$language['id_lang']];
}
$product->save();
}
I am stucked at data saving part. Need some guidance to it in recommended way. Also need the suggestion to read the code of any module bundled with prestashop to help in this.
Add field in product Prestashop 1.7
This part of the code just describes how to create a form with necessary fields but it doesn't handle product class extending. So if you would have this attribute(ebay_reference) with all relations in your product class everything would work. So I suppose that you need to implement steps for /classes/Product.php and for src/PrestaShopBundle/Model/Product/AdminModelAdapter.php from the original answer of here Add field in product Prestashop 1.7 and add necessary field to the DB.
Also, if you don't want to modify or override default product class, you can create own table(s) to keep your data there like with id_product key, but it could be more difficult to propagate that data to all product instances in the store.
We are building an api endpoint where precision is required. We want to enforce strict validation on the parameters that are POST/PUT to the server.
If the api user sends a key=value pair that is not supported (eg. we allow the parameters [first_name, last_name] and the user includes an unsupported parameter [country]), we want the validation to fail.
Have tried building a custom validator called allowed_attributes (used as allowed_attributes:attr1,attr2,...), but for it to be usable in a $validationRules array, it has to be applied to the parent of a list of nested/child attributes (...because otherwise our custom validator did not have access to the attributes being validated).
Validator::extend('allowed_attributes', 'App\Validators\AllowedAttributesValidator#validate');
This created issues with other validators, where we then had to anticipate this parent/child structure and code around it, including additional post-validation clean-up of error keys and error message strings.
tl;dr: very dirty, not a clean implementation.
$validationRules = [
'parent' => 'allowed_attributes:first_name,last_name',
'parent.first_name' => 'required|string|max:40',
'parent.last_name' => 'required|string|max:40'
];
$isValid = Validator::make(['parent' => $request], $validationRules);
var_dump("Validation results: " . ($isValid ? "passed" : "failed"));
Any ideas/suggestions on how this can be accomplished more cleanly in laravel, without requiring the use of parent/child relationship to get access to the list of all $request attributes (within the custom validator)?
I preferred to post a new answer as the approach is different from the previous one and a bit more cleaner. So I would rather keep the two approaches separated and not mixed together in the same answer.
Better problem handling
After digging deeper into the Validation's namespace's source code since my last answer I figured out that the easiest way would have been to extend the Validator class to remplement the passes() function to also check what you needed.
This implementation has the benefit to also correcly handle specific error messages for single array/object fields without any effor and should be fully compatible with the usual error messages translations.
Create a custom validator class
You should first create a Validator class within your app folder (I placed it under app/Validation/Validator.php) and implement the passes method like this:
<?php
namespace App\Validation;
use Illuminate\Support\Arr;
use Illuminate\Validation\Validator as BaseValidator;
class Validator extends BaseValidator
{
/**
* Determine if the data passes the validation rules.
*
* #return bool
*/
public function passes()
{
// Perform the usual rules validation, but at this step ignore the
// return value as we still have to validate the allowance of the fields
// The error messages count will be recalculated later and returned.
parent::passes();
// Compute the difference between the request data as a dot notation
// array and the attributes which have a rule in the current validator instance
$extraAttributes = array_diff_key(
Arr::dot($this->data),
$this->rules
);
// We'll spin through each key that hasn't been stripped in the
// previous filtering. Most likely the fields will be top level
// forbidden values or array/object values, as they get mapped with
// indexes other than asterisks (the key will differ from the rule
// and won't match at earlier stage).
// We have to do a deeper check if a rule with that array/object
// structure has been specified.
foreach ($extraAttributes as $attribute => $value) {
if (empty($this->getExplicitKeys($attribute))) {
$this->addFailure($attribute, 'forbidden_attribute', ['value' => $value]);
}
}
return $this->messages->isEmpty();
}
}
This would essentially extend the default Validator class to add additional checks on the passes method. The check compute the array difference by keys between the input attributes converted to dot notation (to support array/object validation) and the attributes which have at least one rule assigned.
Replace the default Validator in the container
Then the last step you miss is to bind the new Validator class in the boot method of a service provider. To do so you can just override the resolver of the Illuminate\Validation\Factory class binded into the IoC container as 'validator':
// Do not forget the class import at the top of the file!
use App\Validation\Validator;
// ...
/**
* Bootstrap any application services.
*
* #return void
*/
public function boot()
{
$this->app->make('validator')
->resolver(function ($translator, $data, $rules, $messages, $attributes) {
return new Validator($translator, $data, $rules, $messages, $attributes);
});
}
// ...
Pratical use in a controller
You don't have to do anything specific to use this feature. Just call the validate method as usual:
$this->validate(request(), [
'first_name' => 'required|string|max:40',
'last_name' => 'required|string|max:40'
]);
Customize Error messages
To customize the error message you just have to add a translation key in your lang file with a key equal to forbidden_attribute (you can customize the error key name in the custom Validator class on the addFailure method call).
Example: resources/lang/en/validation.php
<?php
return [
// ...
'forbidden_attribute' => 'The :attribute key is not allowed in the request body.',
// ...
];
Note: this implementation has been tested in Laravel 5.3 only.
It should work for simple key/value pairs with this custom validator:
Validator::extendImplicit('allowed_attributes', function ($attribute, $value, $parameters, $validator) {
// If the attribute to validate request top level
if (strpos($attribute, '.') === false) {
return in_array($attribute, $parameters);
}
// If the attribute under validation is an array
if (is_array($value)) {
return empty(array_diff_key($value, array_flip($parameters)));
}
// If the attribute under validation is an object
foreach ($parameters as $parameter) {
if (substr_compare($attribute, $parameter, -strlen($parameter)) === 0) {
return true;
}
}
return false;
});
The validator logic is pretty simple:
If $attribute doesn't contains a ., we're dealing with a top level parameter, and we just have to check if it is present in the allowed_attributes list that we pass to the rule.
If $attribute's value is an array, we diff the input keys with the allowed_attributes list, and check if any attribute key has left. If so, our request had an extra key we didn't expect, so we return false.
Otherwise $attribute's value is an object we have to check if each parameter we're expecting (again, the allowed_attributes list) is the last segment of the current attribute (as laravel gives us the full dot notated attribute in $attribute).
The key here is to apply it to validation rules should like this (note the first validation rule):
$validationRules = [
'parent.*' => 'allowed_attributes:first_name,last_name',
'parent.first_name' => 'required|string|max:40',
'parent.last_name' => 'required|string|max:40'
];
The parent.* rule will apply the custom validator to each key of the 'parent' object.
To answer your question
Just don't wrap your request in an object, but use the same concept as above and apply the allowed_attributes rule with a *:
$validationRules = [
'*' => 'allowed_attributes:first_name,last_name',
'first_name' => 'required|string|max:40',
'last_name' => 'required|string|max:40'
];
This will apply the rule to all the present top level input request fields.
NOTE: Keep in mind that laravel validation is influenced by order of the rules as they are putted in rules array.
For example, moving the parent.* rule on bottom will trigger that rule on parent.first_name and parent.last_name; as opposed, keeping it as the first rule will not trigger the validation for the first_name and last_name.
This means that you could eventually remove the attributes that has further validation logic from the allowed_attributes rule's parameter list.
For example, if you would like to require only the first_name and last_name and prohibit any other field in the parent object, you might use these rules:
$validationRules = [
// This will be triggered for all the request fields except first_name and last_name
'parent.*' => 'allowed_attributes',
'parent.first_name' => 'required|string|max:40',
'parent.last_name' => 'required|string|max:40'
];
But, the following WON'T work as expected:
$validationRules = [
'parent.first_name' => 'required|string|max:40',
'parent.last_name' => 'required|string|max:40',
// This, instead would be triggered on all fields, also on first_name and last_name
// If you put this rule as last, you MUST specify the allowed fields.
'parent.*' => 'allowed_attributes',
];
Array Minor Issues
As far as I know, per Laravel's validation logic, if you were up to validate an array of objects, this custom validator would work, but the error message you would get would be generic on the array item, not on the key of that array item that wasn't allowed.
For example, you allow a products field in your request, each with an id:
$validationRules = [
'products.*' => 'allowed_attributes:id',
];
If you validate a request like this:
{
"products": [{
"id": 3
}, {
"id": 17,
"price": 3.49
}]
}
You will get an error on product 2, but you won't be able to tell which field is causing the problem!
I have an devices/index page where by default I don't want to show "out of order" devices unless I flag a proper checkbox
so I used the CakeDC search plugin 3 and I dit
DevicesTable
public $filterArgs = [
'include_out_of_order' => [
'type' => 'finder',
'finder' => 'outOfOrder',
'allowEmpty' => true
],
// ...
// lot of other filters
// ...
]
public function findOutOfOrder($query, array $options)
{
if(isset($options['include_out_of_order']) && $options['include_out_of_order'] == true)
return $query;
else
return $query->where(['Devices.device_status_id !=' => 2]); //status = 2 means the device is out of order
}
Now this works in my index view, but it work also in another two actions where I filter the records using the Search plugin.
I want this specific filter to apply just in index action, while all the other filters should works in the other actions of the Devices Controller
Is there another way to achieve what I'm trying to do using cakeDC plugin or I should use some custom code in my index action inside the controller? It would be easy but I'd like to find a more clean solution
I want this behavior to apply just in index action, not everytime I apply a filter
In your controller:
if ($this->request->action === 'index') {
$this->loadComponent('Search.Prg');
}
However, I would recommend the FoC Search plugin. It has a better architecture and suits Cake3 better. It can do the same but has a lot less code than the CDC plugin.
I'm planning to build an extension like Shopping Cart, Price Rule, or Catalog Price Rule.
I've already tried to learn something from existing Magento code, that you can see on:
app/code/core/Mage/Adminhtml/Block/Promo/Quote/Edit/Tab/Conditions.php
To show a Conditions Rule field, I've tried to add this script, but it didn't work properly
$fieldset->addField('conditions', 'text', array(
'name' => 'conditions',
'label' => Mage::helper('salesrule')->__('Conditions'),
'title' => Mage::helper('salesrule')->__('Conditions'),
))->setRule($model)->setRenderer(Mage::getBlockSingleton('rule/conditions'));
The question is:
How to display the conditional field properly on my custom field?
How to apply rule conditions on the front-end?
Thanks in advance.
update,
take a look at my screenshot
https://docs.google.com/file/d/0BwLN4KpQhoGbU181R0ZKanJSdVE/edit?usp=drivesdk
this is my form.php:
<?php
class KS_Kscoba_Block_Adminhtml_Tcoba_Edit_Tab_Form
extends Mage_Adminhtml_Block_Widget_Form
/*
extends Mage_Adminhtml_Block_Widget_Form
implements Mage_Adminhtml_Block_Widget_Tab_Interface
*/
{
protected function _prepareForm()
{
$model = Mage::registry('current_promo_quote_rule');
$form = new Varien_Data_Form();
$this->setForm($form);
$fieldset = $form->addFieldset("kscoba_form", array("legend"=>Mage::helper("kscoba")->__("Item information")));
$fieldset->addField("kolom1", "text", array(
"label" => Mage::helper("kscoba")->__("Kolom 1"),
"name" => "kolom1",
));
$fieldset->addField('kolom2', 'select', array(
'label' => Mage::helper('kscoba')->__('Kolom 2'),
'values' => KS_Kscoba_Block_Adminhtml_Tcoba_Grid::getValueArray1(),
'name' => 'kolom2',
));
/*
problem start here
*/
$renderer = Mage::getBlockSingleton('adminhtml/widget_form_renderer_fieldset')
->setTemplate('promo/fieldset.phtml')
->setNewChildUrl($this->getUrl('*/promo_quote/newConditionHtml/form/rule_conditions_fieldset'));
$fieldset = $form->addFieldset('conditions_fieldset', array(
'legend'=>Mage::helper('salesrule')->__('Apply the rule only if the following conditions are met (leave blank for all products)')
))->setRenderer($renderer);
$fieldset->addField('conditions', 'text', array(
'name' => 'conditions',
'label' => Mage::helper('salesrule')->__('Conditions'),
'title' => Mage::helper('salesrule')->__('Conditions'),
))->setRule($model)->setRenderer(Mage::getBlockSingleton('rule/conditions'));
if (Mage::getSingleton("adminhtml/session")->getTcobaData())
{
$form->setValues(Mage::getSingleton("adminhtml/session")->getTcobaData());
Mage::getSingleton("adminhtml/session")->setTcobaData(null);
}
elseif(Mage::registry("tcoba_data")) {
$form->setValues(Mage::registry("tcoba_data")->getData());
}
return parent::_prepareForm();
}
}
am I missing something?
1. Conditions Field
I may be overlooking another issue, but when I tested your form.php, the conditions field was missing because Mage::registry('current_promo_quote_rule') was undefined. The conditions field appeared on the page after I populated $model with a Mage_SalesRule_Model_Rule object.
Magento 1.8 registers the current_promo_quote_rule in _initRule() and editAction() of the Mage_Adminhtml_Promo_QuoteController (app/code/core/Mage/Adminhtml/controllers/Promo/QuoteController.php).
2. Frontend
Using shopping cart price rules as an example, the discounted price is applied in the frontend through the checkout module.
Mage/Checkout/controllers/CartController.php has a couponPostAction() function which is called when the user submits a coupon code from the cart or checkout page. This function gets the cart's Mage_Sales_Model_Quote object, sets the coupon code on that object, and refreshes the totals of each item using the collectTotals() function of Mage_Sales_Model_Quote.
The quote object's collectTotals() gets the related Mage_Sales_Model_Quote_Address objects and calls their collectTotals() functions. Those functions get each of the collector objects associated with the address and call its collect() method.
One of those collector objects is a Mage_SalesRule_Model_Quote_Discount, whose collect() method gets each Mage_Sales_Model_Quote_Item associated with this address, then calculates and stores its discount using a Mage_SalesRule_Model_Validator.
The specific logic in the conditions is read and applied deeper in the SalesRule module.
Does anyone know how can I add a custom product attribute with a widget renderer?
You can see this in Promo rules if you select SKU you'll got an Ajax popup with product selection.
so how would I go about it?
in :
$installer->addAttribute(Mage_Catalog_Model_Product::ENTITY...
In other words, how can I use a widget to select custom attribute values?
EDIT:
The scenario is as follows:
I would like to create a product attribute that will, upon a button click, open a product selection widget.
After the selection, the selected SKU's will go in in a comma delimited format.
This behavior can be seen in the catalog and shopping cart price rules.
If you filter the rule by SKU (SKU attribute must be enabled to "apply to rules"), you'll get a field and a button that will open the product selection widget.
Here is some thoughts that should get you going on the right track:
First, in a setup script, create your entity:
$installer->addAttribute('catalog_product', 'frontend_display', array(
'label' => 'Display Test',
'type' => 'varchar',
'frontend_model' => 'Test_Module/Entity_Attribute_Frontend_CsvExport',
'input' => 'select',
'required' => 0,
'user_defined' => false,
'group' => 'General'
));
Make sure to set the frontend_model to the model that you are going to use. The frontend model affects the display of the attribute (both in the frontend and the adminhtml sections).
Next, create yourself the class, and override one or both of the following functions:
public function getInputType()
{
return parent::getInputType();
}
public function getInputRendererClass()
{
return "Test_Module_Block_Adminhtml_Entity_Renderer_CsvExport";
}
The first (getInputType()) is used to change the input type to a baked in input type (see Varien_Data_Form_Element_* for the options). However, to set your own renderer class, use the latter function - getInputRendererClass(). That is what I am going to demonstrate below:
public function getElementHtml()
{
return Mage::app()->getLayout()->createBlock('Test_Module/Adminhtml_ExportCsv', 'export')->toHtml();
}
Here, to clean things up, I am instantiating another block, as the element itself doesn't have the extra functions to display buttons and the like.
Then finally, create this file:
class Test_Module_Block_Adminhtml_ExportCsv extends Mage_Adminhtml_Block_Widget
{
protected function _prepareLayout()
{
$button = $this->getLayout()->createBlock('adminhtml/widget_button')
->setData(array(
'label' => $this->__('Generate CSV'),
'onclick' => '',
'class' => 'ajax',
));
$this->setChild('generate', $button);
}
protected function _toHtml()
{
return $this->getChildHtml();
}
}
This doesn't cover the AJAX part, but will get you very close to getting the rest to work.