views:

42

answers:

2

I'm using HTMLPurifier in a current project and I'm not sure about the most efficient way to go about handling multiple configs. For the most part the only major thing changing is the allowed tags.

Currently I have a private method, in each class using HTMLPurifier, that gets called when a config is needed and it creates one from the default. I'm not really happy with this as if 2 classes are using the same config, that's duplicating code, and what if a class needs 2 configs? It just feels messy.

The one upside to it, is it's lazy in the sense that it's not creating anything until it's needed. The various classes could be used and never have to purify anything. So I don't want to be creating a bunch of config objects that might not even be used.

I just recently found out that you can create a new instance of HTMLPurifier and directly set config options like so:

$purifier = new HTMLPurifier();
$purifier->config->set('HTML.Allowed', '');

I'm not sure if that's bad form at all or not, and if it isn't I'm not really sure of a good way to put it to use.

My latest idea was to create a config handler class that would just return an HTMLPurifier config for use in subsequent purify calls. At some point it could probably be expanded to allow the setting of configs, but just from the start I figured they'd just be hardcoded and run a method parameter through a switch to grab the requested config. Perhaps I could just send the stored purifier instance as an argument and have the method directly set the config on it like shown above?

This to me seems the best of the few ways I thought of, though I'm not sure if such a task warrants me creating a class to handle it, and if so, if I'm handling it in the best way.

I'm not too familiar with the inner workings of HTMLPurifier so I'm not sure if there are any better mechanisms in place for handling multiple configs.

Thanks for any insight anyone can offer.

+2  A: 

Configuration objects have one important invariant: after they've been used to perform a purification, they cannot be edited. You might be interested in some convenience methods that the class has, in particular, inherit, and you can load an array of values using loadArray.

Edward Z. Yang
Ah thanks, wasn't aware that once a config is used that it can't be edited. That makes the bit I showed not feasible. -- Those methods seem to make it more convenient creating configs though I'm more looking for convenience when managing and using them. -- Any thoughts on the best way to go about that? Thanks.
anomareh
Well, you can cheaply make another config object by just passing the old one to the constructor.
Edward Z. Yang
@Ambush I was looking for more along the lines of what I posted in my answer. I don't really have a problem creating configs, that's fine. I was looking for how other people handled managing several different configs and if there were any built-in mechanisms to make such a task more streamlined. -- Thanks for your answer and comment though. It helped me realize some things about what I was trying to do.
anomareh
+1  A: 

I just wrote up a quick, simple config handler class.

You can view / use it @ http://gist.github.com/358187/

It takes an array of configs at initialization.

$configs = array(
  'HTML.Doctype' => 'HTML 4.01 Strict',

  'posts' => array(
    'HTML.Allowed' => 'p,a[href],img[src]'
  ),
  'comments' => array(
    'HTML.Allowed' => 'p'
  ),

  'default' => array(
    'HTML.Allowed' => ''
  )
);

Directives put directly into the array are global and will be applied to all configs. If the same directive is set inside a named config, the value in the named config will be used.

Then you can grab a config like so:

$purifierConfig = new purifierConfig($configs);
$commentsConfig = $purifierConfig->getConfig('comments');

or, shorthand:

$commentsConfig = $purifierConfig['comments'];

If the requested config does not exist or no config is specified in the call, the default config will be returned.

I'll probably flesh it out at some point, but for now this works.

I was looking for how people handled such things in their projects or if there were any built in mechanisms that made something like this more steamlined, but I suppose my question was a bit too narrow in scope.

anomareh