Development Status Not Applicable

Some pages in the book are details about a feature or combination of features. This special status is used for those pages since they are not expected to have a status per se.

See a complete list of features sorted by Snap! Websites Development Status (note that not applicable pages are not shown in that list.)

Plugin Limits

As we started using plugins, we started finding limitations on their use. First of all, plugins are expected to be used with signals. If not, then you run in a very simple problem: the plugin becomes a required library so you could as well compile it in as a .so file. It would be much easier and work as well. That's certainly the most important point. The following lists all the limits we are running into:

Train of thoughts to do it right

Since I now got a little practice, I have come up with a way to make it right from the start. The one most important concept for any plugin is to ...

WARNING: We are deprecating this plugin. The editor works great in all browsers so we do not see the need to support two similar capabilities, one of which is limited to what the browser is willing to offer us (and thus all of our additions would need to be programmed as in the editor and we would have yet another duplicate!)

I'm just starting work on the widgets as I want to have a form to register and log in as a user.

These forms are very simple, but I want the full capabilities in the forms to be available (Even if we don't have all the possible widgets.)

Different widgets ...


In order to keep our code as easy as possible to maintain and enhance, we request that all code submitted for the Snap! Server be written in a very specifc way as described below. Being very consistent very much ease reading each others code. The most important aspect is indentation. Definitively make sure your indentation is correct! Although we encourage you to submit patches and plugins of your own making, we require that this coding standard be followed before you submit anything or it is likely that it will be rejected (we do not have the time to do the formatting for you ...

Table Fields

"domains" Table

The table includes the rules to be used to check a domain name and determine the exact website key. The key of the domain table is the domain name and TLD which is computed from the URI.

Field Name Description
core::original_rules Rules as written by the user. (text)
core::rules Rules after parsing the original rules. This is a serialized buffer of rules ready to be used by the Snap parser. (QtSerialization output)

The table has a special row named "*index*" ...

When a domain rule set matches, Snap generates a canonicalized domain name which it uses to access a website rule set. (The snap-manager tool will soon offer a way to test your domain names to see what the canonicalized version really looks like, but it should as you expect... everything except the flags.)

Once the name of a website rule set was determined, it can be added using the Websites tab of the snap-manager tool. As you can see, like with the domains, you have a New button at the bottom of the tab. Click on it to create a new website entry.

The rules are very similar to those found ...

Known Issues

The following are known issues that are beyond what we can repair.

These generally result from an operating system, a development environment, or a project over which we do not have direct control.

We try to provide the current work around or a way to repair your environment when we have an idea of what it is.

Now the tables...

[these are old tables created a while back and they do not correspond the current scheme]

The new scheme will use a similar set of data, but it uses namespaces to distinguish fields from the different plugins. So for example if the title of a page is called "name" and the content module handles the title, then it will be saved in column: "content::name".

Pages are a quite broad concept that is run first by the core of the system and also by additional plug ins that add functionality to the pages. To do so the system and users can create and edit ...

Page XSLT definitions

The following describes the XML format expected by our layout XSLT files.

The XML is dynamically generated so we do not check it against a DTD at this time, although we will probably add that capability at some point so in Debug mode we'll be able to detect whether the we make a mistake when we create the XML.

XML File Header

Since it will generally be created in memory, the XML header will generally not be seen. However, for debug purposes, our XML data can be saved in a file in which case the XML header will appear. At this point, we do not include any information about the DTD.



The Layout is implemented using XML data from the database, variables from the running process, and a set of XSLT define in your layouts and internal extraneous XSLT definitions as offered by the core and different extensions.

XSLT is used to transform the XML data into an actual page that can be display in a website.

This page gives some information about XSLT and different features available in that language.

[Note: I'm writing this before doing the actual implementation of the data and therefore it is likely to change by the time it is fully implemented.]

At the ...

Some C++ References

C++ Operators

The following gives you the level of all C++ operators. It is often useful to know.

(table follows)

Snap! Websites
An Open Source CMS System in C++

Contact Us Directly