Kristo Vaher

After much thought I have introduced another change into OriginNode architecture and how it is built from ground up. An average infosystem nowadays features specific requirements to filter content based on things like what language the user is browsing the website on or what product they are viewing. In order to deal with a potential catastrophic problem of having to build an immense tree and then duplicate elements between branches of that tree (such as having two products instead of one product for an e-shop just because the website has two languages), another solution was needed to improve usability without cutting down the legs of your new and fancy website before it is even up and running.

Basing it on my own experience and the various infosystems that are out there, regardless of content total size, the objects are always ‘filtered’ through two key values. One is a language and the other is a type, of sorts. Language plays a different role from a type (which you might use for a products categorization) because language can change values of a field based on what language is currently displayed. Example is to have a product with the exact same price and weight, but two different names because of language difference. This means that the node needs a field that has a different value for each language in the system, while many other fields remain the same. In OriginNode I am calling that behavior ‘language depencancy’ and plan to build it so that you can assign every field to be language dependant, in which case OriginNode generates all the fields required to fulfil that need.

But types are an entirely different monster. Types can be various statuses that you need to assign to products for filtering purposes, for example to separate your products into ‘special offer’, ‘best-selling’ and ‘regular’ groups. Creating a new module for that purpose is unnecessary, because nodes share similar properties. OriginNode has a couple of hardcoded filters that are already used, such as active flag and period when the object is returned, but there is always a need for dynamic types that are also displayed within OriginNode itself. For a public site one could indeed create a new dropdown and deal with filtering simply by using that on public frontend, but for those dynamic types to be also displayed as tabs within OriginNode another solution was needed. So far the best option seems to be to treat those dynamic types as module-based language dependancy. While languages apply for the entire infosystem, types do not. Types are assigned to each module in the system and can be used to filter nodes within OriginNode itself by using tabs when viewing the module. To deal with conflict of interest tabs-wise with languages and types, then languages always take priority and would be shown as tabs. Types however would be displayed as a separate dropdown filtering option.

In unrelated news, one of my country’s more known content management systems has gone open-source after many years of development. The code itself is tired and old-school and looks like it requires a major rewrite, but for what its worth this only shows the value of open source technologies in todays market. While being open source never guarantees quality, it definitely helps.

Anyone who has paid attention to waves of media has noticed – especially when it comes to sports – that media loves seeing giants fall. This has been so throughout the years, but is especially evident with two sportsmen who can be considered the very example of legends in the sport they took part in. Michael Jordan played two seasons for Washington Wizards and barely performed on B level. Media quickly jumped at the throat of who is arguably one of the greatest ever to play basketball simply because he seemingly never faltered during his career, even having ended his years with Chicago Bulls with three titles in a row. Michael Jordan is and was a controversial figure, a strong and often fearless (and fierce) challenger and competitor who was out there to win no matter what. His success overshadowed his shortcomings, you cannot argue with his numbers and what he did to the sport. But with his return to sports he was far from his ‘great days’ and led a mediocre team in the middle of the pack, even falling out playoff run in the later season.

He was hit with sharp criticism and his decision to return was questioned, especially by every single one who always had something against Jordan and never had the chance to do so before. You cannot argue with a king who rules, but once they give up the throne and fall short of a great comeback years later they become mortal. An everyman, just another player among players, often surpassed by the modern greats with rare flashes of greatness from the old days.

If that scenario sounds similar, it is because the most successful Formula 1 race driver of all time walks the very same path. Michael Schumacher returned handful years after he retired from the sports when he finished a successful run with Ferrari, winning five titles for Ferrari in eleven years and finishing higher than third in all other cases except one. A champion with 91 wins. Few years later, now 41 years old, he returned to the sport with much fanfare. Similarly to Jordan, he joined a team he was not part of during his championship days and similarly to Jordan, the team is not a serious championship contender, at least not yet. But that aside, driving a silver Mercedes and paired with a young german Nico Rosberg seemed like the second best thing. Fans of Schumacher were excited and media pushed fanfares to the forefront with such an effort that one would think Schumacher would win the series with a golf cart.

