• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Global variables in view files

#1
Hi guys,

Let me just explain what I'm trying to do here. In my CMS I have a backend option where the user can define the theme color and font etc, dynamically.

The way I've done this is to inject dynamic php into a css file that loads in a header template. And the theme color and font etc is gotten from a helper which queries my db.

So although this works, it just feels dirty because...

1. To hardcode css into a header file just seems wrong
2. To dynamically inject php to define the css style seems wrong
3. To manually call the html helper to get these on EVERY page load, feels like I'm wasting resources.

So my question is, what is the best practice here? Is my method bad?
Practical guide to IgnitedCMS - Book coming soon
Reply

#2
Obviously, there are a lot of potential approaches to this, and a lot of reasons for choosing one approach over another. I would probably do something like this:

Isolate the configurable CSS from the non-configurable CSS, so everyone visiting the site gets the same file for the bulk of the site's CSS. This can be more difficult than it seems at first, depending on the level of customization given to the user and the way the CSS is defined for the site.

I would lean towards using a cleaned version of the configurable value or some related identifier in the name of the CSS file(s) to make it possible to cache/reuse the file (so multiple users with the same configuration would use the same file). Your configuration, testing, and personal preferences would determine whether you end up with small files which might be more likely to be used by multiple users or larger files which may only be used by one person. Then, when you get the user's configuration data, you would first check whether the CSS file(s) for their configuration already exist, and, if not, generate the CSS file(s). Obviously, you'll need a directory which allows your server to create these files (and serve them up as CSS), but you should limit it to just these specific configurable CSS files (even other CSS files should be served from a different location).

If the file names are based on the configuration, it's fairly easy to pass variables or even the file names to the view to include the CSS files. This also allows the server to avoid generating the files on every page load, and the users' browsers can cache the files, because the name will change if their configuration changes.

If a writable directory is out of the question, you could create a controller to serve the generated CSS file(s), much like Bonfire's Images controller. This would give the illusion of serving up the CSS files in terms of the code used in the view and the end user's browser, but would generate additional requests to be handled by CI to serve up those resources, and you would still be generating the CSS for each of those requests.
Reply


Digg   Delicious   Reddit   Facebook   Twitter   StumbleUpon  


  Theme © 2014 iAndrew  
Powered By MyBB, © 2002-2021 MyBB Group.