This page details the parent page. It may include information such as the format or structure used to implement a feature.

What is the Session Random Number?

Each time a user access Snap! Websites pages, he receives a cookie. That cookie include a session identifier and a session random number defined as:

<session identifier>/<session random number>

The session identifier does not change between accesses unless something goes wrong. The session random number changes on each access. This allows us to prevent the use of a session by a hacker for more than one page access if both the hacker and the user being hacked both use the site at the same time. Figure 1 shows a normal session with a ...

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 ...

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*" ...

In order to implement the layout selection we setup the QtScript instead of using our own scripting language since it's already working. At some point we'll want to switch to our own version for speed (i.e. pre-compiled byte code.)

The QtScript is plain JavaScript without any special extensions, however only the system will generate code so we're safe on that end.

The script is expected to return the name of the column defining the layout to use, or an empty string. If empty, then the process is repeated with the page type and its parents (see Layout feature [core]) This column name is ...

Links between rows

All the data in our system is linked one way or another. It is important in order to organize the data in a tree and to categorize it (to not say tag it).

The data starts with a Root node and everything is defined under that root node. The linkage is done using the name of each node and the name of the category being used (a category is itself a node of content, so for example the User category is a node defined under the Root node and a user account is defined as a child of the User category. Thus to find users, you start from the Root, go down to the User category, and then list all the ...

When using an SQL environment, it is very easy to create a new row of data with a unique number. You use a sequence identifier and your SQL system generates the numbers for you.

With Cassandra, there is no such thing as a unique number. There are facilities to count (add and subtract) but no unique number. This is actually very important to let the system go as fast as possible as it is expected to do. Because the only real way to create a unique number is to either make use of a single computer which generates those numbers (be it with an SQL database or another system) or to have all the ...

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 ...

The following is a list of HTML meta tags and links we want to support in Core. More will be added with time and some will be removed as their corresponding reference disappear.

Many of the links are defined by RFC 5988. Some are specific to a feature (icon, hub) and others are defined in Core (top, up, next, previous...)

Note that the Dublin Core meta tags were introduced with "dc." before. They now use "dcterm." instead.

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.

Syndicate content Syndicate content

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

Contact Us Directly