Naming conventions for content classes attributes

Next topic

Author	Message
Sebastiaan van der Vliet	Thursday 29 October 2009 2: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? Certified eZ publish developer with over 9 years of eZ publish experience. Available for challenging eZ publish projects as a technical consultant, project manager, trouble shooter or strategic advisor.
Piotrek Karaś	Thursday 29 October 2009 8:21:07 am 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 ;) -- 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
Sebastiaan van der Vliet	Thursday 29 October 2009 9:08:05 am 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 art_label_obrb Certified eZ publish developer with over 9 years of eZ publish experience. Available for challenging eZ publish projects as a technical consultant, project manager, trouble shooter or strategic advisor.

Author

Message

Thursday 29 October 2009 2: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?

Certified eZ publish developer with over 9 years of eZ publish experience. Available for challenging eZ publish projects as a technical consultant, project manager, trouble shooter or strategic advisor.

Piotrek Karaś

Thursday 29 October 2009 8:21:07 am

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 ;)

--
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

Sebastiaan van der Vliet

Thursday 29 October 2009 9:08:05 am

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

art_label_obrb