For those of you looking for the files directly, they can grab them here. Individual source code can be viewed here: index.htm, javascript.js, ajax.php. Note that jquery.js file is also required (1.4.2), should you copy-paste from the source code instead of downloading the archive.

The code is licensed under LGPL, so you can use it for personal as well as commercial purposes. All files are commented and a working example is provided within. You do not need a firm grasp of jQuery in order to understand this example and you do not need experience with JSON data format. PHP and jQuery handle the conversions for you. I will not explain everything step by step – for that refer to the files and the example provided – but I will give a general overview of what is happening here.

Front-end user-interface has the various actions built through a uiAction() javascript function. This is a general-use function that takes two variables, an ‘action’ that acts as an action identifier, and ‘data’ variable. Data variable can be whatever you want, it can be a string, integer, array or an object, depending on your needs. Since you will control how the ‘data’ variable will be used, it is entirely up to you. In the example files I am calling the uiAction() on a <button> element like this:

uiAction(‘alertLowercaseString’,$(‘#example’).val());

For those of you who know jQuery, know that I am sending the value of an input field with an id of ‘example’ to the function. Action’s name itself is ‘alertLowercaseString’ in that case. Then, within uiAction() function in the ‘action’-switch I am executing the function that sends data to AJAX, like this:

input['string']=data;
executeAjaxAction(action,input);

Action is, by default, the same as action identifier used to call uiAction(). executeAjaxAction() is a function that submits data to PHP backend (but you can customize it, such as have different uiAction() calls execute same function in back-end). ‘input’ is an uiAction() specific javascript object. This is defined at the start of the uiAction() function and is used for convenience in order to send specific data to AJAX. ‘executeAjaxAction()’ expects ‘input’ to be an object or an array, since this is what will be sent to PHP backend. After submitting data to executeAjaxAction() the front-end will connect PHP back-end with AJAX. In this case I am sending an ‘action’ of alertLowercaseString. PHP backend will solve the ‘input’ into a variable named $inputVariables and again – as it was in front-end, within a switch you can define what you want to take place in the back-end and what will be returned. In this example it is:

$return['action']=’alert’;
$return['message']=’Your string lowercased: ‘.strtolower($inputVariables['string']);

‘$return’ is an array that is used to create a JSON object from. ‘action’ for ‘$return’ needs to be always defined, but every other variable can be whatever you want, since – as before – you get to decide what data you need to use later on in front end. Basically everything you want to return to front-end should be placed in ‘$return’ array. PHP then creates a JSON string of the ‘$return’ array and returns it to the browser. executeAjaxAction() function will then call a javascript function parseAjaxReturn(), which will check what action PHP defined for callback (if any) and then – in this example of ‘alert’ as the action – does the following:

alert(json['message']);

And this alerts to the user the lowercased string.

This quick explanation may be difficult to understand at first, but I strongly suggest that you take a look at the fully working examples provided within. Files are fully commented and examples provided within are minimal, so you can take this into production use right away should you want.

Download fully working example files here

If you have any questions, go ahead and contact me directly or comment this article. I will get back to you as soon as possible.

All the best!

This example has a few limits, that is you can easily confuse it by clicking on two tile locations in a row. But in general it works and what I will be using this for will be something a bit different, so this limitation was of no concern to me. However the entire pathfinding calculation takes place on PHP backend. Each map is essentially a square (currently a limitation of pathfinder, but can easily be tweaked) and stored as an associative array, every tile in that array like this:

$map['1x1']['weight']=1.0;

The first key is the coordinate of the single map tile and the weight key is used to store weight of this map tile for calculations. Nothing else is needed (and an example is provided in the files below). For actual game purposes or whatnot you can store additional information on that very map as long as the coordinate and weight are assigned as shown in the example. For example, in my own tech-demo I also store the graphic tile used in the map array.

Finding the actual path is just as simple:

$map=getMap();
require(‘class.pathfinder.php’);
$path=new PathFinder(); //Create new pathfinder object
$path->setOrigin(1,1); //Set the start location
$path->setDestination(20,20); //Set the destination
$path->setMap($map); //Assign the map to use for calculations
$result=$path->returnPath(); //Returns an array of all the walked steps

Working example, as well as commented pathfinder class is available below:

Download the class and example file here

Please note that this is not a definitive pathfinder. It only takes into account one square ahead and on very large maps I am sure there are more ideal solutions. But for your basic browser based game this is a good starting point and I learned a lot by creating it. This is also easy to expand based on your needs.

If you have any other questions, let me know.

The code is shared entirely free for personal or commercial use.

Cheers!

In OridinNode the entire system assumes that every tree has a single parent node. But in OridinNode there are also situations where one tree can be a child of another trees node, which causes conflict for the traversal algorithms. To make traversal work every tree needs to have at least one element that is considered ‘parent’. But if a parent happens to be a node from another tree, then it became important to implement a ‘ghost node’ to every module that has a parent in another tree. The user never sees such a ghost node, but that ghost node is used to traversing within the tree when fetching data to the actual parent element. To give an example, a website has a tree of pages. One of those pages however displays categories for products. There is no ‘main category’ as all of the categories are children of the page node from pages tree, but the categories table does need a ghost parent for quick traversal purposes.

The tree structure model used in OriginNode is a Nested Set Model. Basically every node within the tree is given two values, left and right, which carries their position information within the tree as well as basic information on their children and parents. This allows to completely throw out the recursive set of algorithms that are commonly used and makes it possible to build a whole array of the entire structure with just a few queries. For more detailed description please read through the link I posted above, I will be covering how this will be implemented within the structure of OriginNode below.

In OriginNode, the values often associated with recursive methods will still remain, this means that the nodes in OriginNode will also have information stored on direct ID values of their parents as well as their module identifiers. While those values will not be used to fetch trees, they are still used for other purposes, especially when connecting a number of nodes with one another. Instead of storing this information within the same tables, all this information is stored in a separate table for fetching data.

I have posted the basic table setup of OriginNode before, however the new and (yet again rewritten!) method has changed the structure quite a bit and it requires a revision here. This can be helpful for some of you readers out there who might face a similar challenge in setting up your infosystem architecture for your next project, so I will be giving a revised yet brief overview of the updated structure below.

Node Table
This table stores all nodes that share similar parameters. Every Node Table has a single parent node, but whether this parent is displayed for the user within the UI is up to the developer. This parent node within the table is automatically made invisible if the tree is assigned a parent from another tree. Fields within this node table are as follows:

• id = Primary key of the field.
• identifier = URL friendly string that is optional for the tree. When traversing the OriginNode architecture then both id’s and identifiers can be used to solving the path. For example, when one fetches data by using a string of ‘products/cars/112′, then OriginNode can find identifiers for products and cars, but not one for 112, in which case it will look for id of 112 instead from among the children of ‘cars’ node.
• traversal_left = This is the left integer value for the tree traversal.
• traversal_right = This is the right integer value for the tree traversal.
• active = True or false flag whether the element is returned when data is being fetched from OriginNode.
• period_start = Timestamp from what time the data is considered ‘active’ and thus returned when data is being fetched. This can be used for various purposes, such as pages that are ‘released’ at specific dates and periods. If this value is not set on the node, then the start time is ignored and data is always returned (unless restricted by the period_end field).
• period_end = Timestamp until what time the data is considered ‘active’ and thus returned when data is being fetched. This can be used for various purposes, such as pages that are ‘closed’ after specific dates and periods. If this value is not set on the node, then the end time is ignored and data is always returned (unless restricted by the period_start field).
• rights_read = This is a list of user group identifiers which have the right to see and read that node. Every group is a URL-friendly string and stored within square brackets, like [developer][admin], etc.
• rights_edit = This is a list of user group identifiers which have the right to edit the data within that node. Every group is a URL-friendly string and stored within square brackets, like [developer][admin], etc.
• rights_delete = This is a list of user group identifiers which have the right to remove that node. Every group is a URL-friendly string and stored within square brackets, like [developer][admin], etc.
• f_* = Every custom field from Node Parameters Table (below) has its value stored in f_ prefix fields.

Node Parameters Table
This table stores all the custom fields that are stored within the Node Table. Every custom field is stored in Node Table with an f_ index.

• identifier = String identifier that is also the field name, with a f_ prefix, stored in Node Table. This value is enforced to be unique.
• type = this is a type keyword that determines what type of custom field it is. This ranges from simple fields such as checkboxes, radio buttons and dropdowns to WYSIWYG editors, color pickers, and connections with other nodes.
• configuration = This is a serialized array, stored as a string. This carries whatever custom information the field type or its extension require, such as field length, allowed letters and other restrictions.
• tab_identifier = This is the identifier string of the tab this field is displayed under when viewing the node of the Node Table. Fields with same tab identifiers are stored under the same tab. This value is always required or it will never be shown to the user.
• fieldset_identifier = This is the identifier string of the fieldset this field is displayed under when viewing the node and the tab of the Node Table. Fields with same fieldset identifiers are stored under the same fieldset. This value can be null, which means that the field is not displayed within a fieldset.
• weight = This is the weight of the field. Every node view will be built by taking into account the weights of the fields. First tab in node view will always be the one that has a field with the lowest weight. First fieldset under a tab will be the fieldset that has a field with the lowest weight. And fields with the same tab and fieldset identifiers will also be ordered based on the lowest weight first, and highest last. Basically the heavier a custom field is, the further back it is displayed.
• table_display = Whether this custom field is also displayed in the Module view, in a tree or a list.
• table_filter = Whether this custom field can be filtered in the Module view, in a tree or a list.
• table_sortable = Whether this custom field can be sorted in a Module view, in a tree or a list.
• rights_read = Whether these user groups have the rights to see and read the values of this field. Every group is a URL-friendly string and stored within square brackets, like [developer][admin], etc.
• rights_edit = Whether these user groups have the rights to edit the values of this field. Every group is a URL-friendly string and stored within square brackets, like [developer][admin], etc.
• value_required = Whether value within this field is required and cannot be null. This is not applicable to connections custom field types.
• value_unique = Whether value within this field is required to be unique. This is not applicable to connections custom field types.
• value_default = Default value stored within this field. This is not applicable to connections custom field types.
• languages_dependant = Whether this field is languages dependant and has a new field for each of the languages. This means that in the case of – for example a page title – there will be three fields instead of one when viewing the node, one for each language. If this is set and the custom field is connections, then the connections will be only made with objects that are not language dependant or are of only the same language as the custom field.

Node Connections Table
This table has all the connections stored. In most cases this table is not used when fetching structure from the Node tables. All the connections however are still stored within this table and the traversal left and right values can be restored with the help of this table should something happen with the original tables. All subconnections (of the connections custom field type) are also stored in this table.

• from_module = module identifier that the connection is from.
• from_id = id of the node from the from_module that the connection is from.
• to_module = module that this connection is created to.
• to_id = id of the node that this connection is created to.
• type = the type of this connection. This can be either [primary] (when the connection is part of the whole tree and deals with linked module nodes for traversal) or [secondary=field_name] (when the connection is not part of main structure and is only used to link another object, the field_name value identifies the custom field that this connection is used for).

In general this whole system is a little bit more complicated than the earlier versions of OriginNode concept, but the speed benefits here are rather impressive. Cutting down recursive searches will mean that even larger structures can be built with OriginNode with less problems when fetching large amounts of data. When this is paired with MySQL caching – which will be supported by OriginNode in ‘demand’ mode – then OriginNode architecture will be able to support even large scale infosystems of hundreds of thousands node objects.

What this needs is that all but one of your domain names should be an alias domain name for your main domain name. Most hosting services allow this without additional cost and in fact allow you to set it up yourself (should this be a problem, contact your hosting services customer support). You would then own a number of domain names for which you do still have to pay a fee (usually yearly), but you would only need to pay for only one hosting environment. Drawback of this is that the space and resources used by that environment would then be shared, but as long as you run small scale websites there (blogs and other sites for personal use), it will not become a problem.

To make this happen you need to set up a new index file on your web server which would be run first by PHP. In this index file you would detect the address that the user was trying to access and then direct them to the proper files or project. In case of wordpress you should rename its index.php to something like wpindex.php (alternative is to direct Apache to use another file for index, however many hosting services disable use of .htaccess commands). If I wanted my blog waher.net to always show my blog, but would like my other domain wearenixy.net work as an alias domain name for the domain without having to pay extra for hosting services I would set up something like this:

<?php
    if($_SERVER['SERVER_NAME']=='waher.net' || $_SERVER['SERVER_NAME']=='www.waher.net'){
        include('wpindex.php');
    } else if($_SERVER['SERVER_NAME']=='wearenixy.net' || $_SERVER['SERVER_NAME']=='www.wearenixy.net'){
        include('wearenixy.php');
    }
?>

If the user types in waher.net they would be redirected to wpindex.php and if the user is redirected through my waher.net alias name wearenixy.net, another script would be executed for that purpose.

This is essentially setting up your hosting service to work as a mini ‘domain routing’ service within your own virtualhost.

All the best!

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.

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

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.

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!