ez.no / ezpublish / documentation / building an ez publish site / the members page / creating a custom content class
These documentation pages are no longer maintained. Please visit the new documentation site.
As pointed out in the previous section, we'll use the CMS to store information about the members. Lets say that we would like to store the following information (for each member):
But wait! How can we store all this custom information? If you take a look at the list of the built-in content classes, you'll discover that none of them is even close to being suitable for storing information about TSCM members. What we have here is a typical content management problem. Fortunately, unlike other content management systems, eZ publish allows the users to create their own content classes. Instead of having to fit our data into a predefined, rigid structure, we have the power to create our own custom structure. The following list of steps explains how to do this.
eZ publish will then start the creation process of a new, custom content class. We'll need to specify a name for this class, lets just call it "Member". An identifier will also have to be specified. Each content class may be identified using its ID number or identifier string. The identifier is a friendly string. It is easier to remember and more flexible than an ID number.
We will now start adding attributes to our new "Member" content class. The following text explains how to add the desired attributes.
The "Real name" attribute.
This attribute will be used to store the real name of a member. We'll use the built in "Text line" datatype for this attribute. Since we can't have a member without a name, we'll set the required flag. This means that every time somebody tries to add or modify a member, the system will not update that member as long as the name field is empty.
You've now added the first attribute to the "Member" class. Since the "Searchable" checkbox is checked, this attribute will be searchable by the built-in search engine. In other words, it will be possible to search for members (by name). This functionality will be revealed and explained at a later stage.
The "Nickname" attribute.
Some chess fanatics tend to have lame nicknames such as "King", "Knight-rider", "Rookie" etc. The nickname attribute will be used to store a possible nickname.
The "Date of birth" attribute.
This attribute will be used to store the birthdate of a member. We'll use the built-in "Date field" datatype.
The "Gender" attribute.
This attribute will be used to specify whether a member is a male or a female person. The "Selection" datatype will be used. This datatype is perfect for quick'n dirty single and multiple choice scenarios.
The "Telephone number" attribute.
This attribute will be used to store a member's telephone number. Since some people don't have a phone, we'll not mark this attribute as required. We'll use the "Text line" attribute to store phone numbers.
The "E-mail address" attribute.
This attribute will be used to store a member's electronic mail address. Since some people don't have an E-mail address, we'll not mark this attribute as required. We'll use the "E-mail address" attribute to store the members e-mail addresses.
The "Picture" attribute.
This attribute will be used to store a digitized photograph of a member's face. We'll only allow image files that are smaller than one megabyte.
That's it. The "Member" class is now made up of exactly those seven attributes that we wished for at the beginning. Click the "Store" button; eZ publish will then store the class definition in the database. The next section explains how to add member objects.
Comments
E-mail vs email
James Ashley
Thursday 18 August 2005 12:56:59 am
email is a name the computer recognizes (most systems have problems with names like E-mail, because they think you're trying to subtract). I don't have your post in front of me now (which is annoying), and I don't remember the details.
But, basically, you had something like:
long.bunch.of.classes.and.attributes.to.get.to.email.details.attribute_name
^^^^^
inside some other stuff.
'email' here should be the identifier you entered when you were defining your class.
Getting to email's "attribute_name" (or whatever it was actually called in your post) *ought* to return the name you entered when you were defining the class (in this case, E-mail).
Of course, that may not be the way it works. If I'm wrong, please correct me.
Typo that will cause problems in the following template
Kevin Cook
Sunday 13 February 2005 5:55:52 pm
"Type "E-mail" into the name field."
is a typo error in the sense that in the following page(s)where the user is asked to create an override template called: full_view_member_class; in that template (if the user copies and pastes the code, as I did) the 'E-mail' attribute is referred to as 'email' not 'e-mail'.
from the template example: "...<td>{$node.object.data_map.email.contentclass_attribute.name}:</td>
<td>{attribute_view_gui attribute=$node.object.data_map.email}</td>...."
So be warned, either you need to change the attribute name or the template references to have your members emails show up.
krc
Attribute suggestions
Steve Brown
Saturday 22 January 2005 4:19:22 am
Also, some sort of simple pattern validation in text fields such as zip codes (#####[-####]), Canada postal codes ('A#A #A#') and phone numbers (###-###-####) would help reduce data entry errors and help keep data consistent.