Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>If you are talking about the <a href="http://api.symfony.com/2.0/Symfony/Component/HttpFoundation/Request.html" rel="nofollow">Request</a> and <a href="http://api.symfony.com/2.0/Symfony/Component/HttpFoundation/Response.html" rel="nofollow">Response</a> objects, there was a discussion about this on the Symfony developers mailing list a few days ago. I invite you to take a look at it <a href="https://groups.google.com/forum/#!topic/symfony-devs/CiJuSno85_8" rel="nofollow">here</a>.</p> <p>Why not getters? Not sure if there is a definitive answer to this but I think it is a decision based on personal tastes mainly.</p> <p>Does it break encapsulation? Not really in my opinion for this particular case. My reasoning is that for now, no special logic is performed on the various objects that are public right now. So in the end, you would end up retrieving the object via a getter and read or modify it directly. There is not much difference with retrieving the object using a public property.</p> <pre><code>// With Getters $parameterBag = $request-&gt;getQuery(); $parameterBag-&gt;get('key'); // With Public Properties $parameterBag = $request-&gt;query; $parameterBag-&gt;get('key'); </code></pre> <p>Encapsulation should be enforced when you need to be sure that a property has a particular value or format. For example, say you have a class with a cost property and this property should never be negative. So if the cost property was public, it could be possible to set it to a negative value by doing something like <code>$receipt-&gt;cost = -1;</code>. However, if you make it private and the user of the class is only able to set it via a setter, then you could ensure that the cost is never below 0 by doing some special validation in the setter code.</p> <p>In our case, we are talking about a collection object, a ParameterBag object to be precise. I don't think there are special requirements on this object but I could be wrong. So for me, it is correct to have access to those properties via public properties.</p> <p>The main argument I could see in favor of the getters is that it would be more consistent with the other parts of the framework where getters are used. However, the getters could co-exist with the public properties.</p> <p>To conclude, I think it is safe for this particular case. Public properties should be used only in special cases where it seems to be beneficial and where it is correct to do so.</p>
    singulars
    1. This table or related slice is empty.
    1. POWhy properties request/query/attributes/... are public in Symfony2?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USMatt
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POWhy properties request/query/attributes/... are public in Symfony2?
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COThank you for link to topic in symfony-devs. I'm usualy read this group but haven't noticed this topic.
      singulars
      1. PO
      1. USKoc
    2. COYeah I noticed that you were active on this symfony-devs forum that's why I suggested you this link :) You're right about the fact that I would be possible to set a property to null, so maybe it would be a good idea to enforce encapsulation by providing only setters and getters for the properties.
      singulars
      1. PO
      1. USMatt
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload