I wonder where can I get more information about special syntax like #somevar or %somevar% in symfony2's yaml configuration?
For example, using # defines a call to a service, that is how we pass dependencies to services. %somevar% on the other hand refers to the value of an already defined parameter with the name somevar.
So, if I do:
parameters:
custom: "some value"
another: %custom%
then another will be populated with the value of custom, which in my case is "some value". My question is, where are these relations documented?
My particular need is to be able to reference an element of an array, something like %somevar[somekey]%, but that syntax doesn't work.
Thanks in advance!
EDIT: I found this: Full merge key support.
Full support for references, aliases, and full merge key. Don't repeat yourself by referencing common configuration bits.
in the yaml docs, but no furthur documentation about it..
What you are searching for is not really about Yaml itself, but about the Yaml loader of the Dependency Injection container.
If you search docs about it, here are the ones for the old component (v1): http://components.symfony-project.org/dependency-injection/trunk/book/05-Service-Description
Symfony2 comes with a new component (based on the same principles). You can find the official docs here: http://symfony.com/doc/current/book/service_container.html#service-parameters
Concerning your problem, you cannot access to keys of DI parameters, you have to flatten then manually.
You could use a DI extension to fit your need, take example on some bundles like: https://github.com/symfony/AsseticBundle/blob/master/DependencyInjection/AsseticExtension.php#L54 (maybe not the best example).
Related
i want to load an entity in my Controller, but dont want that the entity contains all fields. I did that before with the Jms-Serializer, where you can use the Groups Annotations, to avoid loading special fields. But i there you have to serialize your object to json/xml etc.
And i dont want it serialized, i just want that groups function. I searched this site and the internet, but didnt found any solution for my problem.
Hope that someone understand what i mean and got an idea :)
There are a couple of possibilities:
Use partial objects (which will deliver objects where only specified attributes will be filled during hydration): http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/partial-objects.html#partial-objects
This is dangerous and you should be extra careful, because it looks like a fully loaded entity from all perspectives. You have to know why a field is null - just because it's null or because it simply hasn't been filled during hydration.
Don't hydrate objects but query for an array as hydration result (by that again you can specify which array keys you would like to get back): http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/dql-doctrine-query-language.html#array-hydration
Use this for performance-sensitive queries where you need a lot of read-only data and complex joins. But be aware that you don't have any entities you can manage with Doctrine (e.g. updating, deleting etc.).
Use DTOs which are objects but non-Doctrine-managed entities, there again you can specify what you would like to get hydrated with the NEW syntax: http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/dql-doctrine-query-language.html#new-operator-syntax
Basically the same advise as in 2) but this time you'll get objects. So you can use all your OOP wisdom.
Create your own custom hydration mode - there you can define on your own how entities should be hydrated: http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/dql-doctrine-query-language.html#custom-hydration-modes
Very advanced level. Only useful if you need a special hydration mode for several entities and really no other option delivers at performance and quality as you require it.
You can use partial objects, but you should be careful. For example:
$q = $em->createQuery("select partial u.{id,name,otherField} from MyApp\Entity\User u");
You can read more here: http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/partial-objects.html
I'm writing an API where I have a Controller that POSTs a new object, GETs it back and can PUT/PATCH updates to it. The problem is that there's a difference in properties between the two different actions. For example, when I POST a new object I want to ensure that the 'id' of it is returned so that it can be used to identify it for the GET/PUT/PATCH endpoints. It doesn't matter if it comes back via the GET (it's just a duplication of data at that point) but I certainly don't want it passed for the PUT or PATCH as the id is immutable.
So what's the best way to mark this up in swagger so that I can have different versions of the same Definition? I've seen that you can use 'allOf' to add Definitions to other properties, but I'm wondering if there's a way of saying 'not these properties in the definition'?
If I could do the latter I could make one Definition of the object as a whole and simply knock out the things that aren't required to be returned or submitted when referencing it at the Controller. Is this possible? Am I making sense?
(Just to make things more interesting, my swagger.json file is being generated by swagger-php based on Annotations in my controller and entity files)
I am facing the same issue while writing our spec file, and didn't know how to fix it but what I used is the property "readOnly":true, this way the documentation says that this is a readonly property, you can only read it through GET/POST methods but you cannot send it via PATCH/ PUT.. hope this helps
I'm brand new to Symfony but am loving getting familiar with it (and many of the concepts behind it). MVC is pretty new to me in terms of the way I'm encountering it in Symfony.
My question is that if I have a simple array of commonly used data that I don't think necessarily belongs in a database table where should I store this. Is it an Entity? Should I store it in the Should I put it in the controller? Somewhere else?
I'm talking specifically about something like a US States array that I might use to power a dropdown. Right now I'm having to build an entity and store these in the database but would like to know if there is a better / preferred way to do this.
In my procedural days I would keep a file called "includes/arrays.php" and pull that when I needed one of these.
Thanks
If you want to use this data with other Entities, for example State would be connected to Adress object, I would stick with Entities, because it makes relations easier to implement and work with (I assume you using some kind of ORM e.g. Doctrine).
If you don't want to use this data with other entities, maybe you would like to hardcode them into all the templates somehow. http://symfony.com/doc/current/cookbook/templating/global_variables.html (I assumed you are using Twig).
A similar question was answered here:
Where to define static array related to an entity in symfony2 ?
It depends. I would opt by having that kind of data in the database. Suppose you in the future would have a back-office that update data.
Or you could use config files. For example, in yml format, arrays is easy to define.
Just like #foxtrot said, any data that is changeable should be stored in the database, just so you do not have to edit any code when a change occurs.
Firstly, I would create the Entity for the common data, and then I would use Fixtures to generate the entries in the database when you deploy your code.
This way, you allow later editing through either forms or phpMyAdmin, but you also get to write the default values into a PHP class so you don't have to manually enter all of them into the database.
See Symfony - DoctrineFixturesBundle
In Zend Framework 2 I wrote a module with custom configuration options.
The options are obtained using the service locator and are then passed to the object that is being initialized inside a factory.
Since my configuration is in PHP array format, I could just pass the array, or I could first create a new instance of Zend\Config\Config and pass this to the new object.
I tried both ways & they both work, but what is the recommended way of doing this inside ZF2 & why? Does it has any advantages to use Zend\Config\Config?
Especially since I just noted it's possible to cast the Config back to an array using toArray() I am curious of possible benefits.
By using the object you would be keeping with the OOP inherent to Zend, plus it has functionality not available to a basic array, and it can be extended to use custom business logic if the need arises.
IE, maybe a condition comes up that will change one of the configuration options, but the rest are the same.
If I'm developing a project for others, I like to give them a certain level of access to the configuration so that they do not have any reason to delve into the code themselves. I'll create a table in the database called something like 'settings' or 'config' that the admin can access through a form, and the data populates a php configuration array. In order to do this, the PHP array format is the way to go.
("a" recommendation, not necessarily "the" recommended way)
Most of the modules just add to the global config, that is accessible via $serviceManager->get('config')
This way your config can be cached later on via config_cache_enabled in application.config.php and users can override config options using their local configurations.
If your's module config isn't related to the global config mechanism it's really up to you on how you store/manage it. Keeping it as an array is simpler, whereas using it as Zend\Config\Config lets you use various tools for config (ini writers, database etc).
I have been coding in SYmfony since last 6 months now. And after completing a couple of projects, I started exploring symfony in greater details. While exploring i came accross, TreeBuilder component. Now, i understood the concept TreeBuilder very well. Its basically used to dump config files in YML. But, the question is, why would one use TreeBUilder when you can directly modify the condig yml files.? Is there any other better use case where one should use TreeBUilder specificaly.? Could you please help me understand any use case. This will give me a better understanding.
According to documentation Tree builder is a component which can/should be used to validate configuration provided by end user.
Configuration values are usually expected to show some kind of
hierarchy. Also, values should be of a certain type, be restricted in
number or be one of a given set of values. For example, the following
configuration (in YAML) shows a clear hierarchy and some validation
rules that should be applied to it (like: "the value for auto_connect
must be a boolean value")
So basically you can make a set of requirements to configuration of your bundle like
required
default value
type constraint
For complete reference check documentation