Added memory to the toplevel tabs in the configuration interface When you click on a toplevel tab, you return to the page you last visited below that tab, just like in Roxen 1.3, click again to go to toplevel
The configuration interface now works with more browsers. Some HTML changes were made so that the configuration interface works better with the Mozilla and Opera browsers.
The ports tab has been merged into the site tabs. The old (overview) ports tab is available under the globals tab.
Two new themes added; Square orange, and the new default theme (old default now known as '2.0 and 2.1 theme').
You can now have multiple user database and multiple authentication modules, and the modules only has to implement one of the two services.
Two example authentication modules are included, one that uses cookies and one that use the normal 'Basic' authentication system.
Two user database modules are currently available (unless you count the htaccess module), the system user database and the ldap user database. The system database uses getpwent on to access the normal system users.
The htaccess module now also acts as a user-database, so you can use <if user=username> in your RXML pages (and, if you feel like it, your module level security patterns) with users and groups authenticated from the htaccess module, even if the page does not otherwise use the htaccess permission system.
The variable is set to the latest version for every newly created site, but is then never changed automatically during upgrade. It's set to "2.1" for sites that are imported from earlier Roxen versions.
The intention with this variable is to make it easier to do small changes that aren't strictly compatible, but still avoid jeopardizing the compatibility when upgrading older sites.
There are now more CIF (Compact Image Font) generation and
unpacking programs available in the bin directory.
The introduction of p-code also allows more advanced features in the <cache> tag, which now is powerful enough to allow you to tune RXML pages for substantial performance gains.
The cache also handles variable assignments. You can e.g. do a costly sql query and assign the result to a variable inside a <cache>, and then use that cached value outside the <cache> tag to format it dynamically depending on a user set theme.
See the following examples for some more information
You can also use the size prestate to trigger the sizing process.
Useful for creating template files whose tags and variables are automatically included before any RXML parsing is done of the content files.
The tags defined in such templates also benefits from the p-code speedups.
If you depend on the PID file location specified by the "PID file" variable, you need to move that setting to the start script, either by adding a --pid-file argument or by setting the environment variable ROXEN_PID_FILE.
Changes directly in id->misc and RXML_CONTEXT->misc (aka id->misc->defines) is however not known by the cache system and therefore not saved in the cache entries. This can be a problem when tags uses either of those two mappings to pass state between each other. A (rather silly) example to illustrate:
<my-set value="foo"/> <!-- Does id->misc->my_value = "foo" --> ... <my-get/> <!-- Returns id->misc->my_value -->
Now, if <my-set> is surrounded by a <cache> tag, there's a problem:
<cache> <my-set value="foo"/> <!-- Does id->misc->my_value = "foo" --> </cache> ... <my-get/> <!-- Returns id->misc->my_value -->
When the <cache> tag is evaluated the second time, it won't redo the assignment id->misc->my_value = "foo", since it doesn't know it has happened. Therefore <my-get/> will not return the same thing.
There are two ways to solve this:
<cache> <my-set value="foo"/> <!-- Does set_var("my_value", "foo", "var") --> </cache> ... <my-get/> <!-- Returns get_var("my_value", "var") -->
The set_var call is intercepted by the cache, so it will be redone when the cached value is reused. The downside of this approach is that the variable will be user accessible (with &var.my_value; in this example).
<cache> <my-set value="foo"/> <!-- Does RXML_CONTEXT->set_misc("my_value", "foo") --> </cache> ... <my-get/> <!-- Returns RXML_CONTEXT->misc->my_value -->
This is very similar to the approach above, except that the variable won't be user accessible. The function set_misc simply sets a value in RXML_CONTEXT->misc but also records the setting for the cache.
RXML.TagSet internal = RXML.TagSet("TagFoldlist.internal", ({ TagFT(), TagFD() }) );
The first argument should earlier be a string that uniquely identifies the tag set in the whole server (which the one in the example above from the foldlist module clearly doesn't). Now, one instead gives the own module as the first argument and a string that only should identify the tag set uniquely within the module (the empty string is reserved for the main module tag set). The example above thus becomes:
RXML.TagSet internal = RXML.TagSet(this_module(), "foldlist", ({ TagFT(), TagFD() }) );
For tag sets that are used for local or additional tags inside a container tag, it's typically a good idea to use the name of the container tag as the unique identifier, hence "foldlist" above. (Note that these identifier strings are stored in the dumped p-code, so it's a good idea to keep them fairly short.)