The Webvanta system is designed for two types of users: developers and content editors. The developers build the site, and they must have a technical understanding of web coding and the Webvanta system.
Once the developer has set up the site, the Webvanta database system is designed to make it easy for content editors to enter and maintain content. Content editors do not need any technical skills, and they don't need any software other than a browser.
Everything about your site is stored in the database. Part of the database works automatically, through built-in functions such as managing pages, templates, CSS files, and so forth. When we talk about using the database, however, we're generally referring to use of custom databases to store structured content: content with a field structure that repeats for each item.
A school, for example, would have database structures for people, courses, programs, etc., while a manufacturing company might have product lines, brands, products, people, and locations.
Common website features, such as blogs and calendars, are easily built with the Webvanta system. Your blog posts and events, for example, are just conventional custom item types that you can enhance however you want.
The first step in designing the database for your site is to consider what kinds of structured content you have. Most sites have several, and some have a dozen or more: people, events, courses, products, brands, product lines, articles, press releases, videos, presentations, etc.
The Webvanta system is uniquely powerful in how easy it is to create whatever database structures you need to model your content. The site developer creates item types just by filling in forms, and the corresponding database and all the admin pages are automatically generated.
To organize your information, you can use any number of taxonomies associated with each database item. A taxonomy is a set of terms, either flat or hierachical.
Taxonomies enable you to organize the content of the database by subject; they answer the "what's it about?" question. Hierarchical taxonomies can be nested to any depth (sub-category, sub-sub-category, and so forth). An item can be assigned to any number of terms within one taxonomy, and across multiple taonomies.
A store that sells lumber might have taxonomies for specials, grade, and size, while a horse breeder's site would have taxonomies for breed, color, and gender.
Two common uses for taxonomies are to organize things into categories, and to tag articles or blog posts. Both categories and tags are just taxonomies. Conventionally, tags are a flat taxonomy, and categories are often hierarchical. With the Webvanta system, you can make however many taxonomies you need, and call them whatever you want; "categories" and "tags" are just two common names.
Another difference between categories and tags is that tags can usually be created on-the-stop, when tagging a particular item, while categories typically use a controlled vocabulary — a predefined set of terms, defined by the site administrator.
See Working with Taxonomies for the details on how to set them up and use them.
(Historical note: earlier versions of the Webvanta system had pre-defined "categories" and "tags" taxonomies. Now these are just taxonomies that you can create if you need them.)
To facilitate the display of lists of items, and the details of individual items, the Webvanta system provides a number of different page types. For the most part, what's special about page types is how the system uses parameters that are included as part of the URL.
Parameters in the Webvanta system are separated with slashes, just like parts of a URL, such as:
In this example, the page is "product" and "hand-lotion" is a parameter being used by that page.
Item pages are the workhorse page type. They're used to display any kind of database item. The URL consists of the page slug (such as "product"), followed by a parameter (such as "small-blue-ball"). For example:
The system automatically retrieves the specified item from the database and makes it available to the code on the page.
There's a lot of flexibility in how URLs for item pages are formatted; see Using Custom Item Identifiers for Item Detail Pages, and Customizing URL Generation for Database-Driven Pages for the details.
Category pages are much like item pages, except they expect a taxonomy term, rather than an item ID, as the parameter. A category page would be use to display all the balls, for example, or all the Friesian horses, or all the recipes for borscht.
Sometimes you want to pass more than one parameter, such as the type of product and the manufacturer (to get all the balls made by Ace). The "variable page" lets you pass any number of variables as part of the URL, and your page logic can then use them in any way to choose what to display.
For example, you might have a fancy category page that takes category, color, and size parameters, with URLs like:
Setting up variable pages takes a little extra work, because the complete flexibility of what the parameters are means that you need to provide all the code for selecting items, generating page metadata, etc.
See Using the Variable Page Type for details.