Revision history for ContributingtowebERP


Revision [2456]

Last edited on 2012-03-20 18:03:24 by PhilDaintree
Deletions:
====Legal Stuff====
In donating code to webERP, the understanding is that you as a developer are donating the code with sufficient rights for the project administrator of webERP to be able to manage the copyright of the entire webERP code base (including your modifications) on your behalf (as copyright owner). weberp.org is the trust of developers who have donated code and is the only body that can act on behalf of the entire code base. The webERP admin is the trusttee of the webERP project (or weberp.org)
Please review the [[CopyrightAgreement Developer Agreement with weberp.org]] to ensure you are happy with it before proceeding. Donation of code will be implied acceptance of this agreement.

Revision [2408]

Edited on 2012-01-21 19:29:19 by PhilDaintree
Additions:
|=|{{image alt="webERP logo" title="webERP Logo" url="images/webERPlogo.gif"}}|=|[[HomePage What Is webERP]] |=| [[WeberpFeatures webERP Features]] |=|[[WeberpFaq Documentation]]||
|=|[[WeberpSupport Support]] |=|[[http://www.weberp.org/forum Forum]] |=|{{image class="center" alt="Sourceforge Logo" title="Sourceforge Logo" url="http://sflogo.sourceforge.net/sflogo.php?group_id=70949&type=9" link="http://sourceforge.net/projects/web-erp"}} |=| [[http://sourceforge.net/project/platformdownload.php?group_id=70949&sel_platform=3757 Download]] |=| [[http://www.weberp.org/weberp/index.php Demo]] |=|[[WeberpDevelopment Development]]||
Deletions:
|=|{{image alt="webERP logo" title="webERP Logo" url="images/webERPlogo.gif"}}|=|[[HomePage What Is webERP]] |=| [[WeberpFeatures webERP Features]] |=|[[WeberpFaq FAQs]]|=|
|=|[[WeberpSupport Support]] |=| [[http://sourceforge.net/projects/web-erp Sourceforge Project Page]] |=| [[http://sourceforge.net/project/platformdownload.php?group_id=70949&sel_platform=3757 Download]] |=| [[http://www.weberp.org/weberp/index.php Demo]] |=|[[WeberpDevelopment Development]]||

Revision [2350]

Edited on 2011-12-14 22:17:47 by PhilDaintree
Additions:
In donating code to webERP, the understanding is that you as a developer are donating the code with sufficient rights for the project administrator of webERP to be able to manage the copyright of the entire webERP code base (including your modifications) on your behalf (as copyright owner). weberp.org is the trust of developers who have donated code and is the only body that can act on behalf of the entire code base. The webERP admin is the trusttee of the webERP project (or weberp.org)
Deletions:
In donating code to webERP, the understanding is that you as developer are donating the code with sufficient rights for the administrator of webERP to be able to manage the copyright of the entire webERP code base (including your modifications) on your behalf (as copyright owner). weberp.org is the trust of developers who have donated code and is the only body that can act on behalf of the entire code base. The webERP admin is the trusttee.

Revision [2347]

Edited on 2011-12-14 21:34:08 by PhilDaintree
Additions:
====Legal Stuff====
In donating code to webERP, the understanding is that you as developer are donating the code with sufficient rights for the administrator of webERP to be able to manage the copyright of the entire webERP code base (including your modifications) on your behalf (as copyright owner). weberp.org is the trust of developers who have donated code and is the only body that can act on behalf of the entire code base. The webERP admin is the trusttee.
Please review the [[CopyrightAgreement Developer Agreement with weberp.org]] to ensure you are happy with it before proceeding. Donation of code will be implied acceptance of this agreement.
Deletions:
In donating code to webERP, the understanding is that you as developer are donating the code with sufficient rights for the administrator of webERP to be able to manage the copyright of the entire webERP code base (including your modifications) on your behalf (as copyright owner). weberp.org is the trust of developers who have donated code and is the only body that can act on behalf of the entire code base. The webERP admin is the trusttee.
[[CopyrightAgreement Developer Agreement with weberp.org]]

Revision [2345]

Edited on 2011-12-14 21:17:41 by PhilDaintree
Additions:
In donating code to webERP, the understanding is that you as developer are donating the code with sufficient rights for the administrator of webERP to be able to manage the copyright of the entire webERP code base (including your modifications) on your behalf (as copyright owner). weberp.org is the trust of developers who have donated code and is the only body that can act on behalf of the entire code base. The webERP admin is the trusttee.
[[CopyrightAgreement Developer Agreement with weberp.org]]
Deletions:
[[CopyrightAgreement Developer Agreement with weberp.org (the trust of developers that created webERP)]]

Revision [2344]

Edited on 2011-12-14 21:16:12 by PhilDaintree
Additions:
[[CopyrightAgreement Developer Agreement with weberp.org (the trust of developers that created webERP)]]
Deletions:
[[CopyrightAgreement By donating code to webERP you are agreeing to the following terms applying to the donated code]]

Revision [2343]

Edited on 2011-12-14 21:14:08 by PhilDaintree
Additions:
[[CopyrightAgreement By donating code to webERP you are agreeing to the following terms applying to the donated code]]
Deletions:
[[CopyrightAgreement By donating to webERP you must agree to the following terms to apply to the donated code]]
In donating code to webERP, the understanding is that you as developer are donating the code with sufficient rights for the administrator of webERP to be able to manage the copyright of the entire webERP code base (including your modifications) on your behalf (as copyright owner). weberp.org is the trust of developers who have donated code and is the only body that can act on behalf of the entire code base. The webERP admin is the trusttee.

Revision [2341]

Edited on 2011-12-14 21:05:39 by PhilDaintree
Additions:
[[CopyrightAgreement By donating to webERP you must agree to the following terms to apply to the donated code]]
Deletions:
====Copyrights====

Revision [2340]

Edited on 2011-12-14 16:57:11 by PhilDaintree
Additions:
====Copyrights====
In donating code to webERP, the understanding is that you as developer are donating the code with sufficient rights for the administrator of webERP to be able to manage the copyright of the entire webERP code base (including your modifications) on your behalf (as copyright owner). weberp.org is the trust of developers who have donated code and is the only body that can act on behalf of the entire code base. The webERP admin is the trusttee.

Revision [2057]

Edited on 2011-03-26 23:12:38 by PhilDaintree
Additions:
The guiding principles are driven by the ProjectGoals
All code contributions must comply with the CodingConventions
Deletions:
===Getting to Know Your Way Around the Scripts===
~webERP uses a few common include files throughout that must be understood:
~includes/ConnectDB.inc - database abstraction
~includes/session.inc - initiation of session and security checking
~includes/header.inc - page headings and quick menu links
~includes/footer.inc - page footer
~includes/DateFunctions.inc - Date functions (included in session.inc)
~includes/MiscFunctions.inc - Functions for printing messages prnMsg
~includes/PDFStarter.inc - PDF report generation
~includes/SQL_CommonFunctions.inc - common functions that retrieve database info or update the database eg GetNextTransNo
~and config.php which is included by includes/session.inc and is separate from session.inc only because it requires user editing to enter the database user and password.
~Most scripts use all the first 6.
~Transactional scripts also use an includes/DefineXXXXXXClass.php script.
~PDF reporting scripts generally have an includes/PDFXXXXXXXPageHeader.inc script for the report page titles.
~Apart from these files above, most scripts are otherwise self contained so that a knowledge of these includes and the main script should be all thats needed to be confident in modifying the script.

Revision [2056]

Edited on 2011-03-26 23:10:16 by PhilDaintree
Additions:
===Getting to Know Your Way Around the Scripts===
====Procedure For Contributing====
Deletions:
====GOALS of webERP====
~1. To provide **fast, web-based, integrated "best practise" business administration software**.
~2. To be **"low footprint"** efficient and fast, with absolutely minimal network traffic.
~This is to enable dial up/low band-width connections to work with reasonable response times. This will require some compromises with the use of graphics.
~3. **Platform independence**.
~Originally the use of Javascript was avoided due to the inconsistencies between implimentations. However, subject to certain rules javascript can be used.
~~1. Any use of javascript must have another server based option as a fallback - so client machines without javascript enabled will still function.
~~2. No significant blocks of javascript to choke dialup connections (see goal 2).
~~3. The javascript used should be used consistently throughout the code.
~4. Scripts **easily readable and modifiable by a business**.
~PHP code written using control structures in a consistent way throughout. (See style guide)
~Well spaced and rigorously indented.
~Extensive commenting.
~Long descriptive variable names.
~There is also an interesting compromise between good programming practice in maximising code reuse through the use of includes, classes and common functions and in the number of separate scripts required to be understood before a developer has enough confidence to consider modifying the script. I believe that too many levels of abstraction can detract from ease of understanding the script. For this reason includes are used in preference to function calls where possible. Abstracting PHP functions to separate user-defined PHP functions is avoided. Use of OOP is restricted to those areas where large amounts of re-use are possible.
====CONTRIBUTIONS====
====CODING STANDARDS====
**Function/Class/Variable Naming**
Descriptive names should be used in preference to short variable names:
eg.
%%
$a = 3.14159;
%%
should be avoided in favour of:
%%
$Pi = 3.14159;
%%
The variable $i can be used as a counter.
As displayed above, there should be one space on either side of an equals sign used to assign the return value of a function to a variable. In the case of a block of related assignments, more space may be inserted to promote readability:
%%
$Short = foo($bar);
$LongVariable = foo($baz);
%%
Good descriptive variable names consisting of several words appended togther should have the first letter of each word capitalised.
eg.
%%
$longvariablename = 1;
%%
should be written as:
%%
$LongVariableName = 1;
%%
**HTML**
HTML keywords and tags should be in lower case to improve xhtml compatibility. This has changed since all code was written with (x)html in capitals. The code has many places currently where the html is in upper case - this will be changed over time to lower case.
HTML table cell tags in echo statements should use carriage returns to keep cells together so it is easy to see what is in each cell.
eg.
%%
echo '<table><tr><td>' . _('Label text') . ':</td><td>' . $SomeVariable . '</td><td>' . _('Some Other Label') . '</td><td align=right>' . number_format($SomeNumber,2) . '</td></tr></table>';
%%
Would be more easily digested and should be written as:
%%
echo '<table>
<tr>
<td>' . _('Label text') . ':</td>
<td>' . $SomeVariable . '</td>
<td>' . _('Some Other Label') . ':</td>
<td align=right>' . number_format($SomeNumber,2) . '</td>
</tr>
</table>';
%%
Carriage returns should be used in a similar way for printf statements.
All values of xhtml properties should be between double quotes e.g. <input type="text" name="InputBox" value="Default">
This goes hand in hand with using single quotes for all echo statments see below.
**Label Strings and Multi-Language**
Since webERP is a multi-language system it is important not to compromise this capability by having labels in your scripts that are not enclosed in the gettext function eg.
%%
echo 'Enter the quantity:<input type="text" name="Quantity">';
%%
should be written as:
%%
echo _('Enter the quantity') . ':<input type="text" name="Quantity">';
%%
note that there should be no trailing spaces or punctuation on the string to be translated inside the _() function call
**PHP Variables**
The PHP variable arrays $_POST, $_GET, $_SERVER, $_SESSION provide context about where a variable comes from - many developers are tempted to abbreviate:
%%
$StartingCustomer = $_POST['StartingCustomer'];
%%
or worse:
%%
$s = $_POST['StartingCustomer'];
%%
This should be avoided in favour of using $_POST['StartAtCustomer'] everywhere it is required so the reader can see where the variable comes from.
However, variables which could come from either a $_GET or a $_POST and/or a $_SESSION may be assigned as in the first example since there is no value in the context.
**Quotation Marks**
Notice that single quotes (') are used in preference to double quotes (") - there is additional overhead for php in parsing data within double quotes. They should only be used where absolutely necessary and concatenation of variables is preferred to having variables inside double quotes.
eg.
%%
echo "Some text with a $Variable";
%%
would be better written as:
%%
echo 'Some text with a ' . $Variable;
%%
to reduce the parsing job required of the web-server.
Arrays and super global arrays should always have the element name within single quotes not doubles
eg.
%%
$_POST["FormVariableName"]
%%
should be written as:
%%
$_POST['FormVariableName']
%%
**Control Structures**
All control structures (these include if, for, while, switch) must always use "Kernighan and Richie" style statement blocks.
You are strongly encouraged to always use curly braces even in situations where they are technically optional. Having them increases readability and decreases the likelihood of logic errors being introduced when new lines are added.
eg.
%%
if ($VariableName == true)
echo _('Variable was true');
%%
whilst legal PHP syntax, this should be avoided in favour of the following syntax:
%%
if ($VariableName == true) {
echo _('Variable was true');
}
%%
Parenthesis should open on the same line (after a space) as the initiating control structure and close the statement block at the same level of indenting as the initiating line.
Else statements should be on the same line as the closing statment block from the preceeding elseif or if statement eg.
%%
if ($VariableName == true) {
echo "Variable was true";
} else {
echo "Variable was false";
} /*end else $VariableName was false*/
%%
This is the only time there should be anything other than a comment on the closing curly brace line. Comments on a closing curly brace line where the block has been quite a few lines of code are encouraged to show the control structure to which they related.
Whenever a statement block is used code within the block should be one tab indented.
Function defintions should follow the same conventions.
It is recommended that you break lines at approximately 75-85 characters.
**Spacing**
Where readability is improved lines of code should be separated by a line
**Comments**
C style comment blocks in the format:
%%
/* comments in here */
%%
are preferred. But all comments gratefully received!
All scripts should have a comment in the first few lines with the script revision number in it if the following comment is pasted into it the CVS automatically updates the revision number.
%%
/* $Revision: 1.7 $ */
%%
**Messages**
The standard message function prnMsg should always be used for all messages to be echo'ed to the screen - this function has two parameters - the string to display and the message type , 'error', 'warn', 'success', 'info' - there is a third optional paramter which is a prefix heading for the message.
**Database Function Calls**
There should never be any database specific calls in scripts other than includes/ConnectDB_XXXX.inc
Where XXXX is the abbreviation for the RDBMS the abstraction code refers to.
All database calls should be performed by calling the abstraction functions in those scripts. (currently only includes/ConnectDB_mysql.inc exists - 2007 - ConnectDB_postgres.inc was depreciated but could easily be revived if we stick with this convention)
**SQL**
Should be as ANSI compliant as possible. Using SQL which is particular to a specific RDBMS is to be avoided in favour of the ANSI equivalent.
The webERP goal of providing "low footprint" efficient system - requires careful thought. The number of "round trips" must be minimised - never go off to the database to get data that could have been got in a prior query. This is inefficient design and to be avoided.
Table and field names should alway use lower case and should be descriptive of the data they hold. e.g. Field names such as "nw" should be avoided in favour of "netweight"
There is a temptation for some developers to try to reuse tables for other purposes by adding a field or two. If the data is not common accross all rows then it probably belongs in a separate table. There is no overhead to having separate tables, but there is a whole table full of waste fields where only a few records need the field.
SQL statements should be on several lines for easier reading eg.
%%
$sql = "select transno, trandate, debtortrans.debtorno, branchcode, reference, invtext, order_, rate, ovamount+ovgst+ovfreight+ovdiscount as totalamt, currcode from debtortrans inner join debtorsmaster on debtortrans.debtorno=debtorsmaster.debtorno where ";
%%
is harder to read than:
%%
$sql = "SELECT transno,
trandate,
debtortrans.debtorno,
branchcode, reference,
invtext,
order_,
rate,
ovamount+ovgst+ovfreight+ovdiscount AS totalamt,
currcode
FROM
debtortrans INNER JOIN debtorsmaster
ON debtortrans.debtorno=debtorsmaster.debtorno
WHERE ";
%%
SQL kywords should be capitalised as above eg. SELECT, CASE, FROM, WHERE, GROUP BY, ORDER BY AS INNER JOIN etc.
Line breaks after every comma and on major SQL reserved words as above.
SQL queries should always "escape" strings using the function "DB_escape_string", integer values with "intval" function and floating point numbers with "floatval" function, that is to prevent SQL injection attacks.
Quoting SQL variables - variables incorporated into SQL strings need to be inside quotes so that the variable cannot be used by a hacker to send spurious SQL to retrieve private data.
**Constants**
Constants should always be all-uppercase, with underscores to separate words. Where it is possible to use a literal instead of a constant then the literal is preferred.
**PHP Code Tags**
Always use <?php ?> to delimit PHP code, not the <? ?> shorthand. This is the most portable way to include PHP code on differing operating systems and setups.

Revision [2047]

Edited on 2011-03-25 20:02:47 by PhilDaintree
Additions:
|=|[[WeberpSupport Support]] |=| [[http://sourceforge.net/projects/web-erp Sourceforge Project Page]] |=| [[http://sourceforge.net/project/platformdownload.php?group_id=70949&sel_platform=3757 Download]] |=| [[http://www.weberp.org/weberp/index.php Demo]] |=|[[WeberpDevelopment Development]]||
Deletions:
|=|[[WeberpSupport Support]] |=| [[http://sourceforge.net/projects/web-erp Sourceforge Project Page]] |=| [[http://sourceforge.net/project/platformdownload.php?group_id=70949&sel_platform=3757 Download]] |=| [[http://www.weberp.org/weberp/index.php Demo]] |=|[[http://www.weberp.org/weberp/doc/Manual/ManualContents.php Manual]] |=|[[WeberpDevelopment Development]]||

Revision [1988]

Edited on 2011-02-20 03:14:08 by PhilDaintree
Additions:
echo 'Enter the quantity:<input type="text" name="Quantity">';
echo _('Enter the quantity') . ':<input type="text" name="Quantity">';
Deletions:
echo 'Enter the quantity:<INPUT TYPE=TEXT NAME=Quantity>';
echo _('Enter the quantity') . ':<INPUT TYPE=TEXT NAME=Quantity>';

Revision [1977]

Edited on 2011-01-11 19:00:17 by PhilDaintree
Additions:
The webERP goal of providing "low footprint" efficient system - requires careful thought. The number of "round trips" must be minimised - never go off to the database to get data that could have been got in a prior query. This is inefficient design and to be avoided.
Table and field names should alway use lower case and should be descriptive of the data they hold. e.g. Field names such as "nw" should be avoided in favour of "netweight"
There is a temptation for some developers to try to reuse tables for other purposes by adding a field or two. If the data is not common accross all rows then it probably belongs in a separate table. There is no overhead to having separate tables, but there is a whole table full of waste fields where only a few records need the field.
Quoting SQL variables - variables incorporated into SQL strings need to be inside quotes so that the variable cannot be used by a hacker to send spurious SQL to retrieve private data.
Constants should always be all-uppercase, with underscores to separate words. Where it is possible to use a literal instead of a constant then the literal is preferred.
Deletions:
Table and field names should alway use lower case.
Constants should always be all-uppercase, with underscores to separate words.

Revision [1894]

Edited on 2010-09-10 18:37:26 by PhilDaintree
Additions:
|=|{{image alt="webERP logo" title="webERP Logo" url="images/webERPlogo.gif"}}|=|[[HomePage What Is webERP]] |=| [[WeberpFeatures webERP Features]] |=|[[WeberpFaq FAQs]]|=|
Deletions:
|=|{{image alt="webERP logo" title="webERP Logo" url="images/webERPlogo.gif"}}|=|[[HomePage What Is webERP]] |=| [[WeberpFeatures webERP Features]] |=|[[WeberpFaq FAQs]]|=|[[WeberpSupport Support]]||

Revision [1893]

Edited on 2010-09-10 18:36:48 by PhilDaintree
Additions:
|=|{{image alt="webERP logo" title="webERP Logo" url="images/webERPlogo.gif"}}|=|[[HomePage What Is webERP]] |=| [[WeberpFeatures webERP Features]] |=|[[WeberpFaq FAQs]]|=|[[WeberpSupport Support]]||
|=|[[WeberpSupport Support]] |=| [[http://sourceforge.net/projects/web-erp Sourceforge Project Page]] |=| [[http://sourceforge.net/project/platformdownload.php?group_id=70949&sel_platform=3757 Download]] |=| [[http://www.weberp.org/weberp/index.php Demo]] |=|[[http://www.weberp.org/weberp/doc/Manual/ManualContents.php Manual]] |=|[[WeberpDevelopment Development]]||
Deletions:
|=|{{image alt="webERP logo" title="webERP Logo" url="images/webERPlogo.gif"}}|=|[[HomePage What Is webERP]] |=| [[WeberpFeatures webERP Features]] |=|[[WeberpFaq FAQs]]|=|[[WeberpSupport Support]] |=| [[http://sourceforge.net/projects/web-erp Sourceforge Project Page]] |=| [[http://sourceforge.net/project/platformdownload.php?group_id=70949&sel_platform=3757 Download]] ||
|| |=|[[http://www.weberp.org/weberp/index.php Demo]] |=|[[http://www.weberp.org/weberp/doc/Manual/ManualContents.php Manual]] |=|[[WeberpDevelopment Development]]||

Revision [1891]

Edited on 2010-09-10 18:34:19 by PhilDaintree
Additions:
|| |=|[[http://www.weberp.org/weberp/index.php Demo]] |=|[[http://www.weberp.org/weberp/doc/Manual/ManualContents.php Manual]] |=|[[WeberpDevelopment Development]]||
Deletions:
|| |[[http://www.weberp.org/weberp/index.php Demo]] |=|[[http://www.weberp.org/weberp/doc/Manual/ManualContents.php Manual]] |=|[[WeberpDevelopment Development]]||

Revision [1890]

Edited on 2010-09-10 18:33:44 by PhilDaintree
Additions:
|| |[[http://www.weberp.org/weberp/index.php Demo]] |=|[[http://www.weberp.org/weberp/doc/Manual/ManualContents.php Manual]] |=|[[WeberpDevelopment Development]]||
Deletions:
||[[http://www.weberp.org/weberp/index.php Demo]] |=|[[http://www.weberp.org/weberp/doc/Manual/ManualContents.php Manual]] |=|[[WeberpDevelopment Development]]||

Revision [1889]

Edited on 2010-09-10 18:32:55 by PhilDaintree
Additions:
|=|{{image alt="webERP logo" title="webERP Logo" url="images/webERPlogo.gif"}}|=|[[HomePage What Is webERP]] |=| [[WeberpFeatures webERP Features]] |=|[[WeberpFaq FAQs]]|=|[[WeberpSupport Support]] |=| [[http://sourceforge.net/projects/web-erp Sourceforge Project Page]] |=| [[http://sourceforge.net/project/platformdownload.php?group_id=70949&sel_platform=3757 Download]] ||
||[[http://www.weberp.org/weberp/index.php Demo]] |=|[[http://www.weberp.org/weberp/doc/Manual/ManualContents.php Manual]] |=|[[WeberpDevelopment Development]]||
Inform the list of your proposed developments and discuss the approach to be used. There are some knowledgeable people on the list and they can contribute ideas if you let them. This is also good to avoid overlapping effort or combine efforts in working on different elements of the same project.
2. Obtain the latest development scripts from SVN - see sourceforge instructions for anonymous SVN checkout the SVN files initially then updates daily - this only downloads any modified scripts, or update immediately before commencing any development.
''IMPORTANT: Only do development work on the most recent scripts from SVN and update your copy of the SVN regularly. Instructions on the use of SVN at sourceforge can be found at the following URL:''
http://sourceforge.net/projects/web-erp/develop
3. This point is relevant only for developers that do not have SVN write access. After any modifications to the scripts - email (only) the modified scripts (and ideally a diff file between the latest SVN scripts and your updated scripts) to submissions@weberp.org within 12 hours of your last update from SVN. The project admin will have to digest the modifications and ensure the coding style is consistent, test the scripts and consider the implications of the modifications in achieving the goals noted above. Plenty of narrative explaining the modifications should be posted in the developers list so all can consider the implications. They will be committed to SVN as soon as possible after receipt and testing.
5. All submissions of modifications or additions should be accompanied by a plain text change.log file describing the changes to each script. This explains to everyone the nature of the changes made. Each entry in the change log should state the developer name and date of the change/addition. This file will be appended to the doc/change.log when the files are committed to SVN.
Deletions:
|=|{{image alt="webERP logo" title="webERP Logo" url="images/webERPlogo.gif"}}|=|[[HomePage What Is webERP]] |=| [[WeberpFeatures webERP Features]] |=|[[WeberpFaq FAQs]]|=|[[WeberpSupport Support]] |=| [[http://sourceforge.net/projects/web-erp Sourceforge Project Page]] |=| [[http://sourceforge.net/project/platformdownload.php?group_id=70949&sel_platform=3757 Download]] |=| [[http://www.weberp.org/weberp/index.php Demo]] |=|[[http://www.weberp.org/weberp/doc/Manual/ManualContents.php Manual]] |=|[[WeberpDevelopment Development]]||
Inform the list of your proposed developments and discuss the approach to be used. There are some knowlegable people on the list and they can contribute ideas if you let them. This is also good to avoid overlapping effort or combine efforts in working on different elements of the same project.
2. Obtain the latest development scripts from CVS - see sourceforge instructions for anonymous cvs checkout the CVS files intially then updates daily - this only downloads any modified scripts, or update immediately before commencing any development.
''IMPORTANT: Only do development work on the most recent scripts from CVS and update your copy of the CVS regularly. Instructions on the use of CVS at sourceforge can be found at the following URL:''
http://apps.sourceforge.net/trac/sourceforge/wiki/CVS
3. This point is relevant only for developers that do not have CVS write access. After any modifications to the scripts - email (only) the modified scripts (and ideally a diff file between the latest CVS scripts and your updated scripts) to submissions@weberp.org within 12 hours of your last update from CVS. The project admin will have to digest the modifications and ensure the coding style is consistent, test the scripts and consider the implications of the modifications in acheiving the goals noted above. Plenty of narrative explaining the modifications should be posted in the developers list so all can consider the implications. They will be committed to CVS as soon as possible after receipt and testing.
5. All submissions of modifications or additions should be accompanied by a plain text change.log file describing the changes to each script. This explains to everyone the nature of the changes made. Each entry in the change log should state the developer name and date of the change/addition. This file will be appended to the doc/change.log when the files are committed to CVS.

Revision [1842]

Edited on 2010-07-08 02:34:55 by PhilDaintree
Additions:
echo _('Variable was true');
echo _('Variable was true');

Revision [1437]

Edited on 2009-04-06 16:40:14 by PhilDaintree
Additions:
http://apps.sourceforge.net/trac/sourceforge/wiki/CVS
Deletions:
http://sourceforge.net/docman/display_doc.php?group_id=1&docid=29894

Revision [1436]

Edited on 2009-04-02 21:37:45 by PhilDaintree
Additions:
~Originally the use of Javascript was avoided due to the inconsistencies between implimentations. However, subject to certain rules javascript can be used.
~~1. Any use of javascript must have another server based option as a fallback - so client machines without javascript enabled will still function.
~~2. No significant blocks of javascript to choke dialup connections (see goal 2).
~~3. The javascript used should be used consistently throughout the code.
Deletions:
~Use of Javascript should be avoided due to the inconsistencies between implimentations. By using only PHP on the server and keeping processing there, anomalies in operation between client's with different software can be avoided. Any use of javascript must have another server based option as a fallback. No significant blocks of javascript to choke dialup connections (see goal 2).

Revision [1374]

Edited on 2009-02-04 21:03:52 by PhilDaintree
Additions:
All values of xhtml properties should be between double quotes e.g. <input type="text" name="InputBox" value="Default">
This goes hand in hand with using single quotes for all echo statments see below.

Revision [1030]

Edited on 2008-01-03 19:25:05 by PhilDaintree
Additions:
~There is also an interesting compromise between good programming practice in maximising code reuse through the use of includes, classes and common functions and in the number of separate scripts required to be understood before a developer has enough confidence to consider modifying the script. I believe that too many levels of abstraction can detract from ease of understanding the script. For this reason includes are used in preference to function calls where possible. Abstracting PHP functions to separate user-defined PHP functions is avoided. Use of OOP is restricted to those areas where large amounts of re-use are possible.
~- A relevant demonstration of your technical knowledge that helps another user/developer or the project - is always appreciated.
''IMPORTANT: Only do development work on the most recent scripts from CVS and update your copy of the CVS regularly. Instructions on the use of CVS at sourceforge can be found at the following URL:''
Deletions:
~There is also an interesting compromise between good programming practise in maximising code reuse through the use of includes, classes and common functions and in the number of separate scripts required to be understood before a developer has enough confidence to consider modifying the script. I believe that too many levels of abstraction can detract from ease of understanding the script. For this reason includes are used in preference to function calls where possible. Abstracting PHP functions to separate userdefined PHP functions is avoided. Use of OOP is restricted to those areas where large amounts of re-use are possible.
~- A relevant demonstration of your technical knowledge that helps another user/developer or the project - is always appreciated. Actions speak much louder than words.
IMPORTANT: Only do development work on the most recent scripts from CVS and update your copy of the CVS regularly. Instructions on the use of CVS at sourceforge can be found at the following URL:

Revision [1029]

Edited on 2008-01-03 19:23:16 by PhilDaintree
Additions:
~- Polite and cordial exchanges with good humour get the best responses.
~- Please do not respond to an email if you are angry at what someone wrote. Email stays written long after you have calmed down and will embarrass you later.
~- Email can be a little impersonal and whilst the information published on the list is very public we do encourage the use of first names at least in list communications.
~- Commercial arrangements with other list members should be kept off list.
~- Advertising of services should be limited to web-site information at the end of emails.
~- A relevant demonstration of your technical knowledge that helps another user/developer or the project - is always appreciated. Actions speak much louder than words.
Deletions:
~> Polite and cordial exchanges with good humour get the best responses.
~> Please do not respond to an email if you are angry at what someone wrote. Email stays written long after you have calmed down and will embarrass you later.
~> Email can be a little impersonal and whilst the information published on the list is very public we do encourage the use of first names at least in list communications.
~> Commercial arrangements with other list members should be kept off list.
~> Advertising of services should be limited to web-site information at the end of emails.
~> Don't write telling us how good you are. However, a relevant demonstration of your technical knowledge that helps another user/developer or the project - is always appreciated. Actions speak much louder than words.

Revision [1028]

Edited on 2008-01-03 19:06:31 by PhilDaintree
Additions:
SQL queries should always "escape" strings using the function "DB_escape_string", integer values with "intval" function and floating point numbers with "floatval" function, that is to prevent SQL injection attacks.

Revision [941]

Edited on 2007-12-01 17:40:33 by PhilDaintree
Additions:
~> Don't write telling us how good you are. However, a relevant demonstration of your technical knowledge that helps another user/developer or the project - is always appreciated. Actions speak much louder than words.

Revision [940]

Edited on 2007-12-01 17:33:37 by PhilDaintree
Additions:
~> Polite and cordial exchanges with good humour get the best responses.
~> Please do not respond to an email if you are angry at what someone wrote. Email stays written long after you have calmed down and will embarrass you later.
~> Email can be a little impersonal and whilst the information published on the list is very public we do encourage the use of first names at least in list communications.
~> Commercial arrangements with other list members should be kept off list.
~> Advertising of services should be limited to web-site information at the end of emails.
Deletions:
~Polite and cordial exchanges with good humour get the best responses.
~Please do not respond to an email if you are angry at what someone wrote. Email stays written long after you have calmed down and will embarrass you later.
~Email can be a little impersonal and whilst the information published on the list is very public we do encourage the use of first names at least in list communications.
~Commercial arrangements with other list members should be kept off list.
~Advertising of services should be limited to web-site information at the end of emails.

Revision [939]

Edited on 2007-12-01 17:33:05 by PhilDaintree
Additions:
A few points to remember about the mailing list:
~Polite and cordial exchanges with good humour get the best responses.
~Please do not respond to an email if you are angry at what someone wrote. Email stays written long after you have calmed down and will embarrass you later.
~Email can be a little impersonal and whilst the information published on the list is very public we do encourage the use of first names at least in list communications.
~Commercial arrangements with other list members should be kept off list.
~Advertising of services should be limited to web-site information at the end of emails.

Revision [936]

Edited on 2007-12-01 17:23:54 by PhilDaintree
Additions:
|=|{{image alt="webERP logo" title="webERP Logo" url="images/webERPlogo.gif"}}|=|[[HomePage What Is webERP]] |=| [[WeberpFeatures webERP Features]] |=|[[WeberpFaq FAQs]]|=|[[WeberpSupport Support]] |=| [[http://sourceforge.net/projects/web-erp Sourceforge Project Page]] |=| [[http://sourceforge.net/project/platformdownload.php?group_id=70949&sel_platform=3757 Download]] |=| [[http://www.weberp.org/weberp/index.php Demo]] |=|[[http://www.weberp.org/weberp/doc/Manual/ManualContents.php Manual]] |=|[[WeberpDevelopment Development]]||
Deletions:
|=|{{image alt="webERP logo" title="webERP Logo" url="images/webERPlogo.gif"}}|=|[[WhatisWeberp What Is webERP]] |=| [[WeberpFeatures webERP Features]] |=|[[WeberpFaq FAQs]]|=|[[WeberpSupport Support]] |=| [[http://sourceforge.net/projects/web-erp Sourceforge Project Page]] |=| [[http://sourceforge.net/project/platformdownload.php?group_id=70949&sel_platform=3757 Download]] |=| [[http://www.weberp.org/weberp/index.php Demo]] |=|[[http://www.weberp.org/weberp/doc/Manual/ManualContents.php Manual]] |=|[[WeberpDevelopment Development]]||

Revision [916]

Edited on 2007-12-01 14:05:30 by PhilDaintree
Additions:
|=|{{image alt="webERP logo" title="webERP Logo" url="images/webERPlogo.gif"}}|=|[[WhatisWeberp What Is webERP]] |=| [[WeberpFeatures webERP Features]] |=|[[WeberpFaq FAQs]]|=|[[WeberpSupport Support]] |=| [[http://sourceforge.net/projects/web-erp Sourceforge Project Page]] |=| [[http://sourceforge.net/project/platformdownload.php?group_id=70949&sel_platform=3757 Download]] |=| [[http://www.weberp.org/weberp/index.php Demo]] |=|[[http://www.weberp.org/weberp/doc/Manual/ManualContents.php Manual]] |=|[[WeberpDevelopment Development]]||
----

Revision [598]

Edited on 2007-10-13 23:34:59 by PhilDaintree
Additions:
~This is to enable dial up/low band-width connections to work with reasonable response times. This will require some compromises with the use of graphics.
Deletions:
~This is to enable dial up/low band-width connections to work with reasonable
response times. This will require some compromises with the use of graphics.

Revision [302]

Edited on 2007-10-05 12:21:14 by PhilDaintree
Additions:
Should be as ANSI compliant as possible. Using SQL which is particular to a specific RDBMS is to be avoided in favour of the ANSI equivalent.
Table and field names should alway use lower case.
Deletions:
Should be as ANSI compliant as possible. Table and field names should alway use lower case.

Revision [301]

Edited on 2007-10-05 12:19:45 by PhilDaintree
Additions:
There should never be any database specific calls in scripts other than includes/ConnectDB_XXXX.inc
Where XXXX is the abbreviation for the RDBMS the abstraction code refers to.
All database calls should be performed by calling the abstraction functions in those scripts. (currently only includes/ConnectDB_mysql.inc exists - 2007 - ConnectDB_postgres.inc was depreciated but could easily be revived if we stick with this convention)
Deletions:
There should never be any database specific calls in scripts other than includes/ConnectDB.inc
All database calls should be performed by calling the abstraction functions in that script.

Revision [300]

Edited on 2007-10-05 12:16:22 by PhilDaintree

No Differences

Revision [299]

Edited on 2007-10-05 12:13:55 by PhilDaintree

No Differences

Revision [298]

Edited on 2007-10-05 12:10:35 by PhilDaintree
Additions:
=====Contributing to webERP=====
~1. To provide **fast, web-based, integrated "best practise" business administration software**.
~2. To be **"low footprint"** efficient and fast, with absolutely minimal network traffic.
~This is to enable dial up/low band-width connections to work with reasonable
~3. **Platform independence**.
~Use of Javascript should be avoided due to the inconsistencies between implimentations. By using only PHP on the server and keeping processing there, anomalies in operation between client's with different software can be avoided. Any use of javascript must have another server based option as a fallback. No significant blocks of javascript to choke dialup connections (see goal 2).
~4. Scripts **easily readable and modifiable by a business**.
~PHP code written using control structures in a consistent way throughout. (See style guide)
~Well spaced and rigorously indented.
~Extensive commenting.
~Long descriptive variable names.
~There is also an interesting compromise between good programming practise in maximising code reuse through the use of includes, classes and common functions and in the number of separate scripts required to be understood before a developer has enough confidence to consider modifying the script. I believe that too many levels of abstraction can detract from ease of understanding the script. For this reason includes are used in preference to function calls where possible. Abstracting PHP functions to separate userdefined PHP functions is avoided. Use of OOP is restricted to those areas where large amounts of re-use are possible.
~webERP uses a few common include files throughout that must be understood:
~includes/ConnectDB.inc - database abstraction
~includes/session.inc - initiation of session and security checking
~includes/header.inc - page headings and quick menu links
~includes/footer.inc - page footer
~includes/DateFunctions.inc - Date functions (included in session.inc)
~includes/MiscFunctions.inc - Functions for printing messages prnMsg
~includes/PDFStarter.inc - PDF report generation
~includes/SQL_CommonFunctions.inc - common functions that retrieve database info or update the database eg GetNextTransNo
~and config.php which is included by includes/session.inc and is separate from session.inc only because it requires user editing to enter the database user and password.
~Most scripts use all the first 6.
~Transactional scripts also use an includes/DefineXXXXXXClass.php script.
~PDF reporting scripts generally have an includes/PDFXXXXXXXPageHeader.inc script for the report page titles.
~Apart from these files above, most scripts are otherwise self contained so that a knowledge of these includes and the main script should be all thats needed to be confident in modifying the script.
</table>';
Deletions:
elortal
%%(noautolinks)
===Contributing to webERP===
1. To provide **fast, web-based, integrated "best practise" business administration software**.
2. To be **"low footprint"** efficient and fast, with absolutely minimal network traffic.
This is to enable dial up/low band-width connections to work with reasonable
3. **Platform independence**.
Use of Javascript should be avoided due to the inconsistencies between implimentations. By using only PHP on the server and keeping processing there, anomalies in operation between client's with different software can be avoided. Any use of javascript must have another server based option as a fallback. No significant blocks of javascript to choke dialup connections (see goal 2).
4. Scripts **easily readable and modifiable by a business**.
PHP code written using control structures in a consistent way throughout. (See style guide)
Well spaced and rigorously indented.
Extensive commenting.
Long descriptive variable names.
There is also an interesting compromise between good programming practise in maximising code reuse through the use of includes, classes and common functions and in the number of separate scripts required to be understood before a developer has enough confidence to consider modifying the script. I believe that too many levels of abstraction can detract from ease of understanding the script. For this reason includes are used in preference to function calls where possible. Abstracting PHP functions to separate userdefined PHP functions is avoided. Use of OOP is restricted to those areas where large amounts of re-use are possible.
webERP uses a few common include files throughout that must be understood:
includes/ConnectDB.inc - database abstraction
includes/session.inc - initiation of session and security checking
includes/header.inc - page headings and quick menu links
includes/footer.inc - page footer
includes/DateFunctions.inc - Date functions (included in session.inc)
includes/MiscFunctions.inc - Functions for printing messages prnMsg
includes/PDFStarter.inc - PDF report generation
includes/SQL_CommonFunctions.inc - common functions that retrieve database info or update the database eg GetNextTransNo
and config.php which is included by includes/session.inc and is separate from session.inc only because it requires user editing to enter the database user and password.
Most scripts use all the first 6.
Transactional scripts also use an includes/DefineXXXXXXClass.php script.
PDF reporting scripts generally have an includes/PDFXXXXXXXPageHeader.inc script for the report page titles.
Apart from these files above, most scripts are otherwise self contained so that a knowledge of these includes and the main script should be all thats needed to be confident in modifying the script.
</table>';

Revision [146]

The oldest known version of this page was created on 2007-09-28 07:47:30 by PhilDaintree
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki