Create a configuration object

[senny]

Create a configuration object

[stadelmanma]

I think one good way to build a strong API around this for adding support for new tags via a config module would be a 'Tag' class or struct along with an accompanying register_tag and a remove_tag method. Those methods would act as getters and setters for the supported tags hash allowing me to limit direct access (or at least not advertise it i.e. use at your own risk). One caveat with this is that I want the end user to be able to add their own AST classes if needed as well so the tag struct would need to include an AST class reference that likely defaults to either Paragraph or Run.

Something similar could be implemented for supporting additional style attributes as well.

Seeing issue #64 also indicates it might be useful to specify the XML parser to be used via a config setting. Then the end user can easily create their own parser and tell Sablon to use it.

In all cases for passing in a class I think I would want to allow the user to pass in a specific Class reference or a symbol/string.

[senny]

@stadelmanma I'm not totally convinced yet that this configuration is something that would be used by the majority of sablon users. I can see use in being able to specify the style class mapping. However, I doubt that adding AST nodes is something that needs to have a prominent API. Somebody who is going down that route will need to be familiar with Sablon internals. At that point we could have a low level entry point and don't need a abstracted "configuration" for it.

[stadelmanma]

@senny I agree that the vast majority of users wouldn't need to use a configuration object at all because they only need the basic functionality. Essentially adding a new AST node wouldn't be part of the main API it would get shuffled over into the options hash, for that exact reason. Since in most cases a person is only going to add new inline tags for some miscellaneous style.

The benefit of storing AST node information on the tag class is that it allows us to refactor and streamline all of the code in the html converter itself. The only reason it would be an available option is that there shouldn't be any additional overhead in providing the end user that added degree of flexibility to extend the gem if they really want to dig into things.