Welcome to Ataox
Ataox is a content management system (CMS) open source programmed mainly in Php/MySql and endowed with many functionalities to help Internet publication. A particular attention was on the creation of powerful tools, especially the file manager, available on standard installation connected to a site or fully independent. Note : the file manager and most tools can also run fully independently of any external database, because if chosen, the MySql database can be partly simulated in Php, decreasing greatly the installation time.

This content management system (CMS) is the last of a 3 CMS series programmed for about 12 years. In 2010 the version started to show some serious limits on the evolution flexibility. Consequently to pursue this interesting software adventure it was indispensable to create a new CMS, brushing off the previous inconveniences and adding tasty concepts we are very excited to test on the real scale! Otherwise we really think that going open source was our best option for durability and quality.


Definitions and important points :

• Ataox : A TAged Open source cms based on Xpetal (defined below).
• Xpetal : eXtensible Polyvalent Encapsulated TAgged Language. This is a language programmed for Ataox (also a markup language) used intensively through the CMS and allowing numerous simplifications.
• CMS : content management system.
• Technical context : programmed in PHP / MySql / Xhtml and Javascript that are main actors inside the Internet publication business.
• License : open source GNU / GPL. See the text file LICENSE.txt
• Documentation : this site is the main Ataox documentation, but because Ataox is on a schedule of permanent improvements, the most recent buttons and functions are not documented! This is not a problem, because most of them are self explanatory and all the vital functions are already documented.

Technical notes on Xpetal :.

The language Xpetal is used intensively with this CMS, in fact so intensively that the whole website you are reading now has been written for its first about 30 bilingual pages (1st version) entirely inside a single text file specified in Xpetal. However extreme this can appear, it has allowed an excellent test of the system, automatic inclusion of back-ups and the creation of whole sites simply defined by an installer Html form.

It appeared that when building a CMS and many other computer entities, having a specific language to define it can help tremendously because it allows to synthesize complex actions into a small words! This is especially true with a CMS because we need to take into account different level of language depending on the user rights!

FAQ about Xpetal :

• Why do we use squared brackets [] ? Because it was necessary to separate it from the usual syntax of standard markup languages such as HTML or XML
• What do we do with the instructions inside the squared brackets ? We execute them using an internal parser.
• Is it necessary to know this Xpetal syntax to do elementary changes on pages ? No because all elementary display function can be done with standard Html that can be copy / paste from any source! On the other hands a lot is also done automatically when for example inserting a new page. It's also important to note that in many cases the Xpetal syntax is simpler than the Html syntax (for example considering images associated with a zoom), or even the only possibility, for example with a dynamic menu having specific graphical adaptation for each page.
• Why Xpetal is coined as polyvalent and not just a markup language ? It does indeed a lot of markup, sometimes even the exact html instruction like for [b]bold[/b] (it was useful for testing the parser, and also useful when users are not allowed to use HTML and sometimes also simply to make it easier inside a large text using just the same sort of syntax - doing just that here!). Also it's polyvalent because it can call any complex function that have been defined, so a simple tag can call a whole menu, a captcha, a file browser (actually many tags for that one to have intuitive modularity), a database browser etc. Generally encapsulated tags accumulate their results along the encapsulation inside the main visible buffer, but it can be some other buffers like in the main form case when building 2 separated buffer (one for the boxes in case a correction is needed and one for the final results) was the easiest approach for users and programmers.
• How do I use the Xpetal language ? Just copy paste the instruction and fill the parts that need to be filled! Note : in most cases the copy/paste process is not a copy/paste but a click on a Javascript button that fits the chosen tag at the right place.
• What the exact syntax of Xpetal ? Here is an example for a fictive tag called anyTag :
  • [anyTag atrX="attibute X" atrY="attribute Y" ] This is the TAG BODY preceded by the tag head and followed by the tag end. [/anyTag]
  • atrX and atrY : two attributes belonging to "anyTag" with their values defined within double quotes. Programmers can define tags with as many attributes as they wish and users can use none to all of them depending again on the tag definition.
  • The TAG BODY : this is the only place of a tag that can encapsulate another or the same sort of tag(s). This is very useful because the result of a tag can be associated with other tags etc. Exactly like in Html or Xml.
  • Why not have simply used the Xml syntax and an available parser ? We needed different sort of brackets, the possibility to have restriction on the tags depending on the context, direct calls on Php methods, an environment using a precise parser, the full control on the parser! That added to the fact that Xml is specialized to store hierarchically defined information but not specifically design to run Php methods, we definitely needed to define our own language and program the parser that goes with it!
  • Where is the parser and how does it work ? The parser is the file code/aKernel/tagsParser.php and is running a recursive algorithm defined in object Php, the resulting string is build directly without building an explicit tree, which is very fast but of course does not give a permanent access to any elements within the Xpetal tree! Such access are rarely needed, but it happens and an easy solution is to use instance variables to store the values we are interested to access randomly from any remote place.
  • Tags & Attribute freedom and restriction : users can use any sort of lower or uper case style on their attributes and tags, because the parser transform them into lower cases! This imply that attributes inside the php programs code need also to be forced into lowercases, because php is case specific for array keys! For programmers it means that a nice attribute very readable in a camel back style is going to be a bit less readable once it's only written in lower cases! The other possibility would have been to impose the camel back style on all the users which is not practical because non programmers tend to assume that a tag like ooo would have the same behavior as a tag like ooo, changing these assumptions would have been quite difficult, also because it is a current property of many languages.
• There is an included Wysiwyg ( NiceEdit) for the Html language, why not for SEL ? Because it would be : Quite slow and extremely long to program. Also it is not available as an external package and the only example we known of such a program deals with a very small set of instructions inside a specific context! Also to have a Xpetal/Wysiwyg double programming should be done each time on the Php and Javascript side (the Javascript side being much more complicated than the Php side because it's not a natural context (essentially simulating PhP/html interactions in Javascript, therefore it could easily be 1 or 2 order of magnitude slower to program)). Also it would defeat the simplicity we were looking for at the origin of the project, especially using the best side of text editors, so for example if you have positions to change in menus you just cut and paste to get the order you want which is often much faster that clicking your way up a list of hierarchical blocks of menus.
• How does Xpetal exactly looks like ? For example to call the smiley bigsmile we use [emo n="bigsmile.png" /] and we get the result : note that we have an instruction without a body, just a header consisting of its surrounding brackets [], the Xpetal tag itself, in tis case emo for emoticon and the attribute n for name that specify what image we want to use.
• Other tags ? Some other tags have bodies that are surrounded by bracketed tag exactly like that : [MyTag]The Body[/MyTag]. Bodies have a very useful particularity, they can contain other tags that can contain other tags too up to the capabilities of the computer (in fact a bit less because we don't want to make you wait too long, also an infinite imbrication will stop before crashing the system)! Here is a simple example of a tag b encapsulating an other tag u inside its body with cumulative effects : the code looks like that [b][u]it happens here[/u][/b] and the result is : it happens here

Logo explanations : the word Tao emerged luckily from the acronym Ataox! So a Tao based logo to underline the research of balance on the programming and user side became obvious! The squared encapsulated "eyes" are there to recall that it's based on an encapsulating language using square brackets and that the whole process of parsing the language is recursive! The color red and white have been chosen for an optimum visibility and also because it looks a little bit like a rose emerging from the xPetal parsing.