Today, four races later, media has turned the tables they themselves set, right against Michael Schumacher. Despite many great figures in the sport supporting Schumacher, it has made a very little impact, because media – as it so often does – smells blood and acts on it. As some might know, Schumacher was never beloved by media, but similarly to Jordan you could not argue against a champion who does get the job done. Schumachers titles in 2001 and 2002, against David Coulthard and teammate Rubens Barrichello, had him score twice as many points as the driver finishing second. His work together with Ross Brawn (lead engineer) and Jean Todt (team manager) throughout the years built Ferrari into the most successful Formula 1 team in sports history.

But media is quick to change its mind, Ferrari days were forgotten almost the very first moment he drove out of pits with his silver Mercedes. It has not made much of a difference that Schumachers return has only lasted for four races, two of which were failures that no one could do anything about. In the second race of the season another driver collided with his car at the very beginning, which forced him to make a stop in pits for mechanical repairs. In the third race, despite a swift rise in positions at the start, he retired because of mechanical failure. The fourth race was full of chaotic rain and rear wing related problems which led to issues with traction. But once media smells blood, they care very little for the details, his great defensive work against fellow drivers to hold back faster teams was quickly forgotten.

Thus Schumacher is painted red by the media, to be hit by bulls of fellow media.

I cannot help but feel affected by all this, even though it should matter very little. Schumacher was an inspiration for me when he was struggling to get wins for Ferrari. He joined with them for 1996 season when I was in my early teens. It took five years for him to finally achieve a championship and I followed his career every step of the way. Seeing media attempt a payback in a situation, where no one could have realistically expected anything much better, leaves a sour taste in my mouth.

But I also know that Schumacher is not one of us. Media will not kill his spirits, even though it is quite clear that they won’t stop trying. I know he will not return to his old form at such an age, but I know he will prove media wrong. Just give him time, so far everyone who really matters in the sport has said as much for they know better. His return has already been half the victory, Formula 1 has not seen this much positive media attention since Schumachers dueling days with Mika Hakkinen and McLarens.

And that, in its own sense, is a championship for the sport of Formula 1.

-K

This post has been deprecated and information within about the tables does not reflect the updated structure of OriginNode. More accurate post is here.

As I was developing the architecture for OriginNode I realized that for the entire system to work in ways I am hoping it would, the entire system itself should be built upon the very same architecture that OriginNode is used for building. As I had started with a custom user interface and MVC structure I realized that this would not only lead me to having to fix problems on two fronts at the same time, but also would lose out on the possibility to use the entire architecture and user interface itself as an example of what is possible with OriginNode.

As I have previously explained, OriginNode is essentially a tree based architecture building tool that consists of three ‘module’ views (tree, branch and leaves) and ‘node’ views with its custom values. But while it is a tree based architecture, it can work in areas that do not necessarily require a tree (in case public site of OriginNode is not required and the public API is used to pull information for other purposes).

To achieve that goal I needed the system to have essentially two type of tables: module table and module fields table. Module table would include identifiers and hardcoded – system required – values for every node in the table as well as custom fields.

Every module is actually nothing more than a collection of nodes that share similar properties and their relations between one another. Modules are simply used to make it easier for the user to navigate the system, keeping things neatly organized.

A bare-bones module table consists currently of these fields:

• id (as a unique identifier of nodes stored)
• identifier (a ‘keyword’ that is used for translations of this object or as a URL node for public site)
• active (system flag that is used, by default, whether the node is served to the public engine, -1 value turns off active flag and period_start and period_end)
• period_start (timestamp, similar to active flag, to set a start period when the node is served to the public engine)
• period_end (timestamp, similar to active flag, to set an end period when the node is served to the public engine)
• language (OriginNode can function in single and multilanguage mode, this essentially acts as a language filter for all nodes stored in the table)
• type (other than dynamically generated languages, a separate type can also be assigned for the object that is used when generating tabs)
• parent_module (if this node has a parent in this same module or in another module, this is the identifier of that module)
• parent_id (the id of the parent)
• user_rights_read (groups of users in OriginNode system that can view and read the node)
• user_rights_edit (groups of users that can edit the node)
• user_rights_delete (groups of users that can delete the node)
• CUSTOM FIELDS (other fields in this table come from another table)

