Boonex Market Etiquette

this page is under collaborative construction

1) CSS coding way:

Fonts, styles, colors, borders, buttons etc.. we have to use the default Dolphin classes. Many modules we made are using our own CSS classes. This will comport issues in the custom templates of the customers and it will always require an additional work on them. It always happens because every customer has or will have a custom template. So we need to use the Dolphin general CSS classes to make sure we will not have any incompatibility with the custom templates.

Any other necessary class the CSS of the module will need to use, should not be coded in a way that will interfer with the general Dolphin CSS classes. It includes, but not exclusively: font colors, font sizes, font styles, borders, background colors-images, thumbnails modifications and in general any other attribute that will make a change in the custom template.

2) PHP Coding way related to the Template system:

-When creating new pages, in the Main section only the Content should be modded.

-No changes are allowed on the designbox, only what is inside the content of the designbox should be modded.

-The HTML code and the CSS code should not be Ever included in the PHP code. The HTML code and the CSS code should be written in the specific files.

-We should not make floating Elements without having them placed in a specific container. Only lightboxes and similars are allowed to float wherever on the template.

-When creating inputs, submit buttons and similars we should use the default Dolphin ones and not using our own classes with different backgrounds-images.

-Modification on the scripts files should always be made inside the custom template and not in the base folder.

-The customer should be always noticed of any change we have made on a Dolphin Default file. We will have to create a folder inside the server of the customer with a .TXT file where each of us should at least write where a change has been made and why.

-Any of the above requirements are also mandatory for the modifications on any Boonex Module.

3) PHP coding way:

-No modifications of the Dolphin Default files are permitted. If any change on the default files is necessary then this change should be properly written in the .TXT file as explained above.

-Every module should be coded in the way Boonex requires.

-Installation of each module should be easy and should not include more than 1-2 steps for the customer when possible.

-Insertions, Alterations and similars should be placed in the SQL file and should run only by the Dolphin Admin Panel.

-PHP code should be written in a way that will not eat all the server resources. Each PHP code should be as much smarter as possible, the same applies for mySQL queries, insertions, alterations and similars.

-Each module should always include the english language file. Each module should not have any missing language string. Also the languages strings should be written in a way that the customer will be able to easily modify them.

The above ones are only the very basic requirements. Every developer/designer interested in being part of this Development Etiquette should provide other requirements, that would be globally reviewed and then accepted.

4) Licensing: -Licenses should be provided in a simple way. The customer should be able to understand how and when is necessary to get a license for our module.

-The license system we are adopting must run on a secure server with at least 2 GB of RAM.

-We must provide to the user the opportunity to change the domain associated to the license. Licenses can be for One Domain. But if the customer requires to change a specific domain name with another one we have to give this oppurtunity. We cannot use such restriction.

-Continuos remote checks are not allowed as well.

5) Encryption:

Encryption is possible to protect our own work.

• CSS, HTML, Javascript, jQuery code should not be encrypted, ever.

• If possible only the Core of the module should be encrypted and not the entire code, in order to give the possibility to the customer to change the code where needed, after a proper communication to you, if the module is commercial.

6) Support:

-We should be available at least 5 days of the week

-We should be able to provide answers by mail or PM at least every 24 hours

-We should always open a specifc support Forum in the proper section for EACH module we sell on the market

-Updates or Upgrades should be released for free for each customer when already has a previous version of the module/template. This also applies for new versions of Dolphin. If the module you are selling is the same for Different versions of Dolphin, then the customer can claim it for free. Updating the module for a new version of Dolphin is required if even only one customer (that has already bought your module) will require that. (Edited : 25/06/2011)

-If we are going to not be available for a certain period, this should be well written in your Boonex Profile. We reject unsupported profiles for over 2 weeks.

7) Branding:

Logo Branding is permitted only for non-commercial scripts

-No Logos, Names, Links should be in the code if you are selling a commercial product. This applies both on front-end and back-end.

-If for any reason you must include your Brand, that must be specified in the Market post IN BOLD

-The name of the module that will appear in the back-end and in the URL should not contain our Name or TradeMark?. The Name of the module should not include in any way our Brand.

-Modules should be listed under the "Modules" tab in the backend. If for any reason we have to use another tab for our module, that should not ever include our Brand.

-The name of the module should be "generic". We can give a name to the module on the Market Post. We cannot do the same in the Module itself. This is also to avoid a "Way for Branding" in the customer admin panel or URL.

8) Product description:

The description of the product must be easy to understand. We should include any possible detail. Also a Chagelog is required when we are providing different versions of the same module. In the description we should include IN BOLD anything that differs from these requirements. We should also explain why there are differences. Also we should make a notice here if you are making a module that is different for any reason from these requirements. This should not happen, only if this is necessary, and that should be properly noticed and written, or we will be immediately rejected!

-Every developer should have a Demo site where all the modules can be properly tested.