Guidelines for Module Development

Original -

Part 1 Building a simple module
Part 2 - using Smarty templates in a module
Part 3 - Building an AJAX module
Part 4 - Xoops Blocks

Before you create a module, define what it should do first. If you start with clear objectives, working to resolve them becomes easier. Never start a module with code. Why? Because if you do, you will be limiting the module to what you already know in terms of code instead of what it SHOULD acomplish. A good example of this is writing themes for xoops, if you start hacking away at a default theme, you start off already limited. However, if you use an image (photoshop, etc) or vector (ilustrator, corel draw, etc) program to start, you can create a visually rich web page. Then you can use that as the basis for your new theme. This way your not being limited by code. I interviewed BitC3R0, webmaster of xoops-mexico back in 2005 (published in 2006) it's worth reading his ideias on theme and module development.

Templates -Aesthectics Vs funcionality.

As you get better at PHP and Xoops development, you will find that you are cramming more and more functionality into the templates, making more and more use of <{if}> statements. This is a mistake because the whole point of using smarty is to visually arrange the html code. If you open a smarty template in a wysiwyg editor and can't understand what's going on, then you already have too much going on inside it. So, how do I give users options without overloading the templates? With help files. Show the users available options they can use inside the templates. For example; You have an article. Instead of having a xoops preference for each individual item such as article date, name, title, publisher, etc, create a simple base template then show your users which options are available in case they want to add more info to that template; <{$art.title}>,<{$}>,<{$}>,<{$art.publisher}>,etc.

Server Load - Always a concern.

Try to minimize the number of times your module has to access the database. One comon mistake is to create DB queries inside of loops. This is a BIG mistake. As your modules tables grow, so will the number of queries.

One to Many - Database Relationships

To explain this I'll use an example. Let's suppose you have a database table with the following information about your clients:

ID telephone
12 23465544
13 32144323

Now, what if I wanted to add more phone numbers for each client? Your first thought might be to create an array and store that in the table. It won't work because your data will no longer be understandable using phpmyadmin. What about a comma separated string? well, if you were to do this: "2324335,2329786" what would happen if your user only filled in the last phone number? How would you tell which phone number was the home number and which was the mobile? The solution is called a "one to many" relationship. We create another table that will hold our phone numbers:

ID email
john anton
13 [email protected]

ID phone_type
1 home
2 mobile
3 office
4 home
5 mobile

So now, when we want the phone numbers for "john anton" we just do a query on table_client_phones where table_client_id is equal to '12'. If we wanted a specific type of phone, for example the mobile we could build a query like this: " WHERE table_client_id='12' AND phone_type='mobile' ".

Beware of Feature Creep

When you finally publish your first module, lots of feature requests will start coming from your users. Before you even consider those new features consider these points:

Are the current features stable? Does it work across diferent platforms such as servers running on linux or windows. Does it run on Internet Explorer and Firefox?. Will it run on mysql 4 and 5? Work to fix the current bugs before you start adding new code.

Will my module lose it’s focus with these new features? Your module had a clear purpose when it started, don’t lose it. Make it excelente at that one objective. Many times developers try to create a module that’s too genaralist, meaning the module might be satisfactory at many diferent jobs but not particularly good at any in particular. Does this new feature benefit the majority? This might sound mean, but, when adding new features, the ones that will benefit the majority should take priority. There’s no point wasting your valuable time on a feature that will be used by only 2 or 3 users.

Budget your time. As most developers you probably have limited time to dedicate to your xoops module(s). Your family, job or other responsabilities will always come first, so, plan for feasable goals. Release often. It’s better to make small changes and release a new version then have your users wait months on end for a new “super” version.

Test then release. Always test your module on diferent platforms before releasing it. As your module gets popular, people will volunteer to test it. Use them!

Keep a clear upgrade path. You’ve created a popular module, version 1.0. Lots of people are using it. They have invested time to personalize it to their needs and have inserted lots of info into it. So your first priority with a new version should be towards these users. They are already supporting you by using this module.

Structured Code

When creating a new module, I plan all classes on paper first, drawing diagrams of how the classes and functions should interreact with each other. This allows me to understand dependencies and how the module should work before writing a single line of code. Even a little planning for your module will save you a lot of problems latter on when writing functions.

Comment your code

The best way to comment your code is to write the comment immediately after you create or change a function or class. I know some developers write their comments at the very end of their development cycle. This in my opinion is a mistake. It’s easier to write 1 or 2 lines of comments for the function you just wrote then to have to write 100 lines of comments for functions you don’t even remember you had.

Keep users informed.

Users that install and use your module will want to know how it’s development is progressing. Even if you can’t budget time for your module, let them know. It’s better to tell your users “I can’t code for 4 to 8 weeks” then to leave them in the dark regarding module progress. Remember: your module is only usefull if people actually use it. So, keep them happy.

Searching for Answers

Search and for answers. Chances are the problem your facing has already been dealt with before. If you can't find it, don't hesitate to ask, many developers will be happy to help. I personaly search xoops using google.

Develop Locally test Remotely

If your not developing locally yet, this should be your top priority! Learn to use xampp or easyphp. These allow you to run a web server on your own machine. You access the webserver typing http://localhost into your web browser.

Part 6 - Theme Development <[Languages |Module Development Guide]> Category: Getting Started
Last modified on 2010/11/10 by Anonymous
The comments are owned by the poster. We aren't responsible for their content.