Going through some backlog of email that got some answers and so I left it
for a while! A couple of comments on this one...
On the subject of database or any other abstraction another main
consideration is weighing the benefit versus the added expense of relying on
something external. That something will always be in transition to new
versions, etc. which gets more difficult and can cause issues while trying
to release a stable accounting product. Also, we end up relying on their
documentation for their part of the product. We end up relying on them
being stable and prevalent ongoing, something that occurs less than more
frequently. Often the code is done much differently and required additional
effort for any webERP developers and others to understand and work with.
So, for many reasons, an abstraction using another software means webERP's
reliance on it and weighs heavily on a decision to use it.
functionality must be covered by php. It could then be enhanced by
upon which is priority one for an accounting/erp system. An example of this
php must be automatically there in order to supply what is needed.
Personally I'm not sure that it would not be better to have users be able to
instead of or in conjunction with php at certain points as appropriate and
as it does now.
I think he's saying there needs to be an option that handles switching to
use one instead of the other depending on user selection and/or system
config. It should be globally, user and possibly even customer selectable.
I don't think showing the code presents a security risk as the code is
readily available which Phil says. However, I think showing code is a bad
thing and measures should be taken when possible to not show it.
It is appreciated that you point out these issues BrainX, however, all of
them take time and effort for someone to do as well as what the someones
already do. Many times the people suggesting actually do the work. When
not, the suggestions get done as they get done by whoever deems them a
embraced at least to the extent I suggest above. Same with the showing
code. No one would seem concerned about it except the person suggesting it
be changed (you), however, someone has to actually do it and they will
likely see an important reason before they do so. Again though, it is nice
to know of the issue.
Hmm, I wouldn't call the majority of these issues the core or what should be
the core of an accounting/erp application (webERP). Some is interesting
discussion about development philosophy, some other are issues that have
some priority within a huge priority of work being done on an ongoing basis
to make webERP better and better. Definitely looking forward to your
involvement with these and other areas of webERP in the future, BrainX.
----- Original Message -----
From: "Phil Daintree" <[hidden email]>
To: "BrainX" <[hidden email]>
Cc: <[hidden email]>
Sent: Friday, August 12, 2005 6:06 PM
Subject: [WebERP-developers] Re: Bunch o' things
> > The first thing is about the SQL abstraction layer. I know that webERP
> > very mature project, but i think that the SQL layer is kinda primitive.
> > There is some SQL library called ADOdb for PHP. It's object oriented and
> > very robust. It supports a good number of databases and prevents the
> > software for SQL injection attacks.
> > I will see if i could port webERP to use ADOdb... I think this could be
> > long and hard work but I also think that it will improve the security
> > portability.
> ADOdb is the way to go for DB abstraction whilst there would a performance
> penalty for us it would be bearable. When I first looked at these
> layers I was only aware of PEAR DB and this carries a whopping overhead
> really affecting performance quite dramatically. I was not prepared to
> the application in this way. ADOdb on the other hand is stable and fast.
> was starting again ADOdb would be the way to go. However, I am not
> in re-writing it since:
> 1. We have a choice of the two major open source DBs as things stand
> 2. I am fairly confident we could add others without too much pain.
> 3. Using ADOdb would carry a performance penalty over the direct function
> calls we currently use.
> This has been discussed at some length previously.
> > system, but there are some problems.
> > The first problem are the dates... There are some calendar scripts to
> > the date from a visual menu.
> my ignorance ... a poor driver I agree. I am loathe to bog the system down
> complexity ... its easy enough for me to understand at the moment. I am a
> little concerned that I may well be a limiting factor in the growth of
> but until someone who understands this stuff puts their hand up to lead
> major problem apart from not understanding it, is that the code must be
> downloaded to the browser - thus reducing page loading performance
> over dial up. Speedy response over dial up is a strong driver. There are
> time when webERP was started off some browsers had patchy support for
> some of the palm browsers came into this category.
> > The second thing are the prices format. Here
> > in Venezuela we use the period as thousands separator and the comma as
> > decimal separator. For example, one thousand and fifty cents is shown as
> > 1.000,50, this could be misunderstood in the system like 1.00050 units.
> There is also a couple of parameters for the PHP function number_format -
> better approach me thinks would be to have two more config parameters for
> thousands separator and decimal separator and give number format the whole
> lot on every call. Or, maybe better still - make these user parameters
> loaded with the user's preferences - so users in different countries can
> the numbers in the format they are familiar with. This is an easy fix
> the existing code - number_format is used everywhere there are commas.
> there is an easy way and a hard way - the easy way and having a mind to
> reducing dependencies should be the way to go.
> > Well... I also told you some time ago that there are some little
> > with the PHP includes: they show the code. I know this is an opensource
> > application, but showing the code could show any (if available) security
> > error in the current installed version, making a hacker attack more
> > effective. There are ways to avoid this.
> The code is completely visible to anyone who wishes to download it.
> > And, of course, the internationalization discussion about the problem of
> > the html references, and some other things (like, the date/time in the
> > footer as example, doesn't always shows in locale configuration) is
> > pending.
> I really need some help on this issue - it is a great shame to have come
> this way with the multi-language to fall over at the last hurdle.
> > I think that all this things are very important: they are the "core" of
> > application, and I could contribute with that. Well.. not now, but I'm
> > planning to go back to webERP again and very soon, all your work 'till
> > is very nice, I love it!
> Looking forward to having you on the team again!
> > Oh, as final words... There is some discussion about engaging other
> > applications to webERP? I've seen some about osCommerce integration, but
> > they've made this integration based in any document/standard of
> > communication?
> > Keep up the good wurx :)
> Phil Daintree
> webERP Project Admin
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> Web-erp-developers mailing list
> [hidden email]
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
Web-erp-developers mailing list
|Free forum by Nabble||Edit this page|