Menu
▾
▴
web-erp-developers
|
From: Jesse P. <je...@st...> - 2004-09-21 01:21:47
|
eh, hem... http://pecl.php.net/package-search.php?pkg_name=pdo&bool=AND&submit=Search http://pecl.php.net/package/PDO_MYSQL http://pecl.php.net/package/PDO_PGSQL skaill wrote: >Good stuff. I wonder if and when their plan is for mysql and postgresql. >Sounds like they're moving pretty fast. > >----- Original Message ----- >From: "Stins, Dick" <DR...@Zi...> >To: <web...@li...> >Sent: Monday, September 20, 2004 5:52 PM >Subject: Re: EGS/Postgresql - Was Re: [Web-erp-developers] Cheap > > > > >>Hoi, >> >>I think you all wouldn't miss this article: >> >> >> >> >http://www.oracle.com/technology/pub/articles/php_experts/otn_pdo_oracle5.ht > > >>ml >> >>With best regards, >> >>Dick Stins >> >> |
|
From: skaill <sk...@ro...> - 2004-09-21 12:46:44
|
Awesome. It's in alpha now but I'll bet they will be stable soon. ----- Original Message ----- From: "Jesse Peterson" <je...@st...> To: <web...@li...> Sent: Monday, September 20, 2004 9:21 PM Subject: Re: EGS/Postgresql - Was Re: [Web-erp-developers] Cheap > eh, hem... > http://pecl.php.net/package-search.php?pkg_name=pdo&bool=AND&submit=Search > http://pecl.php.net/package/PDO_MYSQL > http://pecl.php.net/package/PDO_PGSQL > > skaill wrote: > > >Good stuff. I wonder if and when their plan is for mysql and postgresql. > >Sounds like they're moving pretty fast. > > > >----- Original Message ----- > >From: "Stins, Dick" <DR...@Zi...> > >To: <web...@li...> > >Sent: Monday, September 20, 2004 5:52 PM > >Subject: Re: EGS/Postgresql - Was Re: [Web-erp-developers] Cheap > > > > > > > > > >>Hoi, > >> > >>I think you all wouldn't miss this article: > >> > >> > >> > >> > >http://www.oracle.com/technology/pub/articles/php_experts/otn_pdo_oracle5.h t > > > > > >>ml > >> > >>With best regards, > >> > >>Dick Stins > >> > >> > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > Project Admins to receive an Apple iPod Mini FREE for your judgement on > who ports your project to Linux PPC the best. Sponsored by IBM. > Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers |
|
From: Stins, D. <DR...@Zi...> - 2004-09-20 20:25:19
|
Yes, any technical database layer is not that interesting, although it's always handy when it is not too much work to move to another database engine, but I see no need to change from mysql to another database engine at the moment. Solution like pear:db seems only to slow things down and hide the real code and creates more trouble when in pear:DB (or any other wrapper) are some bugs. When I talk about a database layer, it's functional. Like you have a function to delete a customer. This functions checks all business constraints before deleting: - are there any transaction related? - are there any open orders? - are there any companies related to this customer? - is it an active customer? - is it bankrupt? - ... When one or more checks fail, then the function returns an understandable error and refuses to continue. When you have this function, then you are able to call it from any script, like a delete script, or a batch script which deletes lot's of customers, or a webservices which tries to process delete the customer. The same for a create customer function. When all attributes (credit check, address, chamber of commerce number, tax number, telephone number, bankaccount number, ...) of the customer are properly set, then the status of this customer will be valid. When you have one set of functions/methods to set all these items, then you again can reuse this code (CLASS METHODS) of lot's of places. When you have a problem with creation of customers, then you know you where to find the one and only place where it was coded: in the data layer (customer class). Where all rules are coded is not that important. You can use php classes, php functions, sql, database triggers, stored procedures or foreign keys, column constraints, table constraints, ... Just collect everything for manipulating customers and put them in the same place where you can call it from everywhere, so you need not to code it twice and test it twice and debug it twice or more. Use this principle for every object (table or combination of tables or ..). Every developer would know where to look when there is a problem with the process creating or deleting or updating a customer. When someone still would like to port the software package to another database system, then he has only to port the database layer and is not disturbed by the presentation layer and ... Resume: the above principle/architecture is based at two ideas: 1. you always knows where to find object (table) related functions, so you are not attracted to code same functions again and again but just calls them again 2. you only code once the business rules and are able to reuse them several times by calling them from several php scripts, batch scripts, webservices, .... With best regards, Dick Stins ----- Original Message ----- From: "Daintrees" <p.d...@pa...> To: <web...@li...> Sent: Monday, September 20, 2004 9:24 AM Subject: Re: EGS/Postgresql - Was Re: [Web-erp-developers] Cheap > You'll have to excuse my naievety (and poor spelling) since most of the > native functions are similar in function but different in name for differing > DBs why does one need such a lavish abstraction layer why won't a > ConnectDB.inc calling the native C calls to connect directly for other DBs > do the trick? This way we have ultimate performance minimum overhead! > > I really don't understand why such lengths are necessary - the function > calls are virtually one to one and even most of the parameters are the same. > > MS SQL Server > > mssql_connect > mssql_fetch_array > mssql_fetch_row > mssql_data_seek > > > MySql > > mysql_connect > mysql_query > mysql_fetch_array > mysql_fetch_row > mysql_data_seek > > Postgres > > pg_connect > pg_query > pg_fetch_array > pg_fetch_row > pg_data_seek > > > Firebird/interbase > > ibase_connect > ibase_query > ibase_fetch_assoc > ibase_fetch_row > > whoops there is no > ibase_data_seek > > maybe I'm answering my own question! > > > Phil > > > ----- Original Message ----- > From: "Jake Stride" <ns...@us...> > To: <web...@li...> > Sent: Monday, September 20, 2004 5:58 PM > Subject: Re: EGS/Postgresql - Was Re: [Web-erp-developers] Cheap > > > > Stins, Dick wrote: > > > > >Jake, > > > > > >Thanks for your comments. > > > > > >I am not a fan of pear:db. I prefer to use standard sql. That is already > a > > >big step for portability + the clean and mean weberp script > ConnectDB.inc. > > >So it should not be too hard to port web-erp to another db engine. > > > > > > > > No to be honest neither am I, for reasons I won't bore you with it was > > chosen at the start of the project and has persited through. Have you > > had a look at > > > > http://creole.phpdb.org/ > > http://propel.phpdb.org/wiki/ > > > > >Smarty might be interesting, but I am already glad when css is optimal > used. > > > > > > > > This is the case with EGS, it just allows all of the presentation logic > > to be removed from the code base and allows people to be a lot more > > flexible with the layout without having to trawl through the PHP code. > > > > >Multiple company support is interesting. > > > > > > > > Yes this was one of the distinctions that was used to justify it over > > simply contributing to an exisitng project since non of the others do > > it. For this reason I am not sure if one of the Application Frameworks > > would have worked due to its authentication system. > > > > Have you looked at http://www.binarycloud.com/ > > > > >Does it also support ldap (nds)? > > > > > > > > Not at present. My knowledge of ldap consists of the following: > > > > It exists > > It is adirectory server > > > > I have always thought that it would be good to have it working with ldap > > but unfortunately I have not had the time to look into it. However with > > the present system I believe you can use PEAR:DB to connect to ldap so > > may be possible. > > > > Thanks > > > > Jake > > > > >with best regards, > > > > > >Dick Stins > > > > > >----- Original Message ----- > > >From: "Jake Stride" <ns...@us...> > > >To: <web...@li...> > > >Sent: Sunday, September 19, 2004 7:41 PM > > >Subject: Re: EGS/Postgresql - Was Re: [Web-erp-developers] Cheap > > > > > > > > > > > > > > >>Stins, Dick wrote: > > >> > > >> > > >> > > >>>Jake, > > >>> > > >>>I think that common functions which are needed in weberp and in your > crm > > >>>software should be encapsulated in classes, so you do not need to know > > >>> > > >>> > > >where > > > > > > > > >>>the information is comming from (postgres or mysql). > > >>> > > >>> > > >>> > > >>At the moment it kind of should be in that it uses PEAR:DB for > > >> > > >> > > >abstraction. > > > > > > > > >>>When you want to > > >>>integrate web-erp and your crm software, you still need to integrate > the > > >>>authentication and the address books processing and .... > > >>>The design of these issues should be loosely connected or we should > > >>> > > >>> > > >create > > > > > > > > >>>one big project (wegs-erp?). > > >>> > > >>> > > >>> > > >>> > > >>That could be interesting and worthwhile, is it something people may be > > >>interested in? > > >> > > >> > > >> > > >>>The same for all your code which needs views. Those should be > > >>> > > >>> > > >encapsulated > > > > > > > > >>>in classes, so it's easy to write an alternative for mysql > > >>>(allthough when you are able to run mysql with maxdb, then probably > you > > >>> > > >>> > > >can > > > > > > > > >>>use views). > > >>> > > >>>I even recommend to develop an architecture with: > > >>>- front end layer > > >>> > > >>> > > >>> > > >>> > > >>Smarty for templating > > >> > > >> > > >> > > >>>- business rule layer > > >>> > > >>> > > >>> > > >>> > > >>System is written as classes > > >> > > >> > > >> > > >>>- database trigger layer > > >>>- database layer > > >>> > > >>> > > >>> > > >>> > > >>PEAR > > >> > > >> > > >> > > >>>This helps to be in control of you own code, reuse of code, increase > > >>>portability for you code (like porting to other databases: sql server, > > >>>firebird, oracle). > > >>> > > >>> > > >>> > > >>> > > >>EGS should work in oracle without much trouble because of PEAR:DB > > >> > > >> > > >> > > >>>An example of an architecture like this is: > > >>>http://sourceforge.net/projects/seagull/ > > >>> > > >>> > > >>> > > >>> > > >>I did have a look at these, the problem is that EGS authentication is > > >>more complicated that this. It is written as an ASP application so that > > >>several companies can use the same server/DB etc. > > >> > > >>IE in egs one company can login and create there own users and groups > > >>and insert data etc that another company cannot see. > > >> > > >>Jake > > >> > > >> > > >> > > >>>With best regards, > > >>> > > >>>Dick Stins > > >>> > > >>> > > >>> > > > > > > > > > > > > > > > > > >------------------------------------------------------- > > >This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > > >Project Admins to receive an Apple iPod Mini FREE for your judgement on > > >who ports your project to Linux PPC the best. Sponsored by IBM. > > >Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php > > >_______________________________________________ > > >Web-erp-developers mailing list > > >Web...@li... > > >https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > > > > > > > > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > > Project Admins to receive an Apple iPod Mini FREE for your judgement on > > who ports your project to Linux PPC the best. Sponsored by IBM. > > Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php > > _______________________________________________ > > Web-erp-developers mailing list > > Web...@li... > > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > Project Admins to receive an Apple iPod Mini FREE for your judgement on > who ports your project to Linux PPC the best. Sponsored by IBM. > Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers |
|
From: skaill <sk...@ro...> - 2004-09-20 20:53:20
|
In theory 3-tier is a great idea, however it has some drawbacks too. I don't know of a system anywhere as near as complete as webERP that has true 3-tier separation. An accounting system in particular is critical to a business. It must be very, very reliable. For this reason, typically you will see less than state of the art at banks and government for instance. Someone's neck would be on the line if things got out of control and they can very easily. There are some other important reasons for carefully considering the approach. Many who will put their attention toward webERP will be accountants who may not be computer experts like us. Going too extreme can alienate them from contributing even though they are the ones who more likely understand the full extent of deeper accounting problems. What I'm saying here is I think it's a fine line and a line that, in the interest of keeping the product stable, bringing more people on board and keeping people onboard, needs to be moved slowly. Side note: While I do believe in isolating the business rules, I do not believe planting business rules in the triggers of a database or in stored procedures is beneficial, I would keep them in code. Triggers and stored procedures lead to bits and pieces everywhere. Steve ----- Original Message ----- From: "Stins, Dick" <DR...@Zi...> To: <web...@li...> Sent: Monday, September 20, 2004 4:29 PM Subject: Re: EGS/Postgresql - Was Re: [Web-erp-developers] Cheap > Yes, any technical database layer is not that interesting, although it's > always handy when it is not too much work to move to another database > engine, but I see no need to change from mysql to another database engine at > the moment. Solution like pear:db seems only to slow things down and hide > the real code and creates more trouble when in pear:DB (or any other > wrapper) are some bugs. > > When I talk about a database layer, it's functional. Like you have a > function to delete a customer. > This functions checks all business constraints before deleting: > - are there any transaction related? > - are there any open orders? > - are there any companies related to this customer? > - is it an active customer? > - is it bankrupt? > - ... > > When one or more checks fail, then the function returns an understandable > error and refuses to continue. > > When you have this function, then you are able to call it from any script, > like a delete script, or a batch script which deletes lot's of customers, or > a webservices which tries to process delete the customer. > > The same for a create customer function. When all attributes (credit check, > address, chamber of commerce number, tax number, telephone number, > bankaccount number, ...) of the customer are properly set, then the status > of this customer will be valid. > > When you have one set of functions/methods to set all these items, then you > again can reuse this code (CLASS METHODS) of lot's of places. > > When you have a problem with creation of customers, then you know you where > to find the one and only place where it was coded: in the data layer > (customer class). > > Where all rules are coded is not that important. You can use php classes, > php functions, sql, database triggers, stored procedures or foreign keys, > column constraints, table constraints, ... > Just collect everything for manipulating customers and put them in the same > place where you can call it from everywhere, so you need not to code it > twice and test it twice and debug it twice or more. > > Use this principle for every object (table or combination of tables or ..). > Every developer would know where to look when there is a problem with the > process creating or deleting or updating a customer. > > When someone still would like to port the software package to another > database system, then he has only to port the database layer and is not > disturbed by the presentation layer and ... > > Resume: the above principle/architecture is based at two ideas: > 1. you always knows where to find object (table) related functions, so you > are not attracted to code same functions again and again but just calls them > again > 2. you only code once the business rules and are able to reuse them several > times by calling them from several php scripts, batch scripts, webservices, > .... > > With best regards, > > Dick Stins > > ----- Original Message ----- > From: "Daintrees" <p.d...@pa...> > To: <web...@li...> > Sent: Monday, September 20, 2004 9:24 AM > Subject: Re: EGS/Postgresql - Was Re: [Web-erp-developers] Cheap > > > > You'll have to excuse my naievety (and poor spelling) since most of the > > native functions are similar in function but different in name for > differing > > DBs why does one need such a lavish abstraction layer why won't a > > ConnectDB.inc calling the native C calls to connect directly for other DBs > > do the trick? This way we have ultimate performance minimum overhead! > > > > I really don't understand why such lengths are necessary - the function > > calls are virtually one to one and even most of the parameters are the > same. > > > > MS SQL Server > > > > mssql_connect > > mssql_fetch_array > > mssql_fetch_row > > mssql_data_seek > > > > > > MySql > > > > mysql_connect > > mysql_query > > mysql_fetch_array > > mysql_fetch_row > > mysql_data_seek > > > > Postgres > > > > pg_connect > > pg_query > > pg_fetch_array > > pg_fetch_row > > pg_data_seek > > > > > > Firebird/interbase > > > > ibase_connect > > ibase_query > > ibase_fetch_assoc > > ibase_fetch_row > > > > whoops there is no > > ibase_data_seek > > > > maybe I'm answering my own question! > > > > > > Phil > > > > > > ----- Original Message ----- > > From: "Jake Stride" <ns...@us...> > > To: <web...@li...> > > Sent: Monday, September 20, 2004 5:58 PM > > Subject: Re: EGS/Postgresql - Was Re: [Web-erp-developers] Cheap > > > > > > > Stins, Dick wrote: > > > > > > >Jake, > > > > > > > >Thanks for your comments. > > > > > > > >I am not a fan of pear:db. I prefer to use standard sql. That is > already > > a > > > >big step for portability + the clean and mean weberp script > > ConnectDB.inc. > > > >So it should not be too hard to port web-erp to another db engine. > > > > > > > > > > > No to be honest neither am I, for reasons I won't bore you with it was > > > chosen at the start of the project and has persited through. Have you > > > had a look at > > > > > > http://creole.phpdb.org/ > > > http://propel.phpdb.org/wiki/ > > > > > > >Smarty might be interesting, but I am already glad when css is optimal > > used. > > > > > > > > > > > This is the case with EGS, it just allows all of the presentation logic > > > to be removed from the code base and allows people to be a lot more > > > flexible with the layout without having to trawl through the PHP code. > > > > > > >Multiple company support is interesting. > > > > > > > > > > > Yes this was one of the distinctions that was used to justify it over > > > simply contributing to an exisitng project since non of the others do > > > it. For this reason I am not sure if one of the Application Frameworks > > > would have worked due to its authentication system. > > > > > > Have you looked at http://www.binarycloud.com/ > > > > > > >Does it also support ldap (nds)? > > > > > > > > > > > Not at present. My knowledge of ldap consists of the following: > > > > > > It exists > > > It is adirectory server > > > > > > I have always thought that it would be good to have it working with ldap > > > but unfortunately I have not had the time to look into it. However with > > > the present system I believe you can use PEAR:DB to connect to ldap so > > > may be possible. > > > > > > Thanks > > > > > > Jake > > > > > > >with best regards, > > > > > > > >Dick Stins > > > > > > > >----- Original Message ----- > > > >From: "Jake Stride" <ns...@us...> > > > >To: <web...@li...> > > > >Sent: Sunday, September 19, 2004 7:41 PM > > > >Subject: Re: EGS/Postgresql - Was Re: [Web-erp-developers] Cheap > > > > > > > > > > > > > > > > > > > >>Stins, Dick wrote: > > > >> > > > >> > > > >> > > > >>>Jake, > > > >>> > > > >>>I think that common functions which are needed in weberp and in your > > crm > > > >>>software should be encapsulated in classes, so you do not need to > know > > > >>> > > > >>> > > > >where > > > > > > > > > > > >>>the information is comming from (postgres or mysql). > > > >>> > > > >>> > > > >>> > > > >>At the moment it kind of should be in that it uses PEAR:DB for > > > >> > > > >> > > > >abstraction. > > > > > > > > > > > >>>When you want to > > > >>>integrate web-erp and your crm software, you still need to integrate > > the > > > >>>authentication and the address books processing and .... > > > >>>The design of these issues should be loosely connected or we should > > > >>> > > > >>> > > > >create > > > > > > > > > > > >>>one big project (wegs-erp?). > > > >>> > > > >>> > > > >>> > > > >>> > > > >>That could be interesting and worthwhile, is it something people may > be > > > >>interested in? > > > >> > > > >> > > > >> > > > >>>The same for all your code which needs views. Those should be > > > >>> > > > >>> > > > >encapsulated > > > > > > > > > > > >>>in classes, so it's easy to write an alternative for mysql > > > >>>(allthough when you are able to run mysql with maxdb, then probably > > you > > > >>> > > > >>> > > > >can > > > > > > > > > > > >>>use views). > > > >>> > > > >>>I even recommend to develop an architecture with: > > > >>>- front end layer > > > >>> > > > >>> > > > >>> > > > >>> > > > >>Smarty for templating > > > >> > > > >> > > > >> > > > >>>- business rule layer > > > >>> > > > >>> > > > >>> > > > >>> > > > >>System is written as classes > > > >> > > > >> > > > >> > > > >>>- database trigger layer > > > >>>- database layer > > > >>> > > > >>> > > > >>> > > > >>> > > > >>PEAR > > > >> > > > >> > > > >> > > > >>>This helps to be in control of you own code, reuse of code, increase > > > >>>portability for you code (like porting to other databases: sql > server, > > > >>>firebird, oracle). > > > >>> > > > >>> > > > >>> > > > >>> > > > >>EGS should work in oracle without much trouble because of PEAR:DB > > > >> > > > >> > > > >> > > > >>>An example of an architecture like this is: > > > >>>http://sourceforge.net/projects/seagull/ > > > >>> > > > >>> > > > >>> > > > >>> > > > >>I did have a look at these, the problem is that EGS authentication is > > > >>more complicated that this. It is written as an ASP application so > that > > > >>several companies can use the same server/DB etc. > > > >> > > > >>IE in egs one company can login and create there own users and groups > > > >>and insert data etc that another company cannot see. > > > >> > > > >>Jake > > > >> > > > >> > > > >> > > > >>>With best regards, > > > >>> > > > >>>Dick Stins > > > >>> > > > >>> > > > >>> > > > > > > > > > > > > > > > > > > > > > > > >------------------------------------------------------- > > > >This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > > > >Project Admins to receive an Apple iPod Mini FREE for your judgement on > > > >who ports your project to Linux PPC the best. Sponsored by IBM. > > > >Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php > > > >_______________________________________________ > > > >Web-erp-developers mailing list > > > >Web...@li... > > > >https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > > > Project Admins to receive an Apple iPod Mini FREE for your judgement on > > > who ports your project to Linux PPC the best. Sponsored by IBM. > > > Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php > > > _______________________________________________ > > > Web-erp-developers mailing list > > > Web...@li... > > > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > > > > > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > > Project Admins to receive an Apple iPod Mini FREE for your judgement on > > who ports your project to Linux PPC the best. Sponsored by IBM. > > Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php > > _______________________________________________ > > Web-erp-developers mailing list > > Web...@li... > > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > Project Admins to receive an Apple iPod Mini FREE for your judgement on > who ports your project to Linux PPC the best. Sponsored by IBM. > Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers |
|
From: Stins, D. <DR...@Zi...> - 2004-09-20 21:17:25
|
Steve, When mysql releases with stored procedures and triggers are commonly used, then it will be a piece of a cake to convince some one that this will improve the data integrity dramatically. And that's all accountants wants: reliable data. For now, I think it will be a great improvement when we isolate the business rules in classes when we do maintenance at scripts or when we develop new scripts for new functionality. Like you mentioned: improve things slowly, so web-erp will improve instead of be unstable. with best regards, Dick Stins ----- Original Message ----- From: "skaill" <sk...@ro...> To: <web...@li...> Sent: Monday, September 20, 2004 10:54 PM Subject: Re: EGS/Postgresql - Was Re: [Web-erp-developers] Cheap > In theory 3-tier is a great idea, however it has some drawbacks too. I > don't know of a system anywhere as near as complete as webERP that has true > 3-tier separation. An accounting system in particular is critical to a > business. It must be very, very reliable. For this reason, typically you > will see less than state of the art at banks and government for instance. > Someone's neck would be on the line if things got out of control and they > can very easily. > > There are some other important reasons for carefully considering the > approach. Many who will put their attention toward webERP will be > accountants who may not be computer experts like us. Going too extreme can > alienate them from contributing even though they are the ones who more > likely understand the full extent of deeper accounting problems. > > What I'm saying here is I think it's a fine line and a line that, in the > interest of keeping the product stable, bringing more people on board and > keeping people onboard, needs to be moved slowly. > > Side note: While I do believe in isolating the business rules, I do not > believe planting business rules in the triggers of a database or in stored > procedures is beneficial, I would keep them in code. Triggers and stored > procedures lead to bits and pieces everywhere. > > Steve > > ----- Original Message ----- > From: "Stins, Dick" <DR...@Zi...> > To: <web...@li...> > Sent: Monday, September 20, 2004 4:29 PM > Subject: Re: EGS/Postgresql - Was Re: [Web-erp-developers] Cheap > > > > Yes, any technical database layer is not that interesting, although it's > > always handy when it is not too much work to move to another database > > engine, but I see no need to change from mysql to another database engine > at > > the moment. Solution like pear:db seems only to slow things down and hide > > the real code and creates more trouble when in pear:DB (or any other > > wrapper) are some bugs. > > > > When I talk about a database layer, it's functional. Like you have a > > function to delete a customer. > > This functions checks all business constraints before deleting: > > - are there any transaction related? > > - are there any open orders? > > - are there any companies related to this customer? > > - is it an active customer? > > - is it bankrupt? > > - ... > > > > When one or more checks fail, then the function returns an understandable > > error and refuses to continue. > > > > When you have this function, then you are able to call it from any script, > > like a delete script, or a batch script which deletes lot's of customers, > or > > a webservices which tries to process delete the customer. > > > > The same for a create customer function. When all attributes (credit > check, > > address, chamber of commerce number, tax number, telephone number, > > bankaccount number, ...) of the customer are properly set, then the status > > of this customer will be valid. > > > > When you have one set of functions/methods to set all these items, then > you > > again can reuse this code (CLASS METHODS) of lot's of places. > > > > When you have a problem with creation of customers, then you know you > where > > to find the one and only place where it was coded: in the data layer > > (customer class). > > > > Where all rules are coded is not that important. You can use php classes, > > php functions, sql, database triggers, stored procedures or foreign keys, > > column constraints, table constraints, ... > > Just collect everything for manipulating customers and put them in the > same > > place where you can call it from everywhere, so you need not to code it > > twice and test it twice and debug it twice or more. > > > > Use this principle for every object (table or combination of tables or > ..). > > Every developer would know where to look when there is a problem with the > > process creating or deleting or updating a customer. > > > > When someone still would like to port the software package to another > > database system, then he has only to port the database layer and is not > > disturbed by the presentation layer and ... > > > > Resume: the above principle/architecture is based at two ideas: > > 1. you always knows where to find object (table) related functions, so you > > are not attracted to code same functions again and again but just calls > them > > again > > 2. you only code once the business rules and are able to reuse them > several > > times by calling them from several php scripts, batch scripts, > webservices, > > .... > > > > With best regards, > > > > Dick Stins > > > > ----- Original Message ----- > > From: "Daintrees" <p.d...@pa...> > > To: <web...@li...> > > Sent: Monday, September 20, 2004 9:24 AM > > Subject: Re: EGS/Postgresql - Was Re: [Web-erp-developers] Cheap > > > > > > > You'll have to excuse my naievety (and poor spelling) since most of the > > > native functions are similar in function but different in name for > > differing > > > DBs why does one need such a lavish abstraction layer why won't a > > > ConnectDB.inc calling the native C calls to connect directly for other > DBs > > > do the trick? This way we have ultimate performance minimum overhead! > > > > > > I really don't understand why such lengths are necessary - the function > > > calls are virtually one to one and even most of the parameters are the > > same. > > > > > > MS SQL Server > > > > > > mssql_connect > > > mssql_fetch_array > > > mssql_fetch_row > > > mssql_data_seek > > > > > > > > > MySql > > > > > > mysql_connect > > > mysql_query > > > mysql_fetch_array > > > mysql_fetch_row > > > mysql_data_seek > > > > > > Postgres > > > > > > pg_connect > > > pg_query > > > pg_fetch_array > > > pg_fetch_row > > > pg_data_seek > > > > > > > > > Firebird/interbase > > > > > > ibase_connect > > > ibase_query > > > ibase_fetch_assoc > > > ibase_fetch_row > > > > > > whoops there is no > > > ibase_data_seek > > > > > > maybe I'm answering my own question! > > > > > > > > > Phil > > > > > > > > > ----- Original Message ----- > > > From: "Jake Stride" <ns...@us...> > > > To: <web...@li...> > > > Sent: Monday, September 20, 2004 5:58 PM > > > Subject: Re: EGS/Postgresql - Was Re: [Web-erp-developers] Cheap > > > > > > > > > > Stins, Dick wrote: > > > > > > > > >Jake, > > > > > > > > > >Thanks for your comments. > > > > > > > > > >I am not a fan of pear:db. I prefer to use standard sql. That is > > already > > > a > > > > >big step for portability + the clean and mean weberp script > > > ConnectDB.inc. > > > > >So it should not be too hard to port web-erp to another db engine. > > > > > > > > > > > > > > No to be honest neither am I, for reasons I won't bore you with it was > > > > chosen at the start of the project and has persited through. Have you > > > > had a look at > > > > > > > > http://creole.phpdb.org/ > > > > http://propel.phpdb.org/wiki/ > > > > > > > > >Smarty might be interesting, but I am already glad when css is > optimal > > > used. > > > > > > > > > > > > > > This is the case with EGS, it just allows all of the presentation > logic > > > > to be removed from the code base and allows people to be a lot more > > > > flexible with the layout without having to trawl through the PHP code. > > > > > > > > >Multiple company support is interesting. > > > > > > > > > > > > > > Yes this was one of the distinctions that was used to justify it over > > > > simply contributing to an exisitng project since non of the others do > > > > it. For this reason I am not sure if one of the Application Frameworks > > > > would have worked due to its authentication system. > > > > > > > > Have you looked at http://www.binarycloud.com/ > > > > > > > > >Does it also support ldap (nds)? > > > > > > > > > > > > > > Not at present. My knowledge of ldap consists of the following: > > > > > > > > It exists > > > > It is adirectory server > > > > > > > > I have always thought that it would be good to have it working with > ldap > > > > but unfortunately I have not had the time to look into it. However > with > > > > the present system I believe you can use PEAR:DB to connect to ldap so > > > > may be possible. > > > > > > > > Thanks > > > > > > > > Jake > > > > > > > > >with best regards, > > > > > > > > > >Dick Stins > > > > > > > > > >----- Original Message ----- > > > > >From: "Jake Stride" <ns...@us...> > > > > >To: <web...@li...> > > > > >Sent: Sunday, September 19, 2004 7:41 PM > > > > >Subject: Re: EGS/Postgresql - Was Re: [Web-erp-developers] Cheap > > > > > > > > > > > > > > > > > > > > > > > > >>Stins, Dick wrote: > > > > >> > > > > >> > > > > >> > > > > >>>Jake, > > > > >>> > > > > >>>I think that common functions which are needed in weberp and in > your > > > crm > > > > >>>software should be encapsulated in classes, so you do not need to > > know > > > > >>> > > > > >>> > > > > >where > > > > > > > > > > > > > > >>>the information is comming from (postgres or mysql). > > > > >>> > > > > >>> > > > > >>> > > > > >>At the moment it kind of should be in that it uses PEAR:DB for > > > > >> > > > > >> > > > > >abstraction. > > > > > > > > > > > > > > >>>When you want to > > > > >>>integrate web-erp and your crm software, you still need to > integrate > > > the > > > > >>>authentication and the address books processing and .... > > > > >>>The design of these issues should be loosely connected or we should > > > > >>> > > > > >>> > > > > >create > > > > > > > > > > > > > > >>>one big project (wegs-erp?). > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>That could be interesting and worthwhile, is it something people may > > be > > > > >>interested in? > > > > >> > > > > >> > > > > >> > > > > >>>The same for all your code which needs views. Those should be > > > > >>> > > > > >>> > > > > >encapsulated > > > > > > > > > > > > > > >>>in classes, so it's easy to write an alternative for mysql > > > > >>>(allthough when you are able to run mysql with maxdb, then > probably > > > you > > > > >>> > > > > >>> > > > > >can > > > > > > > > > > > > > > >>>use views). > > > > >>> > > > > >>>I even recommend to develop an architecture with: > > > > >>>- front end layer > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>Smarty for templating > > > > >> > > > > >> > > > > >> > > > > >>>- business rule layer > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>System is written as classes > > > > >> > > > > >> > > > > >> > > > > >>>- database trigger layer > > > > >>>- database layer > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>PEAR > > > > >> > > > > >> > > > > >> > > > > >>>This helps to be in control of you own code, reuse of code, > increase > > > > >>>portability for you code (like porting to other databases: sql > > server, > > > > >>>firebird, oracle). > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>EGS should work in oracle without much trouble because of PEAR:DB > > > > >> > > > > >> > > > > >> > > > > >>>An example of an architecture like this is: > > > > >>>http://sourceforge.net/projects/seagull/ > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>I did have a look at these, the problem is that EGS authentication > is > > > > >>more complicated that this. It is written as an ASP application so > > that > > > > >>several companies can use the same server/DB etc. > > > > >> > > > > >>IE in egs one company can login and create there own users and > groups > > > > >>and insert data etc that another company cannot see. > > > > >> > > > > >>Jake > > > > >> > > > > >> > > > > >> > > > > >>>With best regards, > > > > >>> > > > > >>>Dick Stins > > > > >>> > > > > >>> > > > > >>> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >------------------------------------------------------- > > > > >This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > > > > >Project Admins to receive an Apple iPod Mini FREE for your judgement > on > > > > >who ports your project to Linux PPC the best. Sponsored by IBM. > > > > >Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php > > > > >_______________________________________________ > > > > >Web-erp-developers mailing list > > > > >Web...@li... > > > > >https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > > > > Project Admins to receive an Apple iPod Mini FREE for your judgement > on > > > > who ports your project to Linux PPC the best. Sponsored by IBM. > > > > Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php > > > > _______________________________________________ > > > > Web-erp-developers mailing list > > > > Web...@li... > > > > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > > > Project Admins to receive an Apple iPod Mini FREE for your judgement on > > > who ports your project to Linux PPC the best. Sponsored by IBM. > > > Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php > > > _______________________________________________ > > > Web-erp-developers mailing list > > > Web...@li... > > > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > > > > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > > Project Admins to receive an Apple iPod Mini FREE for your judgement on > > who ports your project to Linux PPC the best. Sponsored by IBM. > > Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php > > _______________________________________________ > > Web-erp-developers mailing list > > Web...@li... > > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > Project Admins to receive an Apple iPod Mini FREE for your judgement on > who ports your project to Linux PPC the best. Sponsored by IBM. > Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers |
|
From: Daintrees <p.d...@pa...> - 2004-09-16 20:02:30
|
Thats a kind offer Jake - please could I accept with thanks. We are after weberp.org which is showing as available I would have preferred weberp.net but its gone. Many thanks Phil ----- Original Message ----- From: "Jake Stride" <ns...@us...> To: <web...@li...> Sent: Friday, September 17, 2004 5:40 AM Subject: Re: [Web-erp-developers] Cheap > skaill wrote: > > > I found this domain registration place that's really > > cheap...http://www.domains.ca/payment.asp > > > > Steve > > Well the company I work for offer domain registrations, and I have > spoken to the boss and he has offered a free registration if you want > it. (A link back to our company site would be nice if it is on offer - > we develop EGS under the GPL - http://egs.sourceforge.net). > > Jake > > > ------------------------------------------------------- > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > Project Admins to receive an Apple iPod Mini FREE for your judgement on > who ports your project to Linux PPC the best. Sponsored by IBM. > Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > |
|
From: skaill <sk...@ro...> - 2004-09-16 20:08:12
|
Can you send the details of where we should go to modify the registration record in the future to Phil in private please, Jake? Please let us know your company name/website and possibly a logo too. Steve ----- Original Message ----- From: "Daintrees" <p.d...@pa...> To: <web...@li...> Sent: Thursday, September 16, 2004 3:58 PM Subject: Re: [Web-erp-developers] Cheap > Thats a kind offer Jake - please could I accept with thanks. We are after > weberp.org which is showing as available I would have preferred weberp.net > but its gone. > > Many thanks > > Phil > > > ----- Original Message ----- > From: "Jake Stride" <ns...@us...> > To: <web...@li...> > Sent: Friday, September 17, 2004 5:40 AM > Subject: Re: [Web-erp-developers] Cheap > > > > skaill wrote: > > > > > I found this domain registration place that's really > > > cheap...http://www.domains.ca/payment.asp > > > > > > Steve > > > > Well the company I work for offer domain registrations, and I have > > spoken to the boss and he has offered a free registration if you want > > it. (A link back to our company site would be nice if it is on offer - > > we develop EGS under the GPL - http://egs.sourceforge.net). > > > > Jake > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > > Project Admins to receive an Apple iPod Mini FREE for your judgement on > > who ports your project to Linux PPC the best. Sponsored by IBM. > > Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php > > _______________________________________________ > > Web-erp-developers mailing list > > Web...@li... > > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > Project Admins to receive an Apple iPod Mini FREE for your judgement on > who ports your project to Linux PPC the best. Sponsored by IBM. > Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php > _______________________________________________ > Web-erp-developers mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers |
|
From: Daintrees <p.d...@pa...> - 2004-09-17 01:05:32
|
I believe we can get weberp going on Postgres easily too - much of the ground work has been done by Danie - but sql in some scripts may have to change to be more generic. Most of it is pretty generic. I am keen not to be reliant on MySql as the only db weberp works on. If we can get the system working on postgres it surely will not be much more to do to work with firebird, MS SQL server, Sybase and a bunch of others. I know Jesse is a bit sceptical - I'd like to prove it. Alas all good things do take time though. I also believe it is much better to work with someone who is keen on integration from the other side of the integration. Count me in Jake. Phil > > Of course integration with some of these tools may be easier and of > course everyone has to weigh up the pros and cons of what they want from > the integration (integration with the above products may suit some > people down to the ground), but when I last looked most of the projects > above did not have any intentions to add any functionality above that > required of the CRM, and this is where EGS is different. > > At present EGS is in a state between CRM and weperp. All of the CRM is > linked into the project management and has some job costing and time > tracking facilities present (it is this functionality we have been > working on for a client, and why we paused looking at weberp for a > while), it is on this that we would like to expand by adding the ability > to run accounting/erp etc from the system. With the possibility of > weberp running on postgres it seems to be the best system for us to > integrate (we have looked at sql-ledger too) and that is why we > appraoched weberp to find out more ( I was unaware of any other projects > looking to do this too). > > Obviously I am biased since a lot of my blood, sweat and tears have gone > into EGS, but I for one will continue to look at integrating web-erp > with EGS since I believe it to be a fairly trivial task (famous last > words) once I have gotten web-erp to run on postgresql due to the way > out database is laid out. > > So my slightly ranting email aside, if anyone has gotten web-erp to work > on postgresql I would be most interested to your experiences. > > Thanks > > Jake > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X