A FormView object in Symfony contains several variables, that can be accessed via twig using the public vars property.
Two of those variables are value and data.
So, supposing that we have our form variable in twig, we can access them using form.vars.data and form.vars.value.
The documentation is clear about the meaning of those properties:
value: The value that will be used when rendering (commonly the value HTML attribute).
data: The normalized data of the type.
but when I use {{ dump(form.vars) }} and compare form.vars.value and form.vars.data they look like identical. Why? What's the correct meaning and proper usage of those two properties?
Take for example a DateType field.
Here, value would be something like the string 2016-06-10.
data on the other hand would be a corresponding DateTime-Object.
When using Text fields, you will not see any difference because in both cases there will be just a string.
Related
I've got a list of variables. Let's call it a=1,b=2,c=3. I would like to pass the variable name to a function as a string and then retrieve its' value. Is there a way to achieve this in PHP? I', hoping to use this in page object pattern with Gherkin to pass a variable name to a gherkin step.
I was able to resolve the problem by using ${$arg} notation as described by #waterloomatt above.
I would like to pass string input with commas through laravel form text field. You can provide multiple numbers separated by commas, the application will handle imploding into array.
The issue is that laravel (or web browser) by default will change comma to '%2C'. I know it's a safety feature, but this is not too big concern in case of this application.
Is there a way to disable this?
Already tried to use {!! !!} instead of standard {{ }}
{{ Form::text('number', null) }}
Try using POST method in form tag instead of GET method.
It will not show field value in URL.
I come from a Javascript and Ruby background and this is baffling me. Laravel can store two different array syntaxes in my DB depending on how I handle my array serialization. In my understanding, collect() creates a true Laravel array. Why then is it storing a serialized array? Furthermore, is the {'key':'value'}syntax still an array despite having no square brackets surrounding it? It looks to me like a standard object or a hash, but if I try to do toArray() on it, it recognizes that it's already an array and throws an error. What am I misunderstanding and what is correct here?
Given a form:
edit.blade:
<select class="form-control m-bootstrap-select m_selectpicker" name="temp">
<option value={{ json_encode(array("$key"=>"$cph"), JSON_FORCE_OBJECT) }}>
</select>
The following two controllers syntaxes yield different database insertions.
PageController.php:
$page->cph_default = collect($request->temp);
$page->save();
Laravel stores an array with the following syntax in my database: ["{\"11\":\"1100\"}"]
PageController.php
$page->cph_default = json_decode($request->temp, true);
$page->save();
Laravel stores an array with the following syntax in my database: {"19": "1900"}
A PHP array with the syntax ['key' => 'value'] is called an associative array, and acts like a hash. A JSON-encoded associative array will show up as an object in JSON syntax. Examples and more info on PHP.net
Laravel's collect() function is a convenience wrapper for creating a new Collection. A Collection is not really a "true Laravel array" so much as it is an object wrapper with some convenience methods for modifying the underlying array. Think of it like a scalar object.
In your form when generating the option value, the submitted form value ($request->temp) will be a JSON-encoded string. Literally the string '{"19": "1900"}'.
Calling collect($request->temp) does no modification to that submitted data. It's simply creating a new Collection (array), containing a single string item. If you were to call toArray() on the collection, you'd see something like this:
[
0 => '{"19": "1900"}'
]
Note that this is not an associative array, it is a numeric array with a zero-based index. This array is encoded as a JSON array, not as a hash object. Hence your first result.
Calling json_decode($request->temp) is turning the string back into an associative array (hash) before saving it via Eloquent. Eloquent then calls json_encode() again internally, turning it back into the same JSON as your form's option value.
If you were to decode the form value before creating the collection, the resulting database save would look identical. You'd just have the convenience of the Collection wrapper:
$page->cph_default = collect(json_decode($request->temp, true));
$page->save();
If you're treating the column as a JSON type, you should ensure the data passed to Eloquent is NOT already encoded, or you'll get the double encoding experienced in your first example.
No Matter What is.
First If you are stroring the array into database convert to JSON FORMAT
For eg
$variable = json_encode($request->controlname);
This is the right way to store array
Into database
I have a strange problem with Symfony's JsonResponse that I cannot seem to figure out. I have the following action in my controller:
public function loadTemplateAction($id)
{
$repository = $this->getDoctrine()->getRepository('AppBundle:Host');
$template = $repository->find($id);
return new JsonResponse((array)$template);
}
It's supposed to find the given template in my repository by the passed id. I want to use the returned data in an ajax call. It does what I want, but it seems to "prefix" all the field names with an asterisk. So it returns a response like this:
I can't figure out why it's putting those asterisks in front of the field names (they are obviously not named that way in my datasource). Does anybody have a clue what could be causing this type of behaviour?
First of all, see http://php.net/manual/en/language.types.array.php:
If an object is converted to an array, the result is an array whose
elements are the object's properties. The keys are the member variable
names, with a few notable exceptions: integer properties are
unaccessible; private variables have the class name prepended to the
variable name; protected variables have a '*' prepended to the
variable name. These prepended values have null bytes on either side.
This can result in some unexpected behaviour:
You probably should not just typecast your object to arrays and JSON encode them. Have a look at some of the serialization solutions that exist:
http://symfony.com/doc/current/cookbook/serializer.html
http://jmsyst.com/libs/serializer
These libraries offer great control on how to serialize your objects to different formats, including JSON.
If you need less control on how your objects are serialized to JSON, you could just implement the JsonSerializable interface.
I am having trouble understanding the concept of serialize/unserialize in PHP.
Assume I have a very simple PHP object (class someObject) and after setting the attributes of that object I want to serialize it:
So I call: serialize($someObject);
I want to transfer this serialized object into another php skript via a html form so I set it as a hidden value:
<input type="hidden" name="someObject" value="<? print $someObject; ?>"
In the next php script I want to use unserialize to get my object back and transfer it e.g. to a databae.
$unserialize = unserialize($_POST['someObject'])
But this always returns BOOL(false) - so what am I missing here?
Thanks for your help!
A serialized string looks like this:
O:1:"a":1:{s:3:"foo";s:3:"100";}
You have tourlencode/urldecode the serialized string to prevent any characters in the serialized representation from breaking your markup. Have a look at your page source. The first quote likely ended your HTML value attribute. So you got something like:
<input ... value="O:1:"a":1:{s:3:"foo";s:3:"100";}">
So your $_POST will never contain the full serialized string, but only O:1:
If this is not the issue, make sure you got a serialized string from the object in the first place. Also please be aware that there some objects cannot be serialized or have modified behavior when (un)serialized. Please refer to the Notes in PHP Manual for serialize for details.
If you dont need to send objects across different servers running PHP, consider persisting them in a Session instead. It's easier, less error prone and more secure because the object cannot be tampered with while in transit.
You need to have the class defined in your second script before you unserialize() the object