There's also this plugin:
http://github.com/weaverryan/sfThemePlugin/blob/master/README.markdown
Haven't tried it yet, but seems to take care of theming, except the
image directory as far as I can see, but that seems to make sense to
me, as some images could be shared between themes.
Daniel
On May 17, 6:21 am, Johannes <johannes.schmitt...@googlemail.com>
wrote:
> I've struggled with this problem myself, and as far as my research
> went there are two possible solutions:
>
> 1. Overwrite getTemplateDirectory, getDecoratorDirectory of
> sfApplicationConfiguration in your appConfiguration class (i.e.
> frontendConfiguration).
> Pros:
> - looks like the cleaner approach, not all too much hacking necessary
> Cons:
> - context is not necessarily available, and must not be relied upon
> - limited information available to determine the path to a template
>
> 2. Create an own view class, and overwrite getDirectory, and
> getDecoratorDirectory
> Pros:
> - context always available
> - not necessary to alter any classes, and thus can be provided by a
> plugin
> Cons:
> - more hacking involved
>
> Johannes
>
> On 17 Mai, 09:29, Georg Gell <geor...@have2.com> wrote:
>
>
>
> > It might be worth looking into using your own view class:
> > something along
>
> > class myView extends sfPHPView {
> > public function setDirectory($directory){
> > $this->directory = $directory . '/theme'; //whatever, must be full path
> > }
>
> > }
>
> > and in filters.yml
> > rendering:
> > class: myView
>
> > But then caching will probably not differentiate between the themes, but
> > that would be the next step ;-)
>
> > Am 16.05.2010 19:53, schrieb Davide Borsatto:
>
> > > Hi everybody,
>
> > > for the project I've been working on I need to be able to define
> > > multiple themes.
> > > With "theme" I mean the full thing, including php code for the
> > > templates, images, stylesheets and javascripts too.
>
> > > But symfony templates structure is not quite friendly for this kind of
> > > operation, since we have files on
>
> > > - apps/frontend/templates/
> > > - apps/frontend/modules/*/templates/
> > > - web/images
> > > - web/css
> > > - web/js
>
> > > Which is not a good solution to mantain.
> > > My idea was to package themes in the "data" directory, creating
> > > something like
>
> > > - data
> > > -- themes
> > > --- default
> > > ---- css
> > > ---- js
> > > ---- images
> > > ---- templates
> > > ---- modules
> > > ----- module1
> > > ----- module2
>
> > > Basically I need to be able to put every file needed in a single
> > > directory (like most CMS do).
>
> > > Since the data dir is not world wide accessible, I thought about
> > > creating a task that creates symlinks in the web directory, so this
> > > problem is easily solved.
>
> > > Now about the PHP files: what's the best solution to handle this?
> > > I think I have two choices:
> > > 1 make symfony look into the right directories, creating custom view
> > > and partial classes
> > > 2 making the apps/frontend/templates and apps/frontend/modules/*/
> > > templates symlink to the directory theme
>
> > > I like more the first solution, but after a while looking in the
> > > symfony core I still can't figure out how to "redirect" all paths to
> > > the theme dir. Setting the global layout is as easy as doing
>
> > > sfConfig::set('sf_app_template_dir', $themeDir . '/templates')
>
> > > But module templates are a bit harder to configure. Actually, I still
> > > don't know how to do that :)
>
> > > So this is my question: which one is the best approach? I'd rather not
> > > have symlinks all over my project, but that seems to be the easiest
> > > solution (one console task to handle everything, no symfony classes to
> > > override, no risks to forget about this or that...).
>
> > --
> > 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 users" group.
> > To post to this group, send email to symfony-users@googlegroups.com
> > To unsubscribe from this group, send email to
> > symfony-users+unsubscr...@googlegroups.com
> > For more options, visit this group
> > athttp://groups.google.com/group/symfony-users?hl=en
>
> --
> 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 users" group.
> To post to this group, send email to symfony-users@googlegroups.com
> To unsubscribe from this group, send email to
> symfony-users+unsubscr...@googlegroups.com
> For more options, visit this group
> athttp://groups.google.com/group/symfony-users?hl=en
--
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 users" group.
To post to this group, send email to symfony-users@googlegroups.com
To unsubscribe from this group, send email to
symfony-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/symfony-users?hl=en
