Tuesday, April 21, 2015

Converters

I suspect converters to be my second greatest idea for QetriX after Particles. In the past, QetriX used Renderers for output in desired format (HTML, JSON...). You simply handed over an object, like QList, to a Renderer of chosen kind and you got the output. It was simple as that.

But I faced the opposite situation - I have a string in some format and I need to convert it to an object. Imagine FileSystem DataStore, the data could be XML, JSON, flat file etc. I don't want to have FileSystemXml DataStore, not to mention Xml is for Soap DataStore as well. And I don't want to duplicate the code either.

I tried to create "coders", with encode and decode method. Therefore I was able to call a DataStore, the output process thru a coder.decode, then create an object and render it. Maybe it sounds complicated but in fact it was quite simple. Just few steps to make.

Well... no. It didn't work as well as I expected and I didn't like the name - coders. So back to a drawing board. I was working on a HTML coder, when the obvious came. I was dealing with conversion of a HTML code to an object and back, which in many aspects duplicates what Renderers are for. But Renderers are one-way only and I need two ways.

Even Renderers were in QetriX from the beginning, the new idea was beyond that. I renamed coders to converters (convs for short) and created few basic ones, like QForm to HTML (qform-html), Wiki to HTML (wiki-html). I was particularly happy about the second one, because before that it was as an add-on library. This way it makes much more sense.

I'm even able to make converters like PNG to JPEG, XML to QList, Image to Thumbnail or Integer to String.

To be honest, I can see the concept (or architecture, if you will) of Converters may be fundamentally wrong, because most functions are in fact converters, like "Math.add" converts two numbers into one number (sum total), and input/output types are not consistent, which is difficult to manage and impossible to unite into e.g. Interface. I may think of some boundaries in the future though.

No comments:

Post a Comment