Obyx

Obyx is a GPL licensed server-side template engine and a related language of the same name, which was developed to be used for developing dynamic web pages for commercial web sites as a modern alternative to existing languages such as Php. It is notable for using XML syntax, as well as closely adhering to the Model-view-controller design pattern, where the html plays the role of the view, xml or sql data (implemented using mySQL or Postgresql ) provides the model, and obyx provides the control; these are normally kept as separate files providing a very strong separation of concerns. Obyx is similar to (and could be said to compete with) XSLT and FLWOR, but it's purpose is far more linked to web development and therefore Obyx was written to support the technology and protocols used by any typical LAMP architecture.
History
The language was first envisioned in April 2003, as a replacement for an existing proprietary language, with several stated requirements.
*The new language must be simple: easy to use, and easy to understand.
*The new language must allow for continual change: use separation of concerns, especially regarding view and control.
*The new language must be aware of SQL, HTTP, and XML.
*The encoding to be used must be UTF-8.
By March 2006, the language had developed into a working project called 'Context'.
The language was finally named as Obyx in November 2007, and by Q1 2010, the language was made available to public under GPL license.
Syntax
Obyx itself has one primary XML syntax and two subsidiary XML syntaxes for dealing with OSI Application Layer transaction management. These are defined by XML schemas. The language also uses regex implemented by PCRE and SQL implemented by mySQL or Postgresql. The primary syntax, the Obyx language itself, is designed to be fast to learn.
Although a 'hello world' script may look like the following,
<source lang="xml">
<instruction xmlns="http://www.obyx.org" note="display hello world" >
<input value="Hello World!" />
</instruction>
</source>
It is far more common to separate the the view from the control.
Therefore, a more typical example would load and display hello world with two files:
<source lang="xml">
<instruction xmlns="http://www.obyx.org">
<input>
<instruction note="load view">
<output space="store" value="v" />
<input space="file" value="hello_world.html" />
</instruction>
<instruction note="set message">
<output space="store" value="v#//*[@id='hw']/comment()" />
<input value="Hello world!" />
</iteration>
<instruction note="display view">
<input space="store" value="v" release="true" />
</instruction>
</input>
</instruction>
</source>
<source lang="xml">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
<title>HW</title>
</head>
<body>
<div id="hw"></div>
</body>
</html>
</source>
Several important design issues can be illustrated by this latter example.
* The xml / object addressing used by Obyx is XPath 2. Because of this, and because of the need to be able to insert XML fragments into objects, Obyx has extended XPath 2 to include node insertion semantics without using FLWOR syntax. These extensions are
** child-gap() represents a potential node that would be a child of the current context.
** following-gap() represents a potential node that would follow the current context.
** preceding-gap() represents a potential node that would precede the current context.
* Program Flow and Function is tied. This may appears that Obyx loses orthogonality by doing this. But, because XML is tree-based, the structure of the tree does not limit us (we can nest whatever function we like) and it is not possible to separate the treelike nature of a declaration, so using a flow that most accords with an operation is, in most cases, highly intuitive; for example, functions that are required to return a boolean are almost always going to be used for a branch.
* Separation of concerns - the markup developer (typically a designer, or working alongside a design team) can work independently from the programming team, and test the view at any time. The view itself remains valid XML. Likewise the control remains valid XML. Using XPaths for linking the view to control means that the two teams must establish a convention for maintaining insertion points, typically maintained by 'id' attributes in the view's XML.
Limitations
*The language is weak when it comes to complex arithmetic or mathematical constructions.
*By design, the language is limited to one database per host. Database connectivity is managed via a configuration file.
*Verbosity. XML is generally more verbose than to 'C'-like syntaxes, and Obyx is no exception. However, Obyx is considerably less verbose than XQueryX.

Main Menu

See Also

Main Menu