Re: [WebERP-developers] Re: Bunch o' things

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Re: [WebERP-developers] Re: Bunch o' things

steve-42-2
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.

The basic rule webERP has held to for Javascript is that necessary
functionality must be covered by php.  It could then be enhanced by
Javascript.  In that way it always works with any browser and can be relied
upon which is priority one for an accounting/erp system.  An example of this
is the login where it moves the cursor to user id but if the Javascript
fails it's not critical.  So far it would seem that if Javascript bombs the
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
optionally select whether they want Javascript to function or not and then
in the code there would be a check that executed "optional" Javascript
instead of or in conjunction with php at certain points as appropriate and
based on that user selection of using Javascript or not.  In this way it
would check if Javascript is to be executed for the logged in user and if so
it would supply the Javascript calendar, otherwise just supply the entry box
as it does now.

Don't think BrainX meant for Javascript to fix the commas or periods issue.
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
priority.  Think by that the Javascript issue becomes a non-issue until
someone does some Javascript in a way that can be
incorporated or challenges the approach to Javascript and Javascript is more
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.

Steve

----- 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
is a
> > 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
a
> > long and hard work but I also think that it will improve the security
and
> > 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
abstraction
> layers I was only aware of PEAR DB and this carries a whopping overhead
> really affecting performance quite dramatically. I was not prepared to
limit
> the application in this way. ADOdb on the other hand is stable and fast.
If I
> was starting again ADOdb would be the way to go. However, I am not
interested

> 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.
>
> > Another thing is... I know that you don't want any javascript in the
> > system, but there are some problems.
> >
> > The first problem are the dates... There are some calendar scripts to
pick
> > the date from a visual menu.
>
> Yes these would be good. In part the decision to avoid Javascript is
driven by
> my ignorance ... a poor driver I agree. I am loathe to bog the system down
in
> 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
webERP
> but until someone who understands this stuff puts their hand up to lead
the
> project. There are other good reasons for avoiding javascript too but my
> major problem apart from not understanding it, is that the code must be
> downloaded to the browser - thus reducing page loading performance
especially
> over dial up. Speedy response over dial up is a strong driver. There are
tiny
> snippets of javascript for focus improvements here and there already. At
the
> time when webERP was started off some browsers had patchy support for
> javascript and relying on it limited the browsers we could have as
clients -
> 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 -
the
> 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
see
> the numbers in the format they are familiar with. This is an easy fix
using
> the existing code - number_format is used everywhere there are commas.
Much
> better I say to use PHP where we can and avoid javascript where possible.
If
> 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.
>
>
> > There are javascripts to validate this and verify the good value.
> >
> > Well... I also told you some time ago that there are some little
problems

> > 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
all
> 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
the
> > 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
now

> > 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
Practices
> 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]
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>
>



-------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/web-erp-developers