Quo

I love traveling and therefore travel a lot, mostly just with my spouse. It all started in 2000s with our trips to the USA and during planing those we mastered our elaborate planning spreadsheets. Because they work.

One of our elaborate itineraries

Besides transport, lodging, tickets and attractions we have a list of other things we need figure out, to squeeze out as much as we can from our time abroad, because it's much more precious than time spent at home.

Many of those other things is possible to automate or use some online queries to get (like upcoming weather). Also many of them are usable not just for us and since we invested a time into finding that, why keep it just to ourselves? The most significant issue though is with things like hours and prices, which gets obsolete rather quickly, but people want it the most.

Quo Logo: a red marker on a blue marble.

So I started to transform the spreadsheet into a web app. I named it “Qua”, which means “which way” in Latin, so it's perfect. I later forced myself to rename it to “Quo”, because I decided products starting with the same letters should be related and this clashed with Quac.

Also “quo” in Latin means “where to”, which may be even better, and I like it uses only a single row on the keyboard and keys from left to right to type it.

Because I write a travelog to Quiky, I decided to embed a lite version of it into Quo and create (yet another) travel portal. I don't mind the vast competition, because none of them were really suitable for my particular needs and if it's just used by me, it's fine.

Traveling is so broad topic there will always be something to incorporate, so it will keep me busy for a long time. There are so many great places on Earth I don't mean to stop traveling any time soon.

Framework Mk. VI released

Another version of the Framework is out and this is a big one, certainly in terms of expected longevity for model and major API specification.

First enhancement is a class Dict, a wrapper around HashMap (associative array in PHP, object in JS). It offers some helper methods with missing item handling and data type conversions.

Second enhancement is I renamed QApp class to QPage. It better suits its purpose, because App is more imaginary, while Page is real (defined by path, which is commonly represented by URL).

Third enhancement is the biggest – I realized form field and table column are technically the same, so instead of QType and QListCol I introduced QElem, so called Data Element, which you can add to either QList or QForm.

Fourth enhancement is I renamed QListRow class to QItem. An “item” generally means a record in a secondary dataset. QItem extends Dict, but it has some extra methods for easy access to basic properties, like value, text, action or image.

General parts of QItem, demonstrated on iOS's Table Cell

CRUD in QetriX

In the big picture, QetriX is just a CRUD (create-read-update-delete) platform. I tried to describe the whole process to find common aspects and repeating patterns among it's parts, leading to simplification and therefore to minimal code.

From this emerged components. There are four component types in QetriX:

• *QElem* is (r)evolution of Data Particle from QPDB. Besides value it could also specify it's data structure.
• *QForm* is like view, but contains form controls (textboxes, comboboxes, checkboxes, buttons...) to modify data.
• *QList* is a listing of entites and their “base” attributes.
• *QView* is partly like a QForm, partly a “glue” holding other components together.

And that’s it. I didn’t find any use case, where I’d need to use anything like this.