Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Message from discussion Allowing other bundles to add view variables
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Adrian Schneider  
View profile  
 More options Oct 7 2012, 12:18 am
From: Adrian Schneider <siradr...@gmail.com>
Date: Sat, 6 Oct 2012 21:18:58 -0700 (PDT)
Local: Sun, Oct 7 2012 12:18 am
Subject: Re: Allowing other bundles to add view variables

I've gone ahead  with #2 for anyone who is interested.

Each controller returns a ViewEvent($templateName, $variables, $eventName =
null).  kernel.view is fired since it's not a Response.  A listener on
kernel.view converts ViewEvents into Responses, firing the custom
$eventName (if not null), which allows modification of $templateName or
$variables.

Pros

   - Removed dependency on templating layer from controller (another step
   towards framework inoperability!)
   - Explicit event-based access to modify templates

Cons

   - Controller's return code is a little more verbose
   - Added complexity
   - Controller doesn't feel as explicit (not returning a Response anymore,
   though to be fair, it wasn't accepting a Request anyway).

On Saturday, October 6, 2012 1:55:45 PM UTC-7, Adrian Schneider wrote:

> I'm working on a bundle that I'd like other bundles to be able to
> dynamically add template variables to.

> Constraints

>    - I'm using a generic templating service in the controller, so nothing
>    twig-specific
>    - I'd like to keep the controller as explit as possible, which means
>    returning a Response object

> Here's a typical controller action -
> https://gist.github.com/665c12b1aea3ebc5e372

> Options

>    - Event system, and array_merge event's view variables into template
>    variables array (new event per action)
>    - New TemplatingResponse object or something that users can hook into
>    (using kernel.response?)
>    - Twig global variables... not explicit enough and locks me into Twig.

> Can anyone suggest anything better or how they've solved it in the past?  
> I'm leaning towards #1 right now, but as the bundle grows it seems #2 might
> be more manageable.

> Thanks


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.