{contenu}
Naming conventions
{contenu}
The standards provide uniform technical reading and support.
This is interesting if the technical framework and the training of developers is always the same.
But when the team  is confronted with new demands, that involve changes in habits.
Too closely following the norms can be sort of jail that create a waste a lot of time.
{contenu}
Since we have to write in PHP and Javascript, but also manipulate HTML DOM and CSS elements, we need some rules to avoid reading difficulties and running problems.
To understand how they apply, observe the contents of a PHP file from a module whose first letter is in capital.

PHP side:
  • In general we do not use the CamelCase style because it is used in Javascript and in many PHP tools.
  • For a class, the first letter is in capital letters, and therefore the name of the file in which it is also written (because of PHP namespaces)
  • the name of the module is the first constant written at the beginning of the module, and preferably it should contain only lower case alphanumeric characters (you can sometimes also use the characters - _ and ¤ but only in very simple modules that do not overlap too much with others).
  • For a function, lower case letters only and _ . PHP functions names are like that as well, but since the call will necessarily be preceded by a namespace or a global object or a $this, one cannot confuse with native functions.
  • For automatic processing of posted variables, they must match this schema: nameofthemodule_tablename-fieldname (functions are available to create these names).
  • Some variables are written entirely in capital letters: Shared global objects, and action variables whose name begins with $ACTION.
  • If there are actions to manipulate an object other than that of the module, the action is usually named as follows: $ACTION_ACTIONNAME_objectname in order to differentiate the basic actions that they will not have a lower case object name.
  • each module is an extension of HelPHP_module class, so pay attention to the names of the constants, properties and method already existing (unless you wish to extend them)
  • in libs/init.php and in other libraries containing a method called "create_ instance", some globals are created whose names are reserved:
    • $CONFIG
    • $CONFIG_DB
    • $CONFIG_EMAIL
    • $CRYPT
    • $DB
    • $DB_CENTRAL
    • $FS
    • $H
    • $LANG
    • $MEDIA
    • $SESSION
    • $USER
  • Finally, it should be noted that most HTML display elements will have a concatenate identifier with _$this->dom_id (unique identification of the module execution instance), which will make them unique for the various Javascript methods in case the module is launched several times in the same DOM space. It will therefore be necessary to transmit the value of $this->dom_id when initializing scripts.
{contenu}
On the Javascript side:
For Javascript the rules are necessarily a little different:
  • Since there are many libraries that use the first capital letter for the class name, we opted for a prefix: "H_" .
    For example for the "DOM" class, the name is "H_dom".

  • To easily access it, and to solve the recurring concern with scope problems through the various documents, the script that is in the js/init.js file (or any library) create the global super object "h", and assigns to it objects that instill libraries. For example: h.a = new H_ajax();
    The ajax library therefore becomes accessible in any script by this object which serves as a shortcut and is the most concise form possible.
    If you want a little more clarity and verbosity in writing your scripts, each library instance is also accessible via "h.libs", so for the H_ajax class, we can call it via "h.libs.ajax".

  • The "h" object is related to "window", so using "windows.h" you can call any library or module method from the current page, an iframe etc ... And without any potential conflict with a "prototype".
    The fact of assigning everything to a super object also allows a better control of the "garbage collector" and therefore of the memory usage.
{contenu}
  • So to create a new library, the file must start as follows (example with the H_ajax class):
