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
>
>