Internal Translation

The basic concept for the internal features of the Snap! Websites is to only offer templates (no text). There are obviously limits to that scheme. Text is used everywhere and thus we need to include the text somewhere. However, we want to clearly separate layouts and other text agnostic data from content itself. The layouts (templates) are not translated, content is.

For sure, C++ has a real problems when it comes to writing a message. In most cases, people want to use the std::cout << "Something" << std::endl; syntax because it's C++. ...

We support uploading of files to a page. This is very similar to having attachment to an email. At this time, the uploaded files are added as children of the page. The upload feature makes use of the Editor feature [core] with Drag & Drap functionality and Widget feature with the Browse Button.

However, a complete file manager has to offer the ability to delete files, rename files, move or share files from one page to another (and these features are not yet available).

Implementation Note

The visual part of the file manage has to be a Widget (??? I think now that all pages accept ...

We want to have an auto-save feature that takes the content of an editor and all the flags and everything else in the form and send it to the server via AJAX as a temporary save (or auto-draft.)

More or less, if the user comes back after losing his connection, he will see what was auto-saved and not the current state. (i.e. a special revision, if you wish.)

The auto-save must be fully secure just like the regular submit button.

Assuming that he Submit is also an AJAX POST, then we don't need to duplicate the work (especially because we'd want the page to auto-update, etc.) the only ...

Sitemap

We want to generate an XML sitemap with all the pages that the system offers1.

Since the pages are not all clearly defined (i.e. a feature may generate hundred of pages) it is important to allow plug-ins to define their XML sitemap entries.

For example, the taxonomy feature allows you to categorize a page using tags (taxonomy pages titles). Pages that were categories can be listed by the taxonomy plug-in on generated pages. Such would not automatically ...

• 1. Although some pages may be hidden by the users, and obviously any non public pages are never added to the XML sitemap.

One very strong feature in advanced CMSes is to offer administrators to create functions (a set of actions to take) that get executed whenever a signal is received.

The feature requires three parts:

Signals

Whenever an event occurs, we send a signal using the emit keyword (in our C++ code.) This calls an internal function that propagates the signal at the user interface level (the administrators.) It is called after all the internal features were called so only the final result is received by the user interface (this being said, if we call set_title() multiple times we'd signal that ...

Anti-Delete

Some pages just cannot be deleted. If so, it would break the system as a whole.

The current implementation adds a lock to all the pages automatically added through the add_xml() function (via the content.xml file.) By default, all those pages are marked as "cannot be deleted." And no one can change that from the interface (obviously, if you have direct access to the database...) As the implementer of a content.xml, you can change the default if some of your pages can safely be deleted and are expected to be deleted at some point.

Locking

We want to look into ...

Since multiple people may all be working simultaneously on the same system, we need a preemptive mechanism so two users trying to edit the same data cannot both enter the editor simultaneously.

The editing should be limited in time so if the first user leaves his editor open for more than 1h, bang, he loses control (we may want to have a reset of the timer as the person types in the editor! Just a bit of AJAX...)

So, first user comes in and clicks Edit.

Second user comes in and clicks Edit, the system finds out that the page is locked, he gets a message saying "John Smith is already ...

We already have a way to display a post that can be commented (Forum Post with replies.)

We have lists of categories (Forum Topics) since we have lists of pages.

We have lists of pages assigned a given category (Forum Posts in a given Topic.)

Lists can use link meta tags to connect multi-page forum posts into one and the categories all together (link prev, next, up, top, etc.) Therefore this can also be made SEO friendly.

Therefore this feature will be available without further development other than a forum look and feel. The only reason to make use of a plug-in for this feature ...

Along with the Password Protect feature, it is possible to block users from different areas without them entering a second password. We want to make sure that entering a 2nd password does not break the functioning of the first password. Also, we have to stick to the 1 cookie per person scheme.

We may create a plugin for a contact form using the widget system to add a contact form on user pages and for the website as a whole. The form should be a couple of pages the administrator can edit: one page for the site wide contact form and the other for the users' contact form.

See: Widget feature