Community day

At the eZ Winter Conference 2010, meet up with the community in Geneva, jan. 21st.
Register and read more here.

Naming conventions for content classes attributes

Give your rating!

Thursday 29 October 2009 10:15:00 am

At Contactivity, we found that the default content class attribute names (image, file, etc) are sometimes confusing to work with: especially in templates where the output of several content classes are combined. It is not always clear what type of datatype we are dealing with (eh, was this a textblock or an xml block?), so we need to go back to the content class definitions to check that.

We found that using more descriptive content class attribute names saves us time and makes our code more readable. Our naming convention for eZ publish content class attributes is as follows:

[class_prefix]_[attribute_name]_[datatype_initials]

For example, the attribute identifier for an article is:

art_intro_xmlb

The attribute identifier for a downloadable file in a blog post is:

blp_file_file

Available datatype initials include:
o auth - Authors;
o chkb - Checkbox;
o datt - Date/Time;
o mail - Email;
o file - File;
o imag - Image;
o keys - Keywords;
o mtrx - Matrix;
o link - URL;
o user - User account;
o xmlb - XML block.
o etc...

But:
- Some of the attribute names we do not change (for example, the 'image' attribute in the image class) because these are 'ez publish' configuration defaults;
- Of course, the use of more advanced debug info also helps;
- Sometimes we need the attribute name of the attributes of two different classes to be the same, in order to simplify a fetch.

We have developed a set of standard content class definitions and matching templates that we use as our 'base' design.

We are interested to know if anybody else uses naming conventions for content classes. Is there another way to do this?

Sebastiaan van der Vliet

Member since: 07/03/2003

Postings: 77

For eZ publish expert advice and troubleshooting services, please visit:
http://www.contactivity.com/solutions or email info@contactivity.com.

For our extensions, visit http://code.google.com/hosting/search?q=label:Contactivity

Certified developer with over 8 years of eZ publish experience.

Replies

Thursday 29 October 2009 4:21:07 pm

Hello Sebastiaan,

Interesting subject.

We try to follow the as semantic as possible approach, so our variables are long and full of meaning And so are the identifiers of any kind (no abbreviations), but we try not to double of what is already expressed with native structures, so they carry no information about class or datatype, like yours. I wouldn't like that either for any evolving project that I have to maintain, because that may quickly lead to inconsistencies that could be a headache.

We have some conventions for prefixes/suffices like holders/containers/catalogs for folder-like class names, the rest we try to keep as descriptive as possible.

Any simplification or unification of fetches and other repeatable pieces of code we do by abstracting them with includes of smaller template bits that can actually act as functions. Again, I wouldn't like to remember that my application relies on attributes having to have the same names. Of course, what you wrote is not exactly example of that situation, but may slightly take the code that way. Also, what if you rely on your attribute being named "file", and then you find out that there are two more file-like attributes required? This is why I would prefer to name the first file more precisely, like "cv_file", and then add two other accordingly.

However, those all rules often have to be bent to handle the reality

Piotrek Karaś

Member since: 25/07/2006

Postings: 875

--
Company: mediaSELF Sp. z o.o., http://www.mediaself.pl
eZ references: http://ez.no/partners/worldwide_partners/mediaself
eZ certified developer: http://ez.no/certification/verify/272585
eZ blog: http://ez.ryba.eu

Thursday 29 October 2009 5:08:05 pm

Hi Piotrek,

Could you give a few examples? I am interested to know how you use conventions for prefixes/suffices like holders/containers/catalogs.

Regarding your question:

>> Also, what if you rely on your attribute being named "file", and then you find out that there are two more file-like attributes required?<<

In such cases we use the object relation browse datatype. This allows us to translate the eZ publish content model into a more 'relational datamodel'. As far as naming conventions are concerned, for multiple files for the class 'article', we would then use the following attribute name:

art_file_obrb

Another example: if we would use predefined labels (using a 'label' class) for articles, we use