web-erp-developers

[WebERP-developers] TableRows()

[Pak R. <pak...@gm...>]

Hi Phil:

I saw with satisfaction the commit 6859 where Rafael used the TableRows()
functions in some scripts. Now, I saw this change was reverted, and I can't
see but good things about it (probably i'm missing something).

These same 6 lines are repeated over and over webERP (probably over 100
times), so if we get a change to reduce the number of lines and still get a
readable script, I think it's worth it.

Well just my 2 cents. I would love to know your POV (and any other
developer's) about it :-)

Regards,
Ricard

Re: [WebERP-developers] TableRows()

[Phil D. <ph...@lo...>]

Ricard,

There are many many ways to reduce the amount of code in webERP - we 
really could take loads out... but the sacrifice is readability - I 
don't believe we would gain speed/efficiency.
If we made the tables a class as per Jonathan's idea we could take out 
buckets of code - this would be the obvious extension of the
I don't want to change the code to increase abstraction ever - or code 
that does the same thing a different way that could potentially 
introduce new bugs. Nope - the effort should be not to reinvent what we 
have, but to add functionality using the same blocks and structure as we 
have.

I believe you learnt php from webERP - and are a living example as to 
why the phil-osophy behind webERP's development style is one of it's 
greatest strengths...

Phil

Phil Daintree
Logic Works Ltd - +64 (0)275 567890
http://www.logicworks.co.nz

On 02/09/14 13:12, Pak Ricard wrote:
> Hi Phil:
>
> I saw with satisfaction the commit 6859 where Rafael used the 
> TableRows() functions in some scripts. Now, I saw this change was 
> reverted, and I can't see but good things about it (probably i'm 
> missing something).
>
> These same 6 lines are repeated over and over webERP (probably over 
> 100 times), so if we get a change to reduce the number of lines and 
> still get a readable script, I think it's worth it.
>
> Well just my 2 cents. I would love to know your POV (and any other 
> developer's) about it :-)
>
> Regards,
> Ricard
>
>
> ------------------------------------------------------------------------------
> Slashdot TV.
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/
>
>
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers

Re: [WebERP-developers] TableRows()

[Andrew G. <aga...@re...>]

Would it be any different if the code was copied into an include instead of a function and we replaced the lines of code with
include('includes/tablerow.inc');

This is what we do with header.inc and footer.inc.  We don't repeat that code in every script (Thank goodness).

<OPINION>
I think a minimal level of abstraction would make changes less daunting.  If I know I can concentrate on business logic and not formatting I would be willing to make more enhancements.
Enhancements might also be done more quickly, tested faster and be more stable.  An example is a recent change to introduce location based security to WebERP that I submitted.  I had seen in the forums multiple times people looking to restrict access to locations within a particular business function.  Example Warehouse worked can see inventory levels at Location A but not Location B.  In order to make this change I had to modify  every script where there was a location selection list.
I had to modify the code as follows:
BEFORE: $sql = "SELECT loccode, locationname FROM locations
AFTER: $sql = "SELECT locations.loccode, locationname, canview FROM locations
                                INNER JOIN locationusers ON locationusers.loccode=locations.loccode AND locationusers.userid='" .  $_SESSION['UserID'] . "' AND locationusers.canview=1"

That line alone appears like 50+ times in 50+ files.  The same code to build the <select> takes around 15 lines of code before and after that SQL that is nearly identical in every script.
If all of that code was in an include file or in a function I could have added a feature people requested in less than 1 day instead of 5 days.  And testing it would have been a lot faster.  If the logic is in 1 place I can test my change in < 5 screens be confident it is working.  If I have to change 50 scripts I need to test all 50 scripts...Because even the smallest typo can make a script break.

Abstraction and reduced code can be a good thing
</OPINION>

Best Regards,
Andrew

From: Phil Daintree [mailto:ph...@lo...]
Sent: Tuesday, September 02, 2014 1:25 AM
To: webERP Developers
Subject: Re: [WebERP-developers] TableRows()

Ricard,

There are many many ways to reduce the amount of code in webERP - we really could take loads out... but the sacrifice is readability - I don't believe we would gain speed/efficiency.
If we made the tables a class as per Jonathan's idea we could take out buckets of code - this would be the obvious extension of the
I don't want to change the code to increase abstraction ever - or code that does the same thing a different way that could potentially introduce new bugs. Nope - the effort should be not to reinvent what we have, but to add functionality using the same blocks and structure as we have.

I believe you learnt php from webERP - and are a living example as to why the phil-osophy behind webERP's development style is one of it's greatest strengths...


Phil



Phil Daintree

Logic Works Ltd - +64 (0)275 567890

http://www.logicworks.co.nz
On 02/09/14 13:12, Pak Ricard wrote:
Hi Phil:

I saw with satisfaction the commit 6859 where Rafael used the TableRows() functions in some scripts. Now, I saw this change was reverted, and I can't see but good things about it (probably i'm missing something).

These same 6 lines are repeated over and over webERP (probably over 100 times), so if we get a change to reduce the number of lines and still get a readable script, I think it's worth it.

Well just my 2 cents. I would love to know your POV (and any other developer's) about it :-)

Regards,
Ricard




------------------------------------------------------------------------------

Slashdot TV.

Video for Nerds.  Stuff that matters.

http://tv.slashdot.org/




_______________________________________________

Web-erp-developers mailing list

Web...@li...<mailto:Web...@li...>

https://lists.sourceforge.net/lists/listinfo/web-erp-developers

Re: [WebERP-developers] TableRows()

[Pak R. <pak...@gm...>]

Hi all:

Following on Andrew's POV, we calculate the demand of one item 10 times in
webERP and it takes 94 lines of code (if I'm not wrong).

I think it is a much readable script if we have a function called
CalculateDemandForItem ($StockId, $Location) and we encapsulate the 94
lines there.

Sharing Andrew's <OPINION>, we save 9 * 94 lines of repeated code and we
get a much readable script.

There are dozens of similar situations in webERP, where I think we can
improve readability and reduce the chances of bugs, as 1 fix fixes all.

Hope we can find a reasonable point where all feel comfortable.

Regards,
Ricard

2014-09-09 3:48 GMT+08:00 Andrew Galuski <aga...@re...>:

>  Would it be any different if the code was copied into an include instead
> of a function and we replaced the lines of code with
>
> include('includes/tablerow.inc');
>
>
>
> This is what we do with header.inc and footer.inc.  We don’t repeat that
> code in every script (Thank goodness).
>
>
>
> <OPINION>
>
> I think a minimal level of abstraction would make changes less daunting.
> If I know I can concentrate on business logic and not formatting I would be
> willing to make more enhancements.
>
> Enhancements might also be done more quickly, tested faster and be more
> stable.  An example is a recent change to introduce location based security
> to WebERP that I submitted.  I had seen in the forums multiple times people
> looking to restrict access to locations within a particular business
> function.  Example Warehouse worked can see inventory levels at Location A
> but not Location B.  In order to make this change I had to modify  every
> script where there was a location selection list.
>
> I had to modify the code as follows:
>
> BEFORE: $sql = "SELECT loccode, locationname FROM locations
>
> AFTER: $sql = "SELECT locations.loccode, locationname, canview FROM
> locations
>
>                                 INNER JOIN locationusers ON
> locationusers.loccode=locations.loccode AND locationusers.userid='" .
> $_SESSION['UserID'] . "' AND locationusers.canview=1"
>
>
>
> That line alone appears like 50+ times in 50+ files.  The same code to
> build the <select> takes around 15 lines of code before and after that SQL
> that is nearly identical in every script.
>
> If all of that code was in an include file or in a function I could have
> added a feature people requested in less than 1 day instead of 5 days.  And
> testing it would have been a lot faster.  If the logic is in 1 place I can
> test my change in < 5 screens be confident it is working.  If I have to
> change 50 scripts I need to test all 50 scripts…Because even the smallest
> typo can make a script break.
>
>
>
> Abstraction and reduced code can be a good thing
>
> </OPINION>
>
>
>
> Best Regards,
>
> Andrew
>
>
>
> *From:* Phil Daintree [mailto:ph...@lo...]
> *Sent:* Tuesday, September 02, 2014 1:25 AM
> *To:* webERP Developers
> *Subject:* Re: [WebERP-developers] TableRows()
>
>
>
> Ricard,
>
> There are many many ways to reduce the amount of code in webERP - we
> really could take loads out... but the sacrifice is readability - I don't
> believe we would gain speed/efficiency.
> If we made the tables a class as per Jonathan's idea we could take out
> buckets of code - this would be the obvious extension of the
> I don't want to change the code to increase abstraction ever - or code
> that does the same thing a different way that could potentially introduce
> new bugs. Nope - the effort should be not to reinvent what we have, but to
> add functionality using the same blocks and structure as we have.
>
> I believe you learnt php from webERP - and are a living example as to why
> the phil-osophy behind webERP's development style is one of it's greatest
> strengths...
>
>  Phil
>
>
>
> Phil Daintree
>
> Logic Works Ltd - +64 (0)275 567890
>
> http://www.logicworks.co.nz
>
> On 02/09/14 13:12, Pak Ricard wrote:
>
>  Hi Phil:
>
>
>
> I saw with satisfaction the commit 6859 where Rafael used the TableRows()
> functions in some scripts. Now, I saw this change was reverted, and I can't
> see but good things about it (probably i'm missing something).
>
>
>
> These same 6 lines are repeated over and over webERP (probably over 100
> times), so if we get a change to reduce the number of lines and still get a
> readable script, I think it's worth it.
>
>
>
> Well just my 2 cents. I would love to know your POV (and any other
> developer's) about it :-)
>
>
>
> Regards,
>
> Ricard
>
>
>
>
>  ------------------------------------------------------------------------------
>
> Slashdot TV.
>
> Video for Nerds.  Stuff that matters.
>
> http://tv.slashdot.org/
>
>
>
>
>  _______________________________________________
>
> Web-erp-developers mailing list
>
> Web...@li...
>
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>
>
>
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>
>

Re: [WebERP-developers] TableRows()

[gilberto d. s. a. <gs...@gm...>]

+1 from me.

2014-09-09 21:51 GMT-03:00 Pak Ricard <pak...@gm...>:

> Hi all:
>
> Following on Andrew's POV, we calculate the demand of one item 10 times in
> webERP and it takes 94 lines of code (if I'm not wrong).
>
> I think it is a much readable script if we have a function called
> CalculateDemandForItem ($StockId, $Location) and we encapsulate the 94
> lines there.
>
> Sharing Andrew's <OPINION>, we save 9 * 94 lines of repeated code and we
> get a much readable script.
>
> There are dozens of similar situations in webERP, where I think we can
> improve readability and reduce the chances of bugs, as 1 fix fixes all.
>
> Hope we can find a reasonable point where all feel comfortable.
>
> Regards,
> Ricard
>
> 2014-09-09 3:48 GMT+08:00 Andrew Galuski <aga...@re...>:
>
>>  Would it be any different if the code was copied into an include
>> instead of a function and we replaced the lines of code with
>>
>> include('includes/tablerow.inc');
>>
>>
>>
>> This is what we do with header.inc and footer.inc.  We don’t repeat that
>> code in every script (Thank goodness).
>>
>>
>>
>> <OPINION>
>>
>> I think a minimal level of abstraction would make changes less daunting.
>> If I know I can concentrate on business logic and not formatting I would be
>> willing to make more enhancements.
>>
>> Enhancements might also be done more quickly, tested faster and be more
>> stable.  An example is a recent change to introduce location based security
>> to WebERP that I submitted.  I had seen in the forums multiple times people
>> looking to restrict access to locations within a particular business
>> function.  Example Warehouse worked can see inventory levels at Location A
>> but not Location B.  In order to make this change I had to modify  every
>> script where there was a location selection list.
>>
>> I had to modify the code as follows:
>>
>> BEFORE: $sql = "SELECT loccode, locationname FROM locations
>>
>> AFTER: $sql = "SELECT locations.loccode, locationname, canview FROM
>> locations
>>
>>                                 INNER JOIN locationusers ON
>> locationusers.loccode=locations.loccode AND locationusers.userid='" .
>> $_SESSION['UserID'] . "' AND locationusers.canview=1"
>>
>>
>>
>> That line alone appears like 50+ times in 50+ files.  The same code to
>> build the <select> takes around 15 lines of code before and after that SQL
>> that is nearly identical in every script.
>>
>> If all of that code was in an include file or in a function I could have
>> added a feature people requested in less than 1 day instead of 5 days.  And
>> testing it would have been a lot faster.  If the logic is in 1 place I can
>> test my change in < 5 screens be confident it is working.  If I have to
>> change 50 scripts I need to test all 50 scripts…Because even the smallest
>> typo can make a script break.
>>
>>
>>
>> Abstraction and reduced code can be a good thing
>>
>> </OPINION>
>>
>>
>>
>> Best Regards,
>>
>> Andrew
>>
>>
>>
>> *From:* Phil Daintree [mailto:ph...@lo...]
>> *Sent:* Tuesday, September 02, 2014 1:25 AM
>> *To:* webERP Developers
>> *Subject:* Re: [WebERP-developers] TableRows()
>>
>>
>>
>> Ricard,
>>
>> There are many many ways to reduce the amount of code in webERP - we
>> really could take loads out... but the sacrifice is readability - I don't
>> believe we would gain speed/efficiency.
>> If we made the tables a class as per Jonathan's idea we could take out
>> buckets of code - this would be the obvious extension of the
>> I don't want to change the code to increase abstraction ever - or code
>> that does the same thing a different way that could potentially introduce
>> new bugs. Nope - the effort should be not to reinvent what we have, but to
>> add functionality using the same blocks and structure as we have.
>>
>> I believe you learnt php from webERP - and are a living example as to why
>> the phil-osophy behind webERP's development style is one of it's greatest
>> strengths...
>>
>>  Phil
>>
>>
>>
>> Phil Daintree
>>
>> Logic Works Ltd - +64 (0)275 567890
>>
>> http://www.logicworks.co.nz
>>
>> On 02/09/14 13:12, Pak Ricard wrote:
>>
>>  Hi Phil:
>>
>>
>>
>> I saw with satisfaction the commit 6859 where Rafael used the TableRows()
>> functions in some scripts. Now, I saw this change was reverted, and I can't
>> see but good things about it (probably i'm missing something).
>>
>>
>>
>> These same 6 lines are repeated over and over webERP (probably over 100
>> times), so if we get a change to reduce the number of lines and still get a
>> readable script, I think it's worth it.
>>
>>
>>
>> Well just my 2 cents. I would love to know your POV (and any other
>> developer's) about it :-)
>>
>>
>>
>> Regards,
>>
>> Ricard
>>
>>
>>
>>
>>  ------------------------------------------------------------------------------
>>
>> Slashdot TV.
>>
>> Video for Nerds.  Stuff that matters.
>>
>> http://tv.slashdot.org/
>>
>>
>>
>>
>>  _______________________________________________
>>
>> Web-erp-developers mailing list
>>
>> Web...@li...
>>
>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Want excitement?
>> Manually upgrade your production database.
>> When you want reliability, choose Perforce
>> Perforce version control. Predictably reliable.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Web-erp-developers mailing list
>> Web...@li...
>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>>
>>
>
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>
>


-- 
gilberto dos santos alves
+55.11.98646-5049
sao paulo - sp - brasil

Re: [WebERP-developers] TableRows()

[<ph...@lo...>]

There are many places where we could increase abstraction and I agree 
there is a happy medium/compromise position, we have quite a bit and 
there is a lot of scope for more.
Of course Andrew and Ricard both have valid ideas.
I really don't want bugs introduced for the sake of abstraction.
Can we focus on new stuff?


Phil



On 2014-09-10 12:26, gilberto dos santos alves wrote:
> +1 from me.
> 
> 2014-09-09 21:51 GMT-03:00 Pak Ricard <pak...@gm...>:
> 
>> Hi all:
>> 
>> Following on Andrew's POV, we calculate the demand of one item 10
>> times in webERP and it takes 94 lines of code (if I'm not wrong).
>> 
>> I think it is a much readable script if we have a function called
>> CalculateDemandForItem ($StockId, $Location) and we encapsulate the
>> 94 lines there.
>> 
>> Sharing Andrew's <OPINION>, we save 9 * 94 lines of repeated code
>> and we get a much readable script.
>> 
>> There are dozens of similar situations in webERP, where I think we
>> can improve readability and reduce the chances of bugs, as 1 fix
>> fixes all.
>> 
>> Hope we can find a reasonable point where all feel comfortable.
>> 
>> Regards,
>> Ricard
>> 
>> 2014-09-09 3:48 GMT+08:00 Andrew Galuski <aga...@re...>:
>> 
>> Would it be any different if the code was copied into an include
>> instead of a function and we replaced the lines of code with
>> 
>> include('includes/tablerow.inc');
>> 
>> This is what we do with header.inc and footer.inc. We don’t
>> repeat that code in every script (Thank goodness).
>> 
>> <OPINION>
>> 
>> I think a minimal level of abstraction would make changes less
>> daunting. If I know I can concentrate on business logic and not
>> formatting I would be willing to make more enhancements.
>> 
>> Enhancements might also be done more quickly, tested faster and be
>> more stable. An example is a recent change to introduce location
>> based security to WebERP that I submitted. I had seen in the forums
>> multiple times people looking to restrict access to locations within
>> a particular business function. Example Warehouse worked can see
>> inventory levels at Location A but not Location B. In order to make
>> this change I had to modify every script where there was a location
>> selection list.
>> 
>> I had to modify the code as follows:
>> 
>> BEFORE: $sql = "SELECT loccode, locationname FROM locations
>> 
>> AFTER: $sql = "SELECT locations.loccode, locationname, canview FROM
>> locations
>> 
>> INNER JOIN locationusers ON
>> locationusers.loccode=locations.loccode AND locationusers.userid='"
>> . $_SESSION['UserID'] . "' AND locationusers.canview=1"
>> 
>> That line alone appears like 50+ times in 50+ files. The same code
>> to build the <select> takes around 15 lines of code before and after
>> that SQL that is nearly identical in every script.
>> 
>> If all of that code was in an include file or in a function I could
>> have added a feature people requested in less than 1 day instead of
>> 5 days. And testing it would have been a lot faster. If the logic
>> is in 1 place I can test my change in < 5 screens be confident it is
>> working. If I have to change 50 scripts I need to test all 50
>> scripts…Because even the smallest typo can make a script break.
>> 
>> Abstraction and reduced code can be a good thing
>> 
>> </OPINION>
>> 
>> Best Regards,
>> 
>> Andrew
>> 
>> FROM: Phil Daintree [mailto:ph...@lo...]
>> SENT: Tuesday, September 02, 2014 1:25 AM
>> TO: webERP Developers
>> SUBJECT: Re: [WebERP-developers] TableRows()
>> 
>> Ricard,
>> 
>> There are many many ways to reduce the amount of code in webERP -
>> we really could take loads out... but the sacrifice is readability -
>> I don't believe we would gain speed/efficiency.
>> If we made the tables a class as per Jonathan's idea we could take
>> out buckets of code - this would be the obvious extension of the
>> I don't want to change the code to increase abstraction ever - or
>> code that does the same thing a different way that could potentially
>> introduce new bugs. Nope - the effort should be not to reinvent what
>> we have, but to add functionality using the same blocks and
>> structure as we have.
>> 
>> I believe you learnt php from webERP - and are a living example as
>> to why the phil-osophy behind webERP's development style is one of
>> it's greatest strengths...
>> 
>> Phil
>> 
>> Phil Daintree
>> 
>> Logic Works Ltd - +64 (0)275 567890
>> 
>> http://www.logicworks.co.nz [1]
>> 
>> On 02/09/14 13:12, Pak Ricard wrote:
>> 
>> Hi Phil:
>> 
>> I saw with satisfaction the commit 6859 where Rafael used the
>> TableRows() functions in some scripts. Now, I saw this change was
>> reverted, and I can't see but good things about it (probably i'm
>> missing something).
>> 
>> These same 6 lines are repeated over and over webERP (probably over
>> 100 times), so if we get a change to reduce the number of lines and
>> still get a readable script, I think it's worth it.
>> 
>> Well just my 2 cents. I would love to know your POV (and any other
>> developer's) about it :-)
>> 
>> Regards,
>> 
>> Ricard
>> 
>> 
> ------------------------------------------------------------------------------
>> 
>> Slashdot TV.
>> 
>> Video for Nerds. Stuff that matters.
>> 
>> http://tv.slashdot.org/ [2]
>> 
>> _______________________________________________
>> 
>> Web-erp-developers mailing list
>> 
>> Web...@li...
>> 
>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers [3]
>> 
>> 
> ------------------------------------------------------------------------------
>> Want excitement?
>> Manually upgrade your production database.
>> When you want reliability, choose Perforce
>> Perforce version control. Predictably reliable.
>> 
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
>> [4]
>> _______________________________________________
>> Web-erp-developers mailing list
>> Web...@li...
>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers [3]
> 
> ------------------------------------------------------------------------------
>  Want excitement?
>  Manually upgrade your production database.
>  When you want reliability, choose Perforce
>  Perforce version control. Predictably reliable.
>  
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> [4]
> _______________________________________________
>  Web-erp-developers mailing list
>  Web...@li...
>  https://lists.sourceforge.net/lists/listinfo/web-erp-developers [3]
> 
> --
> gilberto dos santos alves
> +55.11.98646-5049
> sao paulo - sp - brasil
> 
> 
> 
> Links:
> ------
> [1] http://www.logicworks.co.nz
> [2] http://tv.slashdot.org/
> [3] https://lists.sourceforge.net/lists/listinfo/web-erp-developers
> [4]
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&amp;iu=/4140/ostg.clktrk
> 
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> 
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers

Re: [WebERP-developers] TableRows()

[ExsonQu <hex...@gm...>]

*Dear all,*

           I agree with Phil that we should pay more attention to those old
codes' (or called redundant?). The abstraction to avoid have at least some
merit that:
           1. If there is a bug in the code, it's very clear. 
           2. I believe in most of time, it's fast. 
           3. If we change these tested stable codes, it becomes green code.
It introduce new risk to our users.
           4. And most of the time, it sacrifice the readability. Because we
have to understand a new definition which seems intuitive to the author but
others have to study it. 

          I think most of the time, I don't like the code style of webERP
because I cannot code fast. Its a hand-make style and not economic. But the
style make those codes reliable and robust and fast. And it's very easy to
modify what you need to do is just to search those strings you need. 

          So lets focus on adding new features instead of those existed
codes or the coding convention, IMHO.

          Best regards!

          Exson

          
          

            

          



--
View this message in context: http://weberp-accounting.1478800.n4.nabble.com/TableRows-tp4657615p4657634.html
Sent from the web-ERP-developers mailing list archive at Nabble.com.

Re: [WebERP-developers] TableRows()

[Pak R. <pak...@gm...>]

Hi all:

Agree that we need to focus in new stuff, but also think that we mostly
create new stuff based on current scripts, so the better (readable and
short) they are, the better and faster  we can create new stuff and the
test will be easily done.
As Phil pointed out, I learned PHP with webERP (I am computer engineer, so
I had some background), but I bet 90% of developers find easier to
understand a script of 300 lines instead of one of 600

Well, we should move ahead, but the initial reason of this thread is still
there:
Should Rafael's work on TableRows be accepted or not?
When we find something like the CalculateDemand (i just had to create
another script using demand), should we create the function and "clean up"
some scripts so they use the abstraction? or will the job be rejected?

I think we the developers should know, and avoid the frustrating part of
spending some time in a commit to see it reverted and not useful.



Regards,
Ricard

2014-09-11 10:39 GMT+08:00 ExsonQu <hex...@gm...>:

> *Dear all,*
>
>            I agree with Phil that we should pay more attention to those old
> codes' (or called redundant?). The abstraction to avoid have at least some
> merit that:
>            1. If there is a bug in the code, it's very clear.
>            2. I believe in most of time, it's fast.
>            3. If we change these tested stable codes, it becomes green
> code.
> It introduce new risk to our users.
>            4. And most of the time, it sacrifice the readability. Because
> we
> have to understand a new definition which seems intuitive to the author but
> others have to study it.
>
>           I think most of the time, I don't like the code style of webERP
> because I cannot code fast. Its a hand-make style and not economic. But the
> style make those codes reliable and robust and fast. And it's very easy to
> modify what you need to do is just to search those strings you need.
>
>           So lets focus on adding new features instead of those existed
> codes or the coding convention, IMHO.
>
>           Best regards!
>
>           Exson
>
>
>
>
>
>
>
>
>
>
> --
> View this message in context:
> http://weberp-accounting.1478800.n4.nabble.com/TableRows-tp4657615p4657634.html
> Sent from the web-ERP-developers mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>

Re: [WebERP-developers] TableRows()

[Jonathan (T. <th...@ic...>]

My view, would be to take the same approach as the Table class that I've
built (sorry for taking so long to finalize development, life has it's
complications)! Each table from weberp should have a class associated, with
functions to modify the table. That way we remove all direct queries from
the main files, and put it in classes. By doing this for everything, and
giving one file per class, (especially if we use an autoloader so that the
class name is the same as the file name) we make it very obvious where the
code is coming from, while at the same time abstracting the code,
amplifying re-use. I can commit an example of that this weekend to the
working branch if people are interested.

On 11 September 2014 10:03, Pak Ricard <pak...@gm...> wrote:

> Hi all:
>
> Agree that we need to focus in new stuff, but also think that we mostly
> create new stuff based on current scripts, so the better (readable and
> short) they are, the better and faster  we can create new stuff and the
> test will be easily done.
> As Phil pointed out, I learned PHP with webERP (I am computer engineer, so
> I had some background), but I bet 90% of developers find easier to
> understand a script of 300 lines instead of one of 600
>
> Well, we should move ahead, but the initial reason of this thread is still
> there:
> Should Rafael's work on TableRows be accepted or not?
> When we find something like the CalculateDemand (i just had to create
> another script using demand), should we create the function and "clean up"
> some scripts so they use the abstraction? or will the job be rejected?
>
> I think we the developers should know, and avoid the frustrating part of
> spending some time in a commit to see it reverted and not useful.
>
>
>
> Regards,
> Ricard
>
> 2014-09-11 10:39 GMT+08:00 ExsonQu <hex...@gm...>:
>
>> *Dear all,*
>>
>>            I agree with Phil that we should pay more attention to those
>> old
>> codes' (or called redundant?). The abstraction to avoid have at least some
>> merit that:
>>            1. If there is a bug in the code, it's very clear.
>>            2. I believe in most of time, it's fast.
>>            3. If we change these tested stable codes, it becomes green
>> code.
>> It introduce new risk to our users.
>>            4. And most of the time, it sacrifice the readability. Because
>> we
>> have to understand a new definition which seems intuitive to the author
>> but
>> others have to study it.
>>
>>           I think most of the time, I don't like the code style of webERP
>> because I cannot code fast. Its a hand-make style and not economic. But
>> the
>> style make those codes reliable and robust and fast. And it's very easy to
>> modify what you need to do is just to search those strings you need.
>>
>>           So lets focus on adding new features instead of those existed
>> codes or the coding convention, IMHO.
>>
>>           Best regards!
>>
>>           Exson
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://weberp-accounting.1478800.n4.nabble.com/TableRows-tp4657615p4657634.html
>> Sent from the web-ERP-developers mailing list archive at Nabble.com.
>>
>>
>> ------------------------------------------------------------------------------
>> Want excitement?
>> Manually upgrade your production database.
>> When you want reliability, choose Perforce
>> Perforce version control. Predictably reliable.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Web-erp-developers mailing list
>> Web...@li...
>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>>
>
>
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>
>

Re: [WebERP-developers] TableRows()

[Phil D. <ph...@lo...>]

 > I bet 90% of developers find easier to understand a script of 300 
lines instead of one of 600

Well the thing is we are really not talking about reducing the amount of 
code to understand - we are talking about dotting it around in a 
multitude of new files. You still need to understand the 600 lines - but 
now you have to open 30 files to identify where it is .... actually MUCH 
more difficult IMHO - maybe we must agree to differ.

We would have a bunch of functions that you have no idea in which file 
to even find them - grep is the best bet before you can even find the 
code. Alternatively we have a load of includes which at least we know 
where the code is.

Yes we have the advantage that we can reuse these functions and includes 
and we can write the code once - but in many cases the code is actually 
slightly different so we end up with a multitude of ifs to accommodate 
the different uses for the similar code.

Where there are serious reuse possibilities then please do discuss your 
proposal with me first.

See http://www.weberp.org/Development.html

*1.*Join the developers me ailing list.

http://lists.sourceforge.net/lists/listinfo/web-erp-developers

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. Alternatively, there is a section on 
the webERP forum for posting development specifications for what you 
propose to do.

Of course, if I have any concerns about a proposal then I will chime in.

Phil

Phil Daintree
Logic Works Ltd - +64 (0)275 567890
http://www.logicworks.co.nz

On 11/09/14 15:03, Pak Ricard wrote:
> Hi all:
>
> Agree that we need to focus in new stuff, but also think that we 
> mostly create new stuff based on current scripts, so the better 
> (readable and short) they are, the better and faster  we can create 
> new stuff and the test will be easily done.
> As Phil pointed out, I learned PHP with webERP (I am computer 
> engineer, so I had some background), but I bet 90% of developers find 
> easier to understand a script of 300 lines instead of one of 600
>
> Well, we should move ahead, but the initial reason of this thread is 
> still there:
> Should Rafael's work on TableRows be accepted or not?
> When we find something like the CalculateDemand (i just had to create 
> another script using demand), should we create the function and "clean 
> up" some scripts so they use the abstraction? or will the job be 
> rejected?
>
> I think we the developers should know, and avoid the frustrating part 
> of spending some time in a commit to see it reverted and not useful.
>
>
>
> Regards,
> Ricard
>
> 2014-09-11 10:39 GMT+08:00 ExsonQu <hex...@gm... 
> <mailto:hex...@gm...>>:
>
>     *Dear all,*
>
>                I agree with Phil that we should pay more attention to
>     those old
>     codes' (or called redundant?). The abstraction to avoid have at
>     least some
>     merit that:
>                1. If there is a bug in the code, it's very clear.
>                2. I believe in most of time, it's fast.
>                3. If we change these tested stable codes, it becomes
>     green code.
>     It introduce new risk to our users.
>                4. And most of the time, it sacrifice the readability.
>     Because we
>     have to understand a new definition which seems intuitive to the
>     author but
>     others have to study it.
>
>               I think most of the time, I don't like the code style of
>     webERP
>     because I cannot code fast. Its a hand-make style and not
>     economic. But the
>     style make those codes reliable and robust and fast. And it's very
>     easy to
>     modify what you need to do is just to search those strings you need.
>
>               So lets focus on adding new features instead of those
>     existed
>     codes or the coding convention, IMHO.
>
>               Best regards!
>
>               Exson
>
>
>
>
>
>
>
>
>
>
>     --
>     View this message in context:
>     http://weberp-accounting.1478800.n4.nabble.com/TableRows-tp4657615p4657634.html
>     Sent from the web-ERP-developers mailing list archive at Nabble.com.
>
>     ------------------------------------------------------------------------------
>     Want excitement?
>     Manually upgrade your production database.
>     When you want reliability, choose Perforce
>     Perforce version control. Predictably reliable.
>     http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
>     _______________________________________________
>     Web-erp-developers mailing list
>     Web...@li...
>     <mailto:Web...@li...>
>     https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>
>
>
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers

Re: [WebERP-developers] TableRows()

[<ph...@lo...>]

Preferable for really high use code as the user knows where to find it. 
I like to keep includes to a minimum too though. Some repetition of the 
code is a consequence ... I accept this of course.

Phil

On 2014-09-08 13:48, Andrew Galuski wrote:
> Would it be any different if the code was copied into an include
> instead of a function and we replaced the lines of code with
> 
> include('includes/tablerow.inc');
> 
> This is what we do with header.inc and footer.inc. We don't repeat
> that code in every script (Thank goodness).
> 
> <OPINION>
> 
> I think a minimal level of abstraction would make changes less
> daunting. If I know I can concentrate on business logic and not
> formatting I would be willing to make more enhancements.
> 
> Enhancements might also be done more quickly, tested faster and be
> more stable. An example is a recent change to introduce location based
> security to WebERP that I submitted. I had seen in the forums multiple
> times people looking to restrict access to locations within a
> particular business function. Example Warehouse worked can see
> inventory levels at Location A but not Location B. In order to make
> this change I had to modify every script where there was a location
> selection list.
> 
> I had to modify the code as follows:
> 
> BEFORE: $sql = "SELECT loccode, locationname FROM locations
> 
> AFTER: $sql = "SELECT locations.loccode, locationname, canview FROM
> locations
> 
>  INNER JOIN locationusers ON locationusers.loccode=locations.loccode
> AND locationusers.userid='" . $_SESSION['UserID'] . "' AND
> locationusers.canview=1"
> 
> That line alone appears like 50+ times in 50+ files. The same code to
> build the <select> takes around 15 lines of code before and after that
> SQL that is nearly identical in every script.
> 
> If all of that code was in an include file or in a function I could
> have added a feature people requested in less than 1 day instead of 5
> days. And testing it would have been a lot faster. If the logic is in
> 1 place I can test my change in < 5 screens be confident it is
> working. If I have to change 50 scripts I need to test all 50
> scripts…Because even the smallest typo can make a script break.
> 
> Abstraction and reduced code can be a good thing
> 
> </OPINION>
> 
> Best Regards,
> 
> Andrew
> 
> FROM: Phil Daintree [mailto:ph...@lo...]
>  SENT: Tuesday, September 02, 2014 1:25 AM
>  TO: webERP Developers
>  SUBJECT: Re: [WebERP-developers] TableRows()
> 
> Ricard,
> 
>  There are many many ways to reduce the amount of code in webERP - we
> really could take loads out... but the sacrifice is readability - I
> don't believe we would gain speed/efficiency.
>  If we made the tables a class as per Jonathan's idea we could take
> out buckets of code - this would be the obvious extension of the
>  I don't want to change the code to increase abstraction ever - or
> code that does the same thing a different way that could potentially
> introduce new bugs. Nope - the effort should be not to reinvent what
> we have, but to add functionality using the same blocks and structure
> as we have.
> 
>  I believe you learnt php from webERP - and are a living example as to
> why the phil-osophy behind webERP's development style is one of it's
> greatest strengths...
> 
> Phil
> 
> Phil Daintree
> 
> Logic Works Ltd - +64 (0)275 567890
> 
> http://www.logicworks.co.nz [3]
> 
> On 02/09/14 13:12, Pak Ricard wrote:
> 
>> Hi Phil:
>> 
>> I saw with satisfaction the commit 6859 where Rafael used the
>> TableRows() functions in some scripts. Now, I saw this change was
>> reverted, and I can't see but good things about it (probably i'm
>> missing something).
>> 
>> These same 6 lines are repeated over and over webERP (probably over
>> 100 times), so if we get a change to reduce the number of lines and
>> still get a readable script, I think it's worth it.
>> 
>> Well just my 2 cents. I would love to know your POV (and any other
>> developer's) about it :-)
>> 
>> Regards,
>> 
>> Ricard
>> 
>> 
> ------------------------------------------------------------------------------
>> 
>> Slashdot TV.
>> 
>> Video for Nerds. Stuff that matters.
>> 
>> http://tv.slashdot.org/ [1]
>> 
>> _______________________________________________
>> 
>> Web-erp-developers mailing list
>> 
>> Web...@li...
>> 
>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers [2]
> 
> 
> 
> Links:
> ------
> [1] http://tv.slashdot.org/
> [2] https://lists.sourceforge.net/lists/listinfo/web-erp-developers
> [3] http://www.logicworks.co.nz
> 
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce
> Perforce version control. Predictably reliable.
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> 
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers

Re: [WebERP-developers] TableRows()

[Pak R. <pak...@gm...>]

Hi Phil:

Sorry I didn't understand. Is it finally OK to use functions / includes as
in the case of TableRows()?

If so, when should we use include or function?

Also, I found Tim's proposal for PrintARowOfTable() a really interesing
one. I'm particularly lost with html (which is way more cryptic than PHP),
so, if we can encapsulate some highly used part of code (as printing a row
of a table), I would be really happy.

I also think, the shorter the code, the easier it is to understand, if all
functions have a clear and long enough name.

Regards,
Ricard

2014-09-09 9:24 GMT+08:00 <ph...@lo...>:

> Preferable for really high use code as the user knows where to find it.
> I like to keep includes to a minimum too though. Some repetition of the
> code is a consequence ... I accept this of course.
>
> Phil
>
> On 2014-09-08 13:48, Andrew Galuski wrote:
> > Would it be any different if the code was copied into an include
> > instead of a function and we replaced the lines of code with
> >
> > include('includes/tablerow.inc');
> >
> > This is what we do with header.inc and footer.inc. We don't repeat
> > that code in every script (Thank goodness).
> >
> > <OPINION>
> >
> > I think a minimal level of abstraction would make changes less
> > daunting. If I know I can concentrate on business logic and not
> > formatting I would be willing to make more enhancements.
> >
> > Enhancements might also be done more quickly, tested faster and be
> > more stable. An example is a recent change to introduce location based
> > security to WebERP that I submitted. I had seen in the forums multiple
> > times people looking to restrict access to locations within a
> > particular business function. Example Warehouse worked can see
> > inventory levels at Location A but not Location B. In order to make
> > this change I had to modify every script where there was a location
> > selection list.
> >
> > I had to modify the code as follows:
> >
> > BEFORE: $sql = "SELECT loccode, locationname FROM locations
> >
> > AFTER: $sql = "SELECT locations.loccode, locationname, canview FROM
> > locations
> >
> >  INNER JOIN locationusers ON locationusers.loccode=locations.loccode
> > AND locationusers.userid='" . $_SESSION['UserID'] . "' AND
> > locationusers.canview=1"
> >
> > That line alone appears like 50+ times in 50+ files. The same code to
> > build the <select> takes around 15 lines of code before and after that
> > SQL that is nearly identical in every script.
> >
> > If all of that code was in an include file or in a function I could
> > have added a feature people requested in less than 1 day instead of 5
> > days. And testing it would have been a lot faster. If the logic is in
> > 1 place I can test my change in < 5 screens be confident it is
> > working. If I have to change 50 scripts I need to test all 50
> > scripts…Because even the smallest typo can make a script break.
> >
> > Abstraction and reduced code can be a good thing
> >
> > </OPINION>
> >
> > Best Regards,
> >
> > Andrew
> >
> > FROM: Phil Daintree [mailto:ph...@lo...]
> >  SENT: Tuesday, September 02, 2014 1:25 AM
> >  TO: webERP Developers
> >  SUBJECT: Re: [WebERP-developers] TableRows()
> >
> > Ricard,
> >
> >  There are many many ways to reduce the amount of code in webERP - we
> > really could take loads out... but the sacrifice is readability - I
> > don't believe we would gain speed/efficiency.
> >  If we made the tables a class as per Jonathan's idea we could take
> > out buckets of code - this would be the obvious extension of the
> >  I don't want to change the code to increase abstraction ever - or
> > code that does the same thing a different way that could potentially
> > introduce new bugs. Nope - the effort should be not to reinvent what
> > we have, but to add functionality using the same blocks and structure
> > as we have.
> >
> >  I believe you learnt php from webERP - and are a living example as to
> > why the phil-osophy behind webERP's development style is one of it's
> > greatest strengths...
> >
> > Phil
> >
> > Phil Daintree
> >
> > Logic Works Ltd - +64 (0)275 567890
> >
> > http://www.logicworks.co.nz [3]
> >
> > On 02/09/14 13:12, Pak Ricard wrote:
> >
> >> Hi Phil:
> >>
> >> I saw with satisfaction the commit 6859 where Rafael used the
> >> TableRows() functions in some scripts. Now, I saw this change was
> >> reverted, and I can't see but good things about it (probably i'm
> >> missing something).
> >>
> >> These same 6 lines are repeated over and over webERP (probably over
> >> 100 times), so if we get a change to reduce the number of lines and
> >> still get a readable script, I think it's worth it.
> >>
> >> Well just my 2 cents. I would love to know your POV (and any other
> >> developer's) about it :-)
> >>
> >> Regards,
> >>
> >> Ricard
> >>
> >>
> >
> ------------------------------------------------------------------------------
> >>
> >> Slashdot TV.
> >>
> >> Video for Nerds. Stuff that matters.
> >>
> >> http://tv.slashdot.org/ [1]
> >>
> >> _______________________________________________
> >>
> >> Web-erp-developers mailing list
> >>
> >> Web...@li...
> >>
> >> https://lists.sourceforge.net/lists/listinfo/web-erp-developers [2]
> >
> >
> >
> > Links:
> > ------
> > [1] http://tv.slashdot.org/
> > [2] https://lists.sourceforge.net/lists/listinfo/web-erp-developers
> > [3] http://www.logicworks.co.nz
> >
> >
> ------------------------------------------------------------------------------
> > Want excitement?
> > Manually upgrade your production database.
> > When you want reliability, choose Perforce
> > Perforce version control. Predictably reliable.
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> >
> > _______________________________________________
> > Web-erp-developers mailing list
> > Web...@li...
> > https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>
>
> ------------------------------------------------------------------------------
> Want excitement?
> Manually upgrade your production database.
> When you want reliability, choose Perforce.
> Perforce version control. Predictably reliable.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>