What is DBasis

DBasis is a web-based tool meant for use by developers who are tweaking and customizing SyntaxCMS. It provides a forms based interface for working with content types, their fields, and the relationships between datatypes. It'll also let you create and edit picklists, write some code for you, and a number of other things we won't cover here. By default DBasis is available at your URL in the /admin/dbasis/ directory, and anyone in the admin group can login here.

Creating a datatype

After logging in to DBasis, click on the datatypes tab. You'll see a list of the content types (datatypes is an old label and means the same thing) defined for your site. Some datatypes you shouldn't mess with to much, like administrators (users), groups (used for authentication), and sections ( site pages). But you can add new datatypes as you need but be carefult because, from a maintenance and usability perspective, you don't want to end up with dozens of very specialized content types.

To add a new datatype, fill in the inline form at the top of the table and click on add. The type field should be a short, alphanumeric name for the datatype, Label is a longer, user-friendly name, and Description is a short sentence about your datatype.

Once you click "Add", you new datatype appears in the list. Let's make it available in the admin application. First, you have to "expose" the datatype by editing it (clicking on the yellow arrow button), marking the checkbox in the expose column, and pressing the Save button.

Exposing a datatype is not sufficient, we must also define what user groups can work with the content type and how they can change it. To do so, click on the object tab, click on the link labeled object privileges in the row below the tabs, and then select your datatype from the select menu next to Current datatype. From here you can select an exisiting group in the Group select menu, and mark the checkboxes for the actions allowed for them on the content type. For example, we could have a "writers" group that can view, add, and edit blog posts on the site and also have an "editors" group that can view, edit, approve, and delete blog posts.

In this case, we only have admin users so well let them do anything to blog posts they want.

Take a look at the admin application, you'll see our blog content type is now listed under Manage Content. By the way, you can control the order in which items appear here by changing the order of rows in the datatypes tab in DBasis - except for sections which are hard coded to appear at the top. Clicking on Blog post link there will take us to the list of existing blog posts (which is empty for now). Clicking on the Add Blog post link at the top will also get us to a bare bones input form

Customized Content Type fields

By default, DBasis will give new datatypes a Name field, a Go live field, and an Expire field. All content types must have these fields (although you can rename the label for the name field to "Title" if you were dealing with books for example). Go live (or sunrise as you'll see it in code) controls when a record appears on the site. Similarly, expire ( or sunset) controls when a record disappears from the site. Usually, you need a few more fields than this. To add and edit the fields for a content type, in Dbasis go to the object tab, and click on the object fields link. You'll see a list of the fields defined for blog post. Let's add some simple fields (under field type - these are fields that don't define a relationship between two content types) for users to write a short introduction to each post, write the full text of a post, and select a topic from the topic pick list.

For each new simple field, we need to give it a:

• form label which is what users will see in forms.
• unique name a short identifier unique within the content type
• choose a dbfield, this determines what kind of data the field takes (boolean, numeric, date, text, etc), how it is collected from the user (ie - text input fields, select menus, so on), and also where data will be stored in the database (although Syntax makes this pretty inconsequential for you).
• You can mark the mul checkbox if you're allowing the user to pick from a set of options and they should be able to select more than one.
• You can mark the req checkbox if the field is required and must be filled in by the user before saving the record.
• You can mark the unique checkbox if the field's value (like a username or email field) must be unique for that content type. For example, usernames for administrators must be unique for logins to work.

In addition to those fields, the autogen, widget, validator, and processor menus give you the option to further customize how a field behaves:

• An autogenerator will create the data for the field without user intervention,
• A widget changes the interface used to collect data from the user. Ffor example, a rich text editor for HTML content fields instead of a plain textarea.
• A validator checks the data supplied by users against custom validation rules
• A processor will take the data supplied by the user and transform it in some way. If you let users upload and image you can use a processor to shrink it down if it is too large).

Here are the simple fields we define for a blog post.:

• We rename the form label for the name field to "Title", but other than that, it is unchanged.
• Added a field with name "intro", labeled "Introduction", that uses to the "desc1" db field and is required.
• Added a field with name "content", labeled "Full Text", that uses the "desc2" db field.
• Added a field with name "topics", labeled "Topic(s)", that uses the "topics" db field, it is required and allows the user to pick multiple values. It also uses the "pick1_col" widget to display the options as a set of checkboxes instead of the default select menu.

You can use the green arrow buttons to control the order that they appear in. At the end of it all, you should have something similar to the following screenshot in DBasis

You should also have an input form in the admin application that looks like the next screenshot. At this point, we have a working content type. Admin users can come in and save new blog posts to the database. Syntax will check that all the required fields are correct (something in title, something in intro, at least on topic selected).

Views and admin lists

One last thing you'll want to do, to have a useable admin list once you have some records, is define a view named "admin". A view is a subset of the fields available for a content type. One common use is to show only a subset of all the defined fields in a form available on a public web page. We'll use that when we get around to letting users submit comments to our blog posts. In this case, we can use a view to control the columns that are displayed in the admin list view.

To create a view in DBasis, click on the views tab, make sure your content type is selected in the current datatype select menu. In the first text box Give the view its name, you can also give it a more descriptive label and description for future reference, and press the Add button.

Next, click on the view fields link under the row of tabs. This is where we define what fields are part of an existing view. In this case, we simply want the name field to be part of the view so that we see the name column in admin lists.

Now, after saving o first post or two to our database, blog posts in the admin application will be listed by name. You've know seen how Syntax makes it simple to create content types, define the fields within them, and takes care of building and validating input forms for content editors to use.