var h = h - Yeah. {};
h.libs = h.libs - Yeah. {};
/**** comments and documentation
class H_ajax {
in order to create the h.libs object if the file is called alone or first, and after class should be added this:
  h.libs.ajax = H_ajax;  
for the class to be accessible since "h.libs".
  • For modules, like the PHP part, each module script is an extension of the H_module library and is named like the PHP class, with the first letter in capital (but not necessarily the file, no namespace concern this time).

    But as there may be scripts for the admin side and for the public side which in some cases (previewing for example) can be called in the same page, they must be differentiated, classes for modules receive the _a suffix for the admin side.

    For the "users" module for example, we have the class "Users_a" in modules/users/admin/users.js, and the class "Users" in modules/users/public/users.js.

    Each module class is accessible from "h.modules_class", for "Users_a" it will therefore be "h.modules_class.Users_a", we keep the name as it is this time because it is to access the method of the module but not its instance which will be accessible from "h.modules" (we will detail this in the next chapter).

  • For functions and methods: name preferences with tiny characters and separated by _ as for the PHP side.

  • For variables, there are no strict rules, names with tiny characters and separated by _ go very well, there is less readability concern than for PHP, so more freedoms.

What about the elements of the DOM that Javascript manipulates?
{contenu}
DOM elements (HTML):

If you want to manipulate DOM elements from javascript, there are several classic tools like getElementByID, getElementsByClassName, querySelector, or querySelectorAll that allow you to manipulate any element.
But to simplify things, having unique IDs is relevant.

To create this unique ID, we have two very convenient PHP variables:
$this->css , which returns the name of the module with an "_admin_" if the module in question is admin side,
and $this->dom_id that returns the unique identifier of the current module instance.
Concatenated with PHP: $this->css.'idtag'.$this->dom_id one obtains a unique identifier for a tag belonging to a module instance.

The same result can be obtained using the magic methods of the PHP library HelPHP_module:
$this->dti_idtag or $this->domtagid_idtag returns the same string...

Example application in the hierarchy module on the admin side for the display of the hierarchy that starts with a "UL" tag:
$tree = H::UL(['class'=>$this->css.'tree_parent', 'id'=>$this->dti_tree_parent, 'data-id'=>$post[$this->ifld_structure_id]]);

$tree becomes a class H standalone object representing an UL tag with a CSS class "hierarchy_admin_tree_parent", an id "hierarchy_admin_tree_parent¤215212154" and in data-id the value of a posted variable (we will see that later).

So to make it simple, you can use $this->dti for id in any case.

For the "name" attribute of the "tags" type "input" that is required for processing the form, we will use another magic method: $this->ifld (you can also use $this->inpfield or $this_inputfield if it is more readable for you).
This method for the input attribute name in the forms is essential because it allows to automate a lot of things:
$this->ifld_data_id is equivalent to a string that is the concatenation of the module name, the table name ("data") and the field name ("id").
$post[$this->ifld_data_id] will contain the value of this field when you read SQL data for a modification form or when you receive a $_POST (we will see in detail this later via the CRUD methods).

We can see that the CSS class of the element shown as an example is also the concatenation of a constant and a chosen name, is it the same everywhere for CSS?


{contenu}
CSS:

For CSS, things are pretty simple:
We name CSS classes with lowercase characters more _ in general but as they are usually composed by the concatenation of $this->css and a chosen name, there is no confusion possible when reading the code on the PHP side.

However, to facilitate CSS design work, some redundant elements have the same class
(as a tag can have several classes, you can add yours if needed, if you want to apply another theme system).
The following is a list of the items in question:

  • The base container of the module: module_container

  • The title of the module: module_title

  • The selection form of the item to be modified: form_select

  • The item's ID being modified: module_current_id

  • The editing form of an item: form_edit

  • The container for editing buttons at the end of the form (save / delete): edit_buttons

  • The action button container at the top of the module: action_buttons

  • Edit form for multiple items: form_multiple

  • An item in the_multiple form: form_multiple_line

  • The item search form: module_search

  • Advanced research fields:search_advanced_fields

  • The container that displays search result:search_result

  • An item in the search result: search_result_row with entete for the header

  • Backup button: button_save

  • The removal button: button_delete

Since the helpPHP instance contains a lot of tools for managing CSS and themes, if you want to keep themes that are not too heavy, it is important to avoid changing class names for redundant elements.
TitreRésumé
How to name variables, classes, etc, without conflict with original language
Date de création2025-11-17 00:00:00Date de publication2025-11-25 00:00:00