Using your views with basic conditional logic that will show different content based on global values like a user’s IP address or their incoming referrer address is easy through “the app.request.server” object.  You don’t need to involve your controller to produce basic web page behaviors, especially those that are global in nature you’d normally use in your views where there’s one-way display of information and NO BUSINESS LOGIC.  In other words, the behavior based on global conditions can often wait until it reaches your site’s view to produce the intended results.

Let’s say your business has its own static IP.  It’s safe to say that anyone in the building is accessing the site through the same IP address.  So here’s a simple example of how you can switch or block certain content by reading the user’s IP address:

{%  if app.request.server.get("REMOTE_ADDR")=='your.ip.address.here'  %}
  Conditional content here if in building.
{% else %}
  Content to show if not in building.
{% endif %}

If you are an business in the Jacksonville, FL, Northeast Florida, or Southeast, GA area looking for open source PHP developers or other open source web developers with experience in Symfony, Magento, Drupal, WordPress, Magento, marketing automation, or API integration experts, please contact me.  I have a list of competent open source web developers who I can recommend here in Jacksonville, Southwest Florida, and throughout the US, Canada, UK, Australia, and Germany as temporary web development solution providers or remote web developers!


Strange how obscure it is to find a clear example of how to just access or show the value of a cookie in Twig, so here it is!

{{      app.request.cookies.get('yourCookieHere')  }}

Twig is the templating engine that powers Symfony views.  Symfony is the PHP framework from Sensio Labs.

If you are a company that uses open-source software and developers and you are not using a PHP framework, you should consider migrating your legacy “cowboy” code to a collaborative, scalable framework like Symfony before it becomes a necessity for your company.  I have overseen many migrations of systems and data over the years and am available for consultation at my business consulting site at Belchamber.us.

– Aaron Belchamber


Here is a quick way to access all request variables and output them in a Symfony Twig view:

{% for request in app.request.query.all  %}
   {{ request|raw }}<br/>
{% endfor %}

 


In the newest versions of Symfony greater than 2.2 you can embed output from controller by calling it with this handy TWIG snippet:

{{ render(controller('PostBundle:Posts:recentPosts', { 'category': 'cool symfony tips' })) }}

Check out Sensio Lab’s documentation to learn more.

This is especially useful if you want to create a snippet that will deliver content independent of the controller you are calling the main content of the page — stuff around the periphery.  As long as you aren’t using any logic, this is an acceptable use of MVC and it decouples say content in a related widget on the page from the controller of the page’s main content.  This separation of concerns ensures the controller of the main content stays as lean and clean as possible!


At last, a framework has finally given the tilde (~) a little respect. Hash tag (#) usually gets all the glory, but not this time!  Not is in this case.  Granted, the tilde might be happy to be used at all and chances are, this obscure solution to another view issue doesn’t mean tilde’s ready for primetime, but let’s show some respect when respect is due.  After all, without the tilde, you wouldn’t be able to dynamically create field names with string concatenation.

Symfony’s TWIG uses the tilde to help dynamically address or declare form fields.  This is handy if you have a bunch of form fields with hideous serialized numbers appended to them like “field_name_1” and “field_name_2″….  Without addressing all 50 of these, you can loop through them dynamically like so.  In this example, I only loop from 0 to 4.  An added bonus?  I check if the form field name exists.  That’s helpful in case you’re receiving form fields that are dynamically added and you don’t know how many possible form fields your antiquated form made, probably through some Javascript or using JQuery.

{% for i in 0..4 %}
   {% if attribute(form,'field_name_'~i) is defined %}
       {% for formItem in attribute(form,'field_name_'~i) %}
            
            {{ form_row(formItem) }}

       {% endfor %}
  {% endif %}

{% endfor %}

The only question is…. why didn’t you just use an array for those form fields?!  field_name[0], field_name[1] is much easier, but who am I to judge?