Sorry, I was just replying to your event question and didn't give much
thought to the original problem.

I suppose for themeing, I'd consider wrapping logic around the template's
decision to extend a parent template - or perhaps just putting the logic in
a fixed parent template yourself.  I saw parent template, but from a
Symfony1 perspective it's more like layout; however, Symfony2 lets you
extend multiple times, so the template your controller view extends could
itself extend another template (just like PHP classes).

By making the current theme id/name available to the templating layer
(perhaps as a templating helper service, which you can configure with the
current theme name via the DIC extension loader), you could reference the
theme and then conditionally include the CSS/JS assets and special markup
you need to in that "layout" template.  Alternatively, if you only need to
inject assets and aren't about to radically change the HTML with each theme,
you could keep things strictly behind the scenes and create a service that
gets the Javascript and Stylesheet templating helpers injected and calls
add() appropriately on them to inject assets into your view.  Going this
route, I'd consider making the JS/CSS files configuration parameters (kind
of like Symfony1's view.yml) so your service knows exactly what to inject
for each theme.

Thoughts?

On Wed, Oct 13, 2010 at 1:02 PM, Matthias Nothhaft <
[email protected]> wrote:

> On Oct 13, 6:50 pm, Jeremy Mikola <[email protected]> wrote:
> > The core.controller is dispatched right before the controller is
> executed,
> > and the value given that event is the controller callable (freshly
> resolved
> > from the Request object via a ControllerResolverInterface).
> >
> > My line number might be off, but check out line 122
> > in Symfony\Component\HttpKernel\HttpKernel.php, or just search for
> > core.controller there.
>
> Does that really make sense to rely on that callable/event? Ok, I
> suppose there will be no better way as controllers can also be
> services - which makes it even more fragile..  :-(
>
> Any other ideas out there?
>
> regards,
> Matthias
>
>
> > On Wed, Oct 13, 2010 at 12:29 PM, Matthias Nothhaft <
> >
> >
> >
> > [email protected]> wrote:
> > > Hi,
> >
> > > sorry for posting on the dev list, but my question might be a bit
> > > tricky for users..
> >
> > > Short story: I'm looking for the Symfony2 equivalent for sf 1.4
> > > controller.change_action event.
> >
> > > I would like to create a bundle that provides a way to use
> > > "themes" (set of layout template(s), CSS, JS, image files). I want it
> > > to switch to a certain theme based on various conditions such as the
> > > requested controller.
> >
> > > So I wonder where to plug that theme switching in? What event should I
> > > rely on?
> >
> > > core.request seems to be too early, I guess this is only useful for
> > > caching?
> >
> > > core.response seems to be too late as this is after template
> > > processing, isn't it?
> >
> > > I'm not sure, it seems that there is an event missing for that use
> > > case between core.controller and core.view or in other words: What
> > > event tells me what controller is actually used (before actually
> > > executing the controller) ?
> >
> > > regards,
> > > Matthias
> >
> > > --
> > > If you want to report a vulnerability issue on symfony, please send it
> to
> > > security at symfony-project.com
> >
> > > You received this message because you are subscribed to the Google
> > > Groups "symfony developers" group.
> > > To post to this group, send email to [email protected]
> > > To unsubscribe from this group, send email to
> > > [email protected]<symfony-devs%[email protected]>
> <symfony-devs%[email protected]<symfony-devs%[email protected]>
> >
> > > For more options, visit this group at
> > >http://groups.google.com/group/symfony-devs?hl=en
> >
> > --
> > jeremy mikola
>
> --
> If you want to report a vulnerability issue on symfony, please send it to
> security at symfony-project.com
>
> You received this message because you are subscribed to the Google
> Groups "symfony developers" group.
> To post to this group, send email to [email protected]
> To unsubscribe from this group, send email to
> [email protected]<symfony-devs%[email protected]>
> For more options, visit this group at
> http://groups.google.com/group/symfony-devs?hl=en
>



-- 
jeremy mikola

-- 
If you want to report a vulnerability issue on symfony, please send it to 
security at symfony-project.com

You received this message because you are subscribed to the Google
Groups "symfony developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en

Reply via email to