It’s already a quarter of the year since my last post? Wow, the time flies, when you’re busy! :-) I made a serious progress with QetriX PHP, but I spent a lot of time by “re-iterations”.
In the past, when I had a little feeling something isn’t right, I left it behind for when I have a time to think about it in the future and it somehow haunted me and ultimately I had to redo it, no matter how much time passed and how deeply the feature was integrated. Many times it was really painful and for this reason the core code have been rebuild from scratch a lot and I don’t want to do it again any more.
So this time, whenever I have this feeling something isn’t right, I start to take care of it immediately. And if it’s a tough one, I start to build around it – hoping the idea will come when I see it in context.
As you might think, this really does take a lot of time. But IMO it’s time well spent (and that’s what I’ve been doing a lot since July).
Some of bigger decisions are still in front of me, like how to nicely handle QForm data or how to make (and name) opposite side of Renderer – a parser that accepts somehow encoded string (JSON, XML, picture, Word document...) and fill a component with the result.
It’s a tough to find the fine line between automation and customizability. I made some quite ingenious solutions in the past, when the something adapted almost automatically with just a few lines of code, but it was a real pain, when customer needed (not wanted) it to behave or look differently.
There’s no universal solution, so one of my current motos for QetriX is “just enough”. If the way QetriX uses isn’t suitable for you, write your own Renderer, or please use something else. It may sound harsh, but it’s a way out of the feature loop, which leads to overblown code.