Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Well my theory is that this should be done in the model itself. But sometimes when dealing with a complex model, I like to create a separate class that handles any special "presentation" of that model. It takes the model as an argument and encapsulates the presentation logic. </p> <p>So using your example, perhaps something like this:</p> <pre><code>class Model_Product { public static function getAllTypes() { return array(/* key-value pairs */); } //returns non human readable value public function getType() { return $this-&gt;_type; } } class Model_Product_Presenter { protected $_model; public function __construct(Model_Product $model) { $this-&gt;_model = $model; } //returns human readable value public function getType() { $types = $this-&gt;_model-&gt;getAllTypes(); if (!array_key_exists($this-&gt;_model-&gt;type, $types)) { return null; } return $types[$this-&gt;_model-&gt;type]; } public function getDateCreated($format = "Y-m-d") { return date($format,$this-&gt;_model-&gt;timestamp); } } </code></pre> <p>You can go further and create a base presenter class to define any common tasks, i.e. converting timestamps to dates, formatting numbers, etc.</p> <p><strong>Update:</strong> For anonymous access to a list of product types, I don't see any harm in making it the responsibility of the product model via a static method. Not all static methods are evil. In my opinion, the use of static methods for this purpose is fine, because it declares a global constant.</p> <p>In a more complex scenario, I would delegate this responsibility to a separate class like Model_ProductType. Here is an example of such a complex model in production:</p> <p><a href="https://github.com/magento/magento2/blob/master/app/code/core/Mage/Catalog/Model/Product/Type.php" rel="nofollow">https://github.com/magento/magento2/blob/master/app/code/core/Mage/Catalog/Model/Product/Type.php</a></p>
    singulars
    1. This table or related slice is empty.
    1. POProper place for human-readable representation of entity-based key
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USChristian Burger
    1. USChristian Burger
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. COWhat about a situation where all of the key => value data must be used for say...a dropdown element? If I'm dealing with entities only, the choice is simple, but outside of that construct, when I'm not using any entities but I need data related to an theoretical entity, I'm still at square one.
      singulars
      1. PO
      1. USwebjawns.com
    2. COIn my opinion, maintaining a list of product types and the associated human readable descriptions should be the responsibility of a model. In your example, depending on the complexity, it could be part of the Product model or perhaps a ProductType model. If there is a requirement for anonymous access to the maintained list, then so be it. I'll update my answer with a product model example from the Magento source code. Their Product/Type requirements seems quite complex and obviously warranted a class of its own.
      singulars
      1. PO
      1. USChristian Burger
    3. COThanks for the responses, Christian. It's been helpful to read your opinion on these matters. As far as Magento is concerned, I think Magento is a great application, but its structure is a bit different from our own. They tend to use the singleton pattern and static methods to drive their application, whereas we do not. That's not to say that we can't find a few good ideas. I'll look further into what you've suggested here and see if it is a fit. Thanks again!
      singulars
      1. PO
      1. USwebjawns.com
 

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