Every module can have custom fields for all the nodes stored within. These custom fields can be created by the developer before user starts adding data to the system. All of those fields are stored in a separate table, fields in that table are given below:

• id (id of the field, used only for reference)
• identifier (unique MySQL compatible keyword, used as a field in the main module table with a custom prefix. This keyword is also used to translate the field based on the keyword)
• type (field type, for example: checkbox, radio button, dropdown, multiple selection, text field, text area, password, WYSIWYG field (TinyMCE editor), object connection (to create reference ‘links’ with other nodes), picture connection (to add media))
• configuration (Additional data for the field that is stored as an array. This is specific information for the fields customization, used by the field extension. (and detailed for each field types documentation))
• storage (The field type that is generated to the main module table for storage (integer, string etc). Data can also be stored in an external module in case of a data collection, such as group of pictures)
• tab_identifier (every node is displayed in a completely dynamic interface, this field defines what tab this field is displayed under)
• fieldset_identifier (custom fields can also be set into fieldsets under tabs, all fields with the same fieldset_identifier will appear in the same fieldset)
• priority (general priority value, this only applies to fields that have the same tab and fieldset)
• table_display (whether this field is displayed in main module list, where all nodes are shown)
• table_filter (whether this field can be filtered, only applies to some types of fields)
• table_sortable (whether nodes can be sorted based on this field)
• user_rights_read (groups of users that can view this field)
• user_rights_edit (groups of users that can edit this field)
• value_required (whether this field requires a value or not, otherwise the node cannot be created or edited)
• value_unique (whether this value has to be unique when compared to nodes with the same language (if defined))
• languages_dependant (whether this field consists of actually more than one field. If a public site has two languages, say ‘english’ and ‘german’, then a field that is languages dependant will actually show two fields instead of one, when editing the node. One would be for english language and another would be for german. This is used when you want the same products database, but perhaps want different descriptions based on languages)

Now this description may seem a bit unclear and is quite a lot on the technical side, but it is good to keep in mind that OriginNode takes care of managing all that by itself. This flexibility of modules and nodes applies to every type of module user may come up with and the types of fields can be extended with plugins, allowing for endless opportunities. While there are a few restrictions with this type of system – and mind you much less than would be the case with most architecture frameworks of this type out there – it is important to keep in mind that any technicality of such restriction can be handled on the public side of the system. OriginNode will serve best information possible for the user of the API on public side and the developer of the public site can do with it as they wish, adding further options based on clients specific requirements.

Thus the end result can be extended both ways.

The above information is not yet final, however the basic architecture – the way it is right now – is not a concept anymore and the current build of OriginNode works based on the system described above.

This was a bit of a struggle, I went through a near-dozen different design ideas for the user interface tabs before settling on this simple tabs user interface shown below.

First of all, apologies for not posting anything for a while. Work has held me busy and a lot of my free time is currently used to stay away from the computer. I am trying to stay away from burning out, a lot of my work these days tends to be routine and less of a challenge and somewhat different from the fields I am interested in. Other than the design update in this blog, I have also removed a lot of non-essential posts from here and hope to focus exclusively on software development in the future.

The following pictures are a work in progress and everything is subject to change at a moments notice. I originally came up with the design when I was trying to come up with a sleek look for another application I was working on in the very little free time I have. It’s nothing innovative – I am not a designer – but the idea is for it to be simple, yet modern. I recently finished building the fluid HTML/CSS/JS architecture for this design and getting it working in all major browsers. Next step will be to work on getting the design and engine cooperate.

Some notes:

• The icons will be changed, I don’t own the rights for those icon pictures
• Tabs for the open window are not yet visible. Tabs will be placed on a silver bar below the title field.
• Basic content styles need tweaking and editing still.

In other news, the basic architecture is well on its way. I am on vacation, but on a couple of evenings I’ve managed to set some time aside and work on OriginNode. Everything is going well, the base architecture of how everything will communicate and how the user interface updates will be handled is already set and written in code. Even tested somewhat. I will go into further detail in the future, but there is still a lot to be done before anything can be said in definite.

Comments and critique on the current design would also be welcome. I might be away for a few days, celebrating my birthday, but no feedback will be lost on me.

Cheers!