A guideline for module naming

[Nico Knoll]

Hi,

what I really want t have is a guideline for module naming. So it would be much easier to sort the modules on the module page.

The guideline should at least contain a table of recommend first words, like Process or Fieldtype and a description when I should use which...

Greets,

Nico

[ryan]

I agree, we'll get there. This needs to accompany the larger module documentation, something that I'm hoping to get in place shortly after the 2.2 release.

[Oliver]

Had a similar thought right this morning, Nico. That’s definitely a must, as the dev community and the numbers of modules seems be growing. There should be a kind of best practice guide including naming guidelines for modules and for their db tables for example. How to organize modules with multiple files / classes, how and where to store module specific config data etc.

[ryan]

I agree with all this. Here are the curent module naming conventions (first word in module name):

• Export - any module that provides site data export capabilities, especially where there may be a related Import module.
  
• Fieldtype - any module that extends the 'Fieldtype' class. Represents a data type used by ProcessWire fields.
  
• Form - any module that deals with creating/processing web forms (some crossover potential with Markup).
  
• Inputfield - any module that extends the 'Inputfield' class. Represents an HTML input widget used to collect data in the admin.
  
• Import - any module that imports data to create new data in a PW site.
  
• Jquery - any module that adds something related to jQuery/Javascript.
  
• Language - any module that provides support for other languages
  
• Process - any module that extends the 'Process' class. Typically attached to a page for handling admin actions. If it's related to another Process module (core or 3rd party) it's name should start with that module, i.e. ProcessPageEditLink is related to ProcessPageEdit.
  
• Markup - any module designed for creating or parsing markup
  
• Page - any module designed to add capabilities to PW's Page class.
  
• Textformatter - any module that extends the 'Textformatter' class, for runtime output formatting of text fields.
  

Some of the naming conventions are based on the root class that they extend, though not all. New additions to this list likely won't be based on extending some built-in class, since there aren't any others. Though I would suggest that when a module doesn't fit in the above, it should start with the class name of the core class or module it is hooking into (not unlike the 'Page' one above). So if you are adding hooks to the Pages class, then start your module with 'Pages'. Likewise if you are adding hooks to the Session class, then start your module with 'Session'.

Beyond this, the naming conventions are open ended. I guess the first thing we have to determine is: what are the major classes of modules that aren't covered above? I can't think of any at the moment, but I know they are there.

[teppo]

Sorry to bring an old topic back to life, but there's something I've been trying to make sense of lately regarding module naming: what should one call a module that is clearly related to other module, but still technically speaking very different from it?

This problem seems to show up quite often especially with Process modules that require hooks etc. I'm currently working on something that is directly related to Process Page View and I'm having some trouble deciding whether to name it a) something completely different (Page-something perhaps?) or b) Process Page View [insert-specific-feature-here] even though it's not really a Process module itself.

What do you folks think? Or am I just overthinking this?

Also: I'm currently a bit worried when I look at the modules page of my test site and already see quite a few "module groups" with only one module in them; "Admin", "Comment", "Custom", "Lazy", "Schedule" and "Multisite" to name just a few. This isn't a big problem yet, but it does imho somewhat undermine whole module group concept. I don't have an answer on how to fix this, but I do feel that something needs to be done -- and preferably rather soon.

Edit: for some reason what Ryan said up there ("Though I would suggest that when a module doesn't fit in the above, it should start with the class name of the core class or module it is hooking into (not unlike the 'Page' one above). So if you are adding hooks to the Pages class, then start your module with 'Pages'.") didn't really sink in before I had posted this.

If I'm getting this right, it would mean that if my module adds hooks to Process Page View it should be named after that -- thus it's name would start with Process, even though it's not a Process module. Still doesn't sound quite right considering technical differences etc. but perhaps it's the right way.. Guess I'll have to think about this a bit more. (Also the worries I mentioned above about current module naming conventions, or lack of them, still seem valid.)

Edited November 10, 2012 by teppo

[ryan]

Technically the only module groups built-in are those that start from a base class: Process, Inputfield, Fieldtype, Textformatter, ModuleJS. The headlines you see in the Modules list are runtime grouping of the first word in a modules' class name. Conveniently, this works with our our base-class module groups, but it does also extend to other modules with similar naming conventions. For the most part, I think it's better not to use one of the base class names for your module unless it extends that class. In the future, we may want to offer other types of runtime grouping options like: modules related by dependency, autoload modules, etc. Related modules in a group may have different naming conventions by need (like a related module set that has it's own Process module, Fieldtype and perhaps others) -- these aren't expected to appear together in the modules list.

[kixe]

I posted an issue related to modules naming guide/ convention on github. https://github.com/processwire/processwire-issues/issues/164

Any guidelines using numbers in general in module names like @adrian or I did

• Process404Logger
• Process404Search
• HTML5Boilerplate