webERP: Contributing to webERP

Revision [1437]

Last 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.
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:

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:

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.
';

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.
';

Revision [146]

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