Javascript clean up and improvements

[Amardeep Singh Jhajj-2]

Hello everyone,

Currently, OFBiz javascript code (except third party libraries) is not
written with the best practices which can cause following problems -

1. Increases the code maintenance effort.
2. Impact page performance.
3. Present not good examples to new contributors which leads to C/P to
various areas of js code.

Here are things we should do for cleanup and improvements in js code.

1. Remove unused javascript code and files if any.
2. Use best practices for javascript coding to improve performance (I have
listed some of it below).
3. Move utility js functions to one js file.
4. Remove deprecated code and use latest. For ex: We are still using
"language='javascript'" attribute at script tag which is deprecated a years
ago.
5. js should be loaded at bottom of the page, currently its in Header. Its
a tedious task now to move it into footer because we have lot of js code
inline in ftls.
6. js should not be written inline, it should be enough generic to be in
minimum number of files and have generic code for doing the common set of
operations over DOM.
7. Currently our macros of rendering pages has inline scripts, they can be
moved to one macrorenderer.js with generic code as we can use classes, ids
and data-attributes for doing any operation over html DOM.
8. After all cleanup work, we can think of build tool (like grunt) for
various javascript build tasks (minification, concatenation of files) if
needed. Its just a thought.

I know its a huge effort and need to be done carefully. So before doing any
major changes, I would like to start work with first 4 points.

Here is the list of some best practices to start with:

1. Use [] Instead of New Array()
2. Long list of variables? Omit the "Var" keyword and use commas instead.
3. Reduce global variables
4. Use explicit blocks
5. Start blocks on the same line
6. Always, Always Use Semicolons - Having said that, this is a very bad
practice that can potentially lead to much bigger, and harder to find,
issues.
7. Optimize loops. Avoid calculating the length of array in for loop
iteration.
8. Avoid multiple redundant jQuery DOM manupulation by saving reference to
any object.
9. Try to use meaningful comments.
10. Many more.

Here are some links of best practices information-

https://www.w3.org/wiki/JavaScript_best_practices
http://www.codeproject.com/Articles/580165/JavaScript-Best-Practices
https://developer.yahoo.com/performance/rules.html

If everyone agrees, I would like to start on this work.

Please let me know your thoughts on it.

Thanks and Regards
--
Amardeep Singh Jhajj

[taher]

Hi Amardeep,

In my opinion, the absolute best thing you can do for JavaScript is to run
it through jslint. If you are serious about the work, I would suggest you
take all the JavaScript files and snippets inside FTL files and run them
inside jslint and fix the issues one by one. That would automatically
include best practices from what I consider the king of JavaScript: Douglas
Crockford.

my 2 cents

Taher Alkhateeb

On Friday, 24 June 2016, Amardeep Singh Jhajj <
[hidden email]> wrote:

> Hello everyone,
>
> Currently, OFBiz javascript code (except third party libraries) is not
> written with the best practices which can cause following problems -
>
> 1. Increases the code maintenance effort.
> 2. Impact page performance.
> 3. Present not good examples to new contributors which leads to C/P to
> various areas of js code.
>
> Here are things we should do for cleanup and improvements in js code.
>
> 1. Remove unused javascript code and files if any.
> 2. Use best practices for javascript coding to improve performance (I have
> listed some of it below).
> 3. Move utility js functions to one js file.
> 4. Remove deprecated code and use latest. For ex: We are still using
> "language='javascript'" attribute at script tag which is deprecated a years
> ago.
> 5. js should be loaded at bottom of the page, currently its in Header. Its
> a tedious task now to move it into footer because we have lot of js code
> inline in ftls.
> 6. js should not be written inline, it should be enough generic to be in
> minimum number of files and have generic code for doing the common set of
> operations over DOM.
> 7. Currently our macros of rendering pages has inline scripts, they can be
> moved to one macrorenderer.js with generic code as we can use classes, ids
> and data-attributes for doing any operation over html DOM.
> 8. After all cleanup work, we can think of build tool (like grunt) for
> various javascript build tasks (minification, concatenation of files) if
> needed. Its just a thought.
>
> I know its a huge effort and need to be done carefully. So before doing any
> major changes, I would like to start work with first 4 points.
>
> Here is the list of some best practices to start with:
>
> 1. Use [] Instead of New Array()
> 2. Long list of variables? Omit the "Var" keyword and use commas instead.
> 3. Reduce global variables
> 4. Use explicit blocks
> 5. Start blocks on the same line
> 6. Always, Always Use Semicolons - Having said that, this is a very bad
> practice that can potentially lead to much bigger, and harder to find,
> issues.
> 7. Optimize loops. Avoid calculating the length of array in for loop
> iteration.
> 8. Avoid multiple redundant jQuery DOM manupulation by saving reference to
> any object.
> 9. Try to use meaningful comments.
> 10. Many more.
>
> Here are some links of best practices information-
>
> https://www.w3.org/wiki/JavaScript_best_practices
> http://www.codeproject.com/Articles/580165/JavaScript-Best-Practices
> https://developer.yahoo.com/performance/rules.html
>
> If everyone agrees, I would like to start on this work.
>
> Please let me know your thoughts on it.
>
> Thanks and Regards
> --
> Amardeep Singh Jhajj
>

[taher]

and +1 for your recommendations

On Friday, 24 June 2016, Amardeep Singh Jhajj <
[hidden email]> wrote:

> Hello everyone,
>
> Currently, OFBiz javascript code (except third party libraries) is not
> written with the best practices which can cause following problems -
>
> 1. Increases the code maintenance effort.
> 2. Impact page performance.
> 3. Present not good examples to new contributors which leads to C/P to
> various areas of js code.
>
> Here are things we should do for cleanup and improvements in js code.
>
> 1. Remove unused javascript code and files if any.
> 2. Use best practices for javascript coding to improve performance (I have
> listed some of it below).
> 3. Move utility js functions to one js file.
> 4. Remove deprecated code and use latest. For ex: We are still using
> "language='javascript'" attribute at script tag which is deprecated a years
> ago.
> 5. js should be loaded at bottom of the page, currently its in Header. Its
> a tedious task now to move it into footer because we have lot of js code
> inline in ftls.
> 6. js should not be written inline, it should be enough generic to be in
> minimum number of files and have generic code for doing the common set of
> operations over DOM.
> 7. Currently our macros of rendering pages has inline scripts, they can be
> moved to one macrorenderer.js with generic code as we can use classes, ids
> and data-attributes for doing any operation over html DOM.
> 8. After all cleanup work, we can think of build tool (like grunt) for
> various javascript build tasks (minification, concatenation of files) if
> needed. Its just a thought.
>
> I know its a huge effort and need to be done carefully. So before doing any
> major changes, I would like to start work with first 4 points.
>
> Here is the list of some best practices to start with:
>
> 1. Use [] Instead of New Array()
> 2. Long list of variables? Omit the "Var" keyword and use commas instead.
> 3. Reduce global variables
> 4. Use explicit blocks
> 5. Start blocks on the same line
> 6. Always, Always Use Semicolons - Having said that, this is a very bad
> practice that can potentially lead to much bigger, and harder to find,
> issues.
> 7. Optimize loops. Avoid calculating the length of array in for loop
> iteration.
> 8. Avoid multiple redundant jQuery DOM manupulation by saving reference to
> any object.
> 9. Try to use meaningful comments.
> 10. Many more.
>
> Here are some links of best practices information-
>
> https://www.w3.org/wiki/JavaScript_best_practices
> http://www.codeproject.com/Articles/580165/JavaScript-Best-Practices
> https://developer.yahoo.com/performance/rules.html
>
> If everyone agrees, I would like to start on this work.
>
> Please let me know your thoughts on it.
>
> Thanks and Regards
> --
> Amardeep Singh Jhajj
>

[Pranay Pandey-3]

+1 for the recommendation Amardeep.

Best regards,

Pranay Pandey
HotWax Systems
http://www.hotwaxsystems.com/

On Fri, Jun 24, 2016 at 12:50 PM, Amardeep Singh Jhajj <
[hidden email]> wrote:

> Hello everyone,
>
> Currently, OFBiz javascript code (except third party libraries) is not
> written with the best practices which can cause following problems -
>
> 1. Increases the code maintenance effort.
> 2. Impact page performance.
> 3. Present not good examples to new contributors which leads to C/P to
> various areas of js code.
>
> Here are things we should do for cleanup and improvements in js code.
>
> 1. Remove unused javascript code and files if any.
> 2. Use best practices for javascript coding to improve performance (I have
> listed some of it below).
> 3. Move utility js functions to one js file.
> 4. Remove deprecated code and use latest. For ex: We are still using
> "language='javascript'" attribute at script tag which is deprecated a years
> ago.
> 5. js should be loaded at bottom of the page, currently its in Header. Its
> a tedious task now to move it into footer because we have lot of js code
> inline in ftls.
> 6. js should not be written inline, it should be enough generic to be in
> minimum number of files and have generic code for doing the common set of
> operations over DOM.
> 7. Currently our macros of rendering pages has inline scripts, they can be
> moved to one macrorenderer.js with generic code as we can use classes, ids
> and data-attributes for doing any operation over html DOM.
> 8. After all cleanup work, we can think of build tool (like grunt) for
> various javascript build tasks (minification, concatenation of files) if
> needed. Its just a thought.
>
> I know its a huge effort and need to be done carefully. So before doing any
> major changes, I would like to start work with first 4 points.
>
> Here is the list of some best practices to start with:
>
> 1. Use [] Instead of New Array()
> 2. Long list of variables? Omit the "Var" keyword and use commas instead.
> 3. Reduce global variables
> 4. Use explicit blocks
> 5. Start blocks on the same line
> 6. Always, Always Use Semicolons - Having said that, this is a very bad
> practice that can potentially lead to much bigger, and harder to find,
> issues.
> 7. Optimize loops. Avoid calculating the length of array in for loop
> iteration.
> 8. Avoid multiple redundant jQuery DOM manupulation by saving reference to
> any object.
> 9. Try to use meaningful comments.
> 10. Many more.
>
> Here are some links of best practices information-
>
> https://www.w3.org/wiki/JavaScript_best_practices
> http://www.codeproject.com/Articles/580165/JavaScript-Best-Practices
> https://developer.yahoo.com/performance/rules.html
>
> If everyone agrees, I would like to start on this work.
>
> Please let me know your thoughts on it.
>
> Thanks and Regards
> --
> Amardeep Singh Jhajj
>

[Deepak Dixit-3]

Hi Amardeep,

I agree with you current js code is not written as per the best practice.
Here are some inputs from my side.
Please see comments inline:



On Fri, Jun 24, 2016 at 12:50 PM, Amardeep Singh Jhajj <
[hidden email]> wrote:

> Hello everyone,
>
> Currently, OFBiz javascript code (except third party libraries) is not
> written with the best practices which can cause following problems -
>
> 1. Increases the code maintenance effort.
> 2. Impact page performance.
> 3. Present not good examples to new contributors which leads to C/P to
> various areas of js code.
>
> Here are things we should do for cleanup and improvements in js code.
>
>

Here is the existing ticket for same:
https://issues.apache.org/jira/browse/OFBIZ-1319


> 1. Remove unused javascript code and files if any.
> 2. Use best practices for javascript coding to improve performance (I have
> listed some of it below).
> 3. Move utility js functions to one js file.

4. Remove deprecated code and use latest. For ex: We are still using
> "language='javascript'" attribute at script tag which is deprecated a years
> ago.

5. js should be loaded at bottom of the page, currently its in Header. Its
> a tedious task now to move it into footer because we have lot of js code
> inline in ftls.
>


We can't load all js file at bottom, library file should be loaded at top
and utility and other js can be loaded at bottom on screen.



> 6. js should not be written inline, it should be enough generic to be in
> minimum number of files and have generic code for doing the common set of
> operations over DOM.

7. Currently our macros of rendering pages has inline scripts, they can be
> moved to one macrorenderer.js with generic code as we can use classes, ids
> and data-attributes for doing any operation over html DOM.

8. After all cleanup work, we can think of build tool (like grunt) for

> various javascript build tasks (minification, concatenation of files) if
> needed. Its just a thought.
>
> I know its a huge effort and need to be done carefully. So before doing any
> major changes, I would like to start work with first 4 points.
>
> Here is the list of some best practices to start with:
>
> 1. Use [] Instead of New Array()
> 2. Long list of variables? Omit the "Var" keyword and use commas instead.
> 3. Reduce global variables
> 4. Use explicit blocks
> 5. Start blocks on the same line
> 6. Always, Always Use Semicolons - Having said that, this is a very bad
> practice that can potentially lead to much bigger, and harder to find,
> issues.
> 7. Optimize loops. Avoid calculating the length of array in for loop
> iteration.
> 8. Avoid multiple redundant jQuery DOM manupulation by saving reference to
> any object.
> 9. Try to use meaningful comments.
> 10. Many more.
>
> Here are some links of best practices information-
>
> https://www.w3.org/wiki/JavaScript_best_practices
> http://www.codeproject.com/Articles/580165/JavaScript-Best-Practices
> https://developer.yahoo.com/performance/rules.html
>
> If everyone agrees, I would like to start on this work.
>
> Please let me know your thoughts on it.
>
> Thanks and Regards
> --
> Amardeep Singh Jhajj
>

We can use html5 based data element as well in js to remove inline
scripting.


Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com

[Divesh Dutta-2]

+1 Amardeep.


Thanks
--
Divesh Dutta.

On Fri, Jun 24, 2016 at 12:50 PM, Amardeep Singh Jhajj <
[hidden email]> wrote:

> Hello everyone,
>
> Currently, OFBiz javascript code (except third party libraries) is not
> written with the best practices which can cause following problems -
>
> 1. Increases the code maintenance effort.
> 2. Impact page performance.
> 3. Present not good examples to new contributors which leads to C/P to
> various areas of js code.
>
> Here are things we should do for cleanup and improvements in js code.
>
> 1. Remove unused javascript code and files if any.
> 2. Use best practices for javascript coding to improve performance (I have
> listed some of it below).
> 3. Move utility js functions to one js file.
> 4. Remove deprecated code and use latest. For ex: We are still using
> "language='javascript'" attribute at script tag which is deprecated a years
> ago.
> 5. js should be loaded at bottom of the page, currently its in Header. Its
> a tedious task now to move it into footer because we have lot of js code
> inline in ftls.
> 6. js should not be written inline, it should be enough generic to be in
> minimum number of files and have generic code for doing the common set of
> operations over DOM.
> 7. Currently our macros of rendering pages has inline scripts, they can be
> moved to one macrorenderer.js with generic code as we can use classes, ids
> and data-attributes for doing any operation over html DOM.
> 8. After all cleanup work, we can think of build tool (like grunt) for
> various javascript build tasks (minification, concatenation of files) if
> needed. Its just a thought.
>
> I know its a huge effort and need to be done carefully. So before doing any
> major changes, I would like to start work with first 4 points.
>
> Here is the list of some best practices to start with:
>
> 1. Use [] Instead of New Array()
> 2. Long list of variables? Omit the "Var" keyword and use commas instead.
> 3. Reduce global variables
> 4. Use explicit blocks
> 5. Start blocks on the same line
> 6. Always, Always Use Semicolons - Having said that, this is a very bad
> practice that can potentially lead to much bigger, and harder to find,
> issues.
> 7. Optimize loops. Avoid calculating the length of array in for loop
> iteration.
> 8. Avoid multiple redundant jQuery DOM manupulation by saving reference to
> any object.
> 9. Try to use meaningful comments.
> 10. Many more.
>
> Here are some links of best practices information-
>
> https://www.w3.org/wiki/JavaScript_best_practices
> http://www.codeproject.com/Articles/580165/JavaScript-Best-Practices
> https://developer.yahoo.com/performance/rules.html
>
> If everyone agrees, I would like to start on this work.
>
> Please let me know your thoughts on it.
>
> Thanks and Regards
> --
> Amardeep Singh Jhajj
>

[Rishi Solanki]

+1.

Rishi Solanki
Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: [phone]
http://www.hotwaxsystems.com

On Fri, Jun 24, 2016 at 2:13 PM, Divesh Dutta <
[hidden email]> wrote:

> +1 Amardeep.
>
>
> Thanks
> --
> Divesh Dutta.
>
> On Fri, Jun 24, 2016 at 12:50 PM, Amardeep Singh Jhajj <
> [hidden email]> wrote:
>
> > Hello everyone,
> >
> > Currently, OFBiz javascript code (except third party libraries) is not
> > written with the best practices which can cause following problems -
> >
> > 1. Increases the code maintenance effort.
> > 2. Impact page performance.
> > 3. Present not good examples to new contributors which leads to C/P to
> > various areas of js code.
> >
> > Here are things we should do for cleanup and improvements in js code.
> >
> > 1. Remove unused javascript code and files if any.
> > 2. Use best practices for javascript coding to improve performance (I
> have
> > listed some of it below).
> > 3. Move utility js functions to one js file.
> > 4. Remove deprecated code and use latest. For ex: We are still using
> > "language='javascript'" attribute at script tag which is deprecated a
> years
> > ago.
> > 5. js should be loaded at bottom of the page, currently its in Header.
> Its
> > a tedious task now to move it into footer because we have lot of js code
> > inline in ftls.
> > 6. js should not be written inline, it should be enough generic to be in
> > minimum number of files and have generic code for doing the common set of
> > operations over DOM.
> > 7. Currently our macros of rendering pages has inline scripts, they can
> be
> > moved to one macrorenderer.js with generic code as we can use classes,
> ids
> > and data-attributes for doing any operation over html DOM.
> > 8. After all cleanup work, we can think of build tool (like grunt) for
> > various javascript build tasks (minification, concatenation of files) if
> > needed. Its just a thought.
> >
> > I know its a huge effort and need to be done carefully. So before doing
> any
> > major changes, I would like to start work with first 4 points.
> >
> > Here is the list of some best practices to start with:
> >
> > 1. Use [] Instead of New Array()
> > 2. Long list of variables? Omit the "Var" keyword and use commas instead.
> > 3. Reduce global variables
> > 4. Use explicit blocks
> > 5. Start blocks on the same line
> > 6. Always, Always Use Semicolons - Having said that, this is a very bad
> > practice that can potentially lead to much bigger, and harder to find,
> > issues.
> > 7. Optimize loops. Avoid calculating the length of array in for loop
> > iteration.
> > 8. Avoid multiple redundant jQuery DOM manupulation by saving reference
> to
> > any object.
> > 9. Try to use meaningful comments.
> > 10. Many more.
> >
> > Here are some links of best practices information-
> >
> > https://www.w3.org/wiki/JavaScript_best_practices
> > http://www.codeproject.com/Articles/580165/JavaScript-Best-Practices
> > https://developer.yahoo.com/performance/rules.html
> >
> > If everyone agrees, I would like to start on this work.
> >
> > Please let me know your thoughts on it.
> >
> > Thanks and Regards
> > --
> > Amardeep Singh Jhajj
> >
>

[Ashish Vijaywargiya-4]

Very good idea Amardeep. Big +1.

--
Kind Regards
Ashish Vijaywargiya
HotWax Systems - est. 1997
https://www.linkedin.com/in/ashishvijaywargiya1

On Fri, Jun 24, 2016 at 12:50 PM, Amardeep Singh Jhajj <
[hidden email]> wrote:

> Hello everyone,
>
> Currently, OFBiz javascript code (except third party libraries) is not
> written with the best practices which can cause following problems -
>
> 1. Increases the code maintenance effort.
> 2. Impact page performance.
> 3. Present not good examples to new contributors which leads to C/P to
> various areas of js code.
>
> Here are things we should do for cleanup and improvements in js code.
>
> 1. Remove unused javascript code and files if any.
> 2. Use best practices for javascript coding to improve performance (I have
> listed some of it below).
> 3. Move utility js functions to one js file.
> 4. Remove deprecated code and use latest. For ex: We are still using
> "language='javascript'" attribute at script tag which is deprecated a years
> ago.
> 5. js should be loaded at bottom of the page, currently its in Header. Its
> a tedious task now to move it into footer because we have lot of js code
> inline in ftls.
> 6. js should not be written inline, it should be enough generic to be in
> minimum number of files and have generic code for doing the common set of
> operations over DOM.
> 7. Currently our macros of rendering pages has inline scripts, they can be
> moved to one macrorenderer.js with generic code as we can use classes, ids
> and data-attributes for doing any operation over html DOM.
> 8. After all cleanup work, we can think of build tool (like grunt) for
> various javascript build tasks (minification, concatenation of files) if
> needed. Its just a thought.
>
> I know its a huge effort and need to be done carefully. So before doing any
> major changes, I would like to start work with first 4 points.
>
> Here is the list of some best practices to start with:
>
> 1. Use [] Instead of New Array()
> 2. Long list of variables? Omit the "Var" keyword and use commas instead.
> 3. Reduce global variables
> 4. Use explicit blocks
> 5. Start blocks on the same line
> 6. Always, Always Use Semicolons - Having said that, this is a very bad
> practice that can potentially lead to much bigger, and harder to find,
> issues.
> 7. Optimize loops. Avoid calculating the length of array in for loop
> iteration.
> 8. Avoid multiple redundant jQuery DOM manupulation by saving reference to
> any object.
> 9. Try to use meaningful comments.
> 10. Many more.
>
> Here are some links of best practices information-
>
> https://www.w3.org/wiki/JavaScript_best_practices
> http://www.codeproject.com/Articles/580165/JavaScript-Best-Practices
> https://developer.yahoo.com/performance/rules.html
>
> If everyone agrees, I would like to start on this work.
>
> Please let me know your thoughts on it.
>
> Thanks and Regards
> --
> Amardeep Singh Jhajj
>

[Jacques Le Roux]

Amardeep,

I agree with your points, I'd just request that we do that in a branch with a load of UI tests (good occasion to use Selenium).
Our js code is complex and fragile, I think notably at the global variables in fieldlookup.js and selectall.js which are maybe hard to avoid.
IMO those files are the main pains.

Thanks

Jacques


Le 24/06/2016 à 09:20, Amardeep Singh Jhajj a écrit :

> Hello everyone,
>
> Currently, OFBiz javascript code (except third party libraries) is not
> written with the best practices which can cause following problems -
>
> 1. Increases the code maintenance effort.
> 2. Impact page performance.
> 3. Present not good examples to new contributors which leads to C/P to
> various areas of js code.
>
> Here are things we should do for cleanup and improvements in js code.
>
> 1. Remove unused javascript code and files if any.
> 2. Use best practices for javascript coding to improve performance (I have
> listed some of it below).
> 3. Move utility js functions to one js file.
> 4. Remove deprecated code and use latest. For ex: We are still using
> "language='javascript'" attribute at script tag which is deprecated a years
> ago.
> 5. js should be loaded at bottom of the page, currently its in Header. Its
> a tedious task now to move it into footer because we have lot of js code
> inline in ftls.
> 6. js should not be written inline, it should be enough generic to be in
> minimum number of files and have generic code for doing the common set of
> operations over DOM.
> 7. Currently our macros of rendering pages has inline scripts, they can be
> moved to one macrorenderer.js with generic code as we can use classes, ids
> and data-attributes for doing any operation over html DOM.
> 8. After all cleanup work, we can think of build tool (like grunt) for
> various javascript build tasks (minification, concatenation of files) if
> needed. Its just a thought.
>
> I know its a huge effort and need to be done carefully. So before doing any
> major changes, I would like to start work with first 4 points.
>
> Here is the list of some best practices to start with:
>
> 1. Use [] Instead of New Array()
> 2. Long list of variables? Omit the "Var" keyword and use commas instead.
> 3. Reduce global variables
> 4. Use explicit blocks
> 5. Start blocks on the same line
> 6. Always, Always Use Semicolons - Having said that, this is a very bad
> practice that can potentially lead to much bigger, and harder to find,
> issues.
> 7. Optimize loops. Avoid calculating the length of array in for loop
> iteration.
> 8. Avoid multiple redundant jQuery DOM manupulation by saving reference to
> any object.
> 9. Try to use meaningful comments.
> 10. Many more.
>
> Here are some links of best practices information-
>
> https://www.w3.org/wiki/JavaScript_best_practices
> http://www.codeproject.com/Articles/580165/JavaScript-Best-Practices
> https://developer.yahoo.com/performance/rules.html
>
> If everyone agrees, I would like to start on this work.
>
> Please let me know your thoughts on it.
>
> Thanks and Regards
> --
> Amardeep Singh Jhajj
>

[Amardeep Singh Jhajj-2]

Thanks all for approval.

Thanks Taher and Deepak for valuable suggestions. I will think on them.

Jacques,

I am bit confused by your reply, could you please elaborate your point.

Regards,
--
Amardeep Singh Jhajj


On Fri, Jun 24, 2016 at 4:17 PM, Jacques Le Roux <
[hidden email]> wrote:

> Amardeep,
>
> I agree with your points, I'd just request that we do that in a branch
> with a load of UI tests (good occasion to use Selenium).
> Our js code is complex and fragile, I think notably at the global
> variables in fieldlookup.js and selectall.js which are maybe hard to avoid.
> IMO those files are the main pains.
>
> Thanks
>
> Jacques
>
>
>
> Le 24/06/2016 à 09:20, Amardeep Singh Jhajj a écrit :
>
>> Hello everyone,
>>
>> Currently, OFBiz javascript code (except third party libraries) is not
>> written with the best practices which can cause following problems -
>>
>> 1. Increases the code maintenance effort.
>> 2. Impact page performance.
>> 3. Present not good examples to new contributors which leads to C/P to
>> various areas of js code.
>>
>> Here are things we should do for cleanup and improvements in js code.
>>
>> 1. Remove unused javascript code and files if any.
>> 2. Use best practices for javascript coding to improve performance (I have
>> listed some of it below).
>> 3. Move utility js functions to one js file.
>> 4. Remove deprecated code and use latest. For ex: We are still using
>> "language='javascript'" attribute at script tag which is deprecated a
>> years
>> ago.
>> 5. js should be loaded at bottom of the page, currently its in Header. Its
>> a tedious task now to move it into footer because we have lot of js code
>> inline in ftls.
>> 6. js should not be written inline, it should be enough generic to be in
>> minimum number of files and have generic code for doing the common set of
>> operations over DOM.
>> 7. Currently our macros of rendering pages has inline scripts, they can be
>> moved to one macrorenderer.js with generic code as we can use classes, ids
>> and data-attributes for doing any operation over html DOM.
>> 8. After all cleanup work, we can think of build tool (like grunt) for
>> various javascript build tasks (minification, concatenation of files) if
>> needed. Its just a thought.
>>
>> I know its a huge effort and need to be done carefully. So before doing
>> any
>> major changes, I would like to start work with first 4 points.
>>
>> Here is the list of some best practices to start with:
>>
>> 1. Use [] Instead of New Array()
>> 2. Long list of variables? Omit the "Var" keyword and use commas instead.
>> 3. Reduce global variables
>> 4. Use explicit blocks
>> 5. Start blocks on the same line
>> 6. Always, Always Use Semicolons - Having said that, this is a very bad
>> practice that can potentially lead to much bigger, and harder to find,
>> issues.
>> 7. Optimize loops. Avoid calculating the length of array in for loop
>> iteration.
>> 8. Avoid multiple redundant jQuery DOM manupulation by saving reference to
>> any object.
>> 9. Try to use meaningful comments.
>> 10. Many more.
>>
>> Here are some links of best practices information-
>>
>> https://www.w3.org/wiki/JavaScript_best_practices
>> http://www.codeproject.com/Articles/580165/JavaScript-Best-Practices
>> https://developer.yahoo.com/performance/rules.html
>>
>> If everyone agrees, I would like to start on this work.
>>
>> Please let me know your thoughts on it.
>>
>> Thanks and Regards
>> --
>> Amardeep Singh Jhajj
>>
>>
>

[Jacques Le Roux]

Hi Amardeep,

What I mean is we should be cautious. Hence the suggestion to create a branch for the refactoring. And to benefit from this opportunity to put some
Selenium tests related with js (eg: calendar - could also use HTML5 now -, autocompletion, lookups, dependent dropdowns). That would be a start for
Selenium, no needs to have tons of it. A Jira subtask would be perfect.

Hope I'm clearer

Thanks

Jacques


Le 24/06/2016 à 15:53, Amardeep Singh Jhajj a écrit :

> Thanks all for approval.
>
> Thanks Taher and Deepak for valuable suggestions. I will think on them.
>
> Jacques,
>
> I am bit confused by your reply, could you please elaborate your point.
>
> Regards,
> --
> Amardeep Singh Jhajj
>
>
> On Fri, Jun 24, 2016 at 4:17 PM, Jacques Le Roux <
> [hidden email]> wrote:
>
>> Amardeep,
>>
>> I agree with your points, I'd just request that we do that in a branch
>> with a load of UI tests (good occasion to use Selenium).
>> Our js code is complex and fragile, I think notably at the global
>> variables in fieldlookup.js and selectall.js which are maybe hard to avoid.
>> IMO those files are the main pains.
>>
>> Thanks
>>
>> Jacques
>>
>>
>>
>> Le 24/06/2016 à 09:20, Amardeep Singh Jhajj a écrit :
>>
>>> Hello everyone,
>>>
>>> Currently, OFBiz javascript code (except third party libraries) is not
>>> written with the best practices which can cause following problems -
>>>
>>> 1. Increases the code maintenance effort.
>>> 2. Impact page performance.
>>> 3. Present not good examples to new contributors which leads to C/P to
>>> various areas of js code.
>>>
>>> Here are things we should do for cleanup and improvements in js code.
>>>
>>> 1. Remove unused javascript code and files if any.
>>> 2. Use best practices for javascript coding to improve performance (I have
>>> listed some of it below).
>>> 3. Move utility js functions to one js file.
>>> 4. Remove deprecated code and use latest. For ex: We are still using
>>> "language='javascript'" attribute at script tag which is deprecated a
>>> years
>>> ago.
>>> 5. js should be loaded at bottom of the page, currently its in Header. Its
>>> a tedious task now to move it into footer because we have lot of js code
>>> inline in ftls.
>>> 6. js should not be written inline, it should be enough generic to be in
>>> minimum number of files and have generic code for doing the common set of
>>> operations over DOM.
>>> 7. Currently our macros of rendering pages has inline scripts, they can be
>>> moved to one macrorenderer.js with generic code as we can use classes, ids
>>> and data-attributes for doing any operation over html DOM.
>>> 8. After all cleanup work, we can think of build tool (like grunt) for
>>> various javascript build tasks (minification, concatenation of files) if
>>> needed. Its just a thought.
>>>
>>> I know its a huge effort and need to be done carefully. So before doing
>>> any
>>> major changes, I would like to start work with first 4 points.
>>>
>>> Here is the list of some best practices to start with:
>>>
>>> 1. Use [] Instead of New Array()
>>> 2. Long list of variables? Omit the "Var" keyword and use commas instead.
>>> 3. Reduce global variables
>>> 4. Use explicit blocks
>>> 5. Start blocks on the same line
>>> 6. Always, Always Use Semicolons - Having said that, this is a very bad
>>> practice that can potentially lead to much bigger, and harder to find,
>>> issues.
>>> 7. Optimize loops. Avoid calculating the length of array in for loop
>>> iteration.
>>> 8. Avoid multiple redundant jQuery DOM manupulation by saving reference to
>>> any object.
>>> 9. Try to use meaningful comments.
>>> 10. Many more.
>>>
>>> Here are some links of best practices information-
>>>
>>> https://www.w3.org/wiki/JavaScript_best_practices
>>> http://www.codeproject.com/Articles/580165/JavaScript-Best-Practices
>>> https://developer.yahoo.com/performance/rules.html
>>>
>>> If everyone agrees, I would like to start on this work.
>>>
>>> Please let me know your thoughts on it.
>>>
>>> Thanks and Regards
>>> --
>>> Amardeep Singh Jhajj
>>>
>>>

[Amardeep Singh Jhajj-2]

Hello Jacques,

Making branch is a good idea to handle regressions but I would prefer to
work in trunk itself. Here are the things we should consider before
creating new branch:

1. Branch can be abandoned, I would prefer to have code changes in trunk in
proper steps instead of merging the complete branch work later in trunk.
2. Currently, lot of changes is coming in trunk, so different branch need
to updated regularly. Its also an additional work.

To avoid regressions, we can do our work in granular level tasks for
various functionality (wherever needed) and proper testing steps will be
there. The code changes will only be committed after thorough testing.

First, I would like to start with cleanup of inline javascripts so that all
javascript code will only in js files which helps us to follow best
practices of javascript.
Here is the steps can be taken to do it:

1. Start with one component. For example: Accounting.
2. Pick its various functionality one by one where javascript is added
inline.
3. Do cleanup in it.
4. Do thorough testing for it with testing steps over ticket.

Once the all cleanup (inline js cleanup) is done, we would have javascript
files for further work. We can further break the js work by functionality
(if needed) for improvements.

The above process will assure us that nothing will break. I will not work
on this effort alone, the team of developers having two or more year
experience in javascript will work with me.

I will create the parent ticket for selenium tests as well and we will see
how we can work on it.

Thanks & Regards
--
Amardeep Singh Jhajj
www.hotwaxsystems.com

On Sat, Jun 25, 2016 at 1:06 PM, Jacques Le Roux <
[hidden email]> wrote:

> Hi Amardeep,
>
> What I mean is we should be cautious. Hence the suggestion to create a
> branch for the refactoring. And to benefit from this opportunity to put
> some Selenium tests related with js (eg: calendar - could also use HTML5
> now -, autocompletion, lookups, dependent dropdowns). That would be a start
> for Selenium, no needs to have tons of it. A Jira subtask would be perfect.
>
> Hope I'm clearer
>
> Thanks
>
> Jacques
>
>
>
> Le 24/06/2016 à 15:53, Amardeep Singh Jhajj a écrit :
>
>> Thanks all for approval.
>>
>> Thanks Taher and Deepak for valuable suggestions. I will think on them.
>>
>> Jacques,
>>
>> I am bit confused by your reply, could you please elaborate your point.
>>
>> Regards,
>> --
>> Amardeep Singh Jhajj
>>
>>
>> On Fri, Jun 24, 2016 at 4:17 PM, Jacques Le Roux <
>> [hidden email]> wrote:
>>
>> Amardeep,
>>>
>>> I agree with your points, I'd just request that we do that in a branch
>>> with a load of UI tests (good occasion to use Selenium).
>>> Our js code is complex and fragile, I think notably at the global
>>> variables in fieldlookup.js and selectall.js which are maybe hard to
>>> avoid.
>>> IMO those files are the main pains.
>>>
>>> Thanks
>>>
>>> Jacques
>>>
>>>
>>>
>>> Le 24/06/2016 à 09:20, Amardeep Singh Jhajj a écrit :
>>>
>>> Hello everyone,
>>>>
>>>> Currently, OFBiz javascript code (except third party libraries) is not
>>>> written with the best practices which can cause following problems -
>>>>
>>>> 1. Increases the code maintenance effort.
>>>> 2. Impact page performance.
>>>> 3. Present not good examples to new contributors which leads to C/P to
>>>> various areas of js code.
>>>>
>>>> Here are things we should do for cleanup and improvements in js code.
>>>>
>>>> 1. Remove unused javascript code and files if any.
>>>> 2. Use best practices for javascript coding to improve performance (I
>>>> have
>>>> listed some of it below).
>>>> 3. Move utility js functions to one js file.
>>>> 4. Remove deprecated code and use latest. For ex: We are still using
>>>> "language='javascript'" attribute at script tag which is deprecated a
>>>> years
>>>> ago.
>>>> 5. js should be loaded at bottom of the page, currently its in Header.
>>>> Its
>>>> a tedious task now to move it into footer because we have lot of js code
>>>> inline in ftls.
>>>> 6. js should not be written inline, it should be enough generic to be in
>>>> minimum number of files and have generic code for doing the common set
>>>> of
>>>> operations over DOM.
>>>> 7. Currently our macros of rendering pages has inline scripts, they can
>>>> be
>>>> moved to one macrorenderer.js with generic code as we can use classes,
>>>> ids
>>>> and data-attributes for doing any operation over html DOM.
>>>> 8. After all cleanup work, we can think of build tool (like grunt) for
>>>> various javascript build tasks (minification, concatenation of files) if
>>>> needed. Its just a thought.
>>>>
>>>> I know its a huge effort and need to be done carefully. So before doing
>>>> any
>>>> major changes, I would like to start work with first 4 points.
>>>>
>>>> Here is the list of some best practices to start with:
>>>>
>>>> 1. Use [] Instead of New Array()
>>>> 2. Long list of variables? Omit the "Var" keyword and use commas
>>>> instead.
>>>> 3. Reduce global variables
>>>> 4. Use explicit blocks
>>>> 5. Start blocks on the same line
>>>> 6. Always, Always Use Semicolons - Having said that, this is a very bad
>>>> practice that can potentially lead to much bigger, and harder to find,
>>>> issues.
>>>> 7. Optimize loops. Avoid calculating the length of array in for loop
>>>> iteration.
>>>> 8. Avoid multiple redundant jQuery DOM manupulation by saving reference
>>>> to
>>>> any object.
>>>> 9. Try to use meaningful comments.
>>>> 10. Many more.
>>>>
>>>> Here are some links of best practices information-
>>>>
>>>> https://www.w3.org/wiki/JavaScript_best_practices
>>>> http://www.codeproject.com/Articles/580165/JavaScript-Best-Practices
>>>> https://developer.yahoo.com/performance/rules.html
>>>>
>>>> If everyone agrees, I would like to start on this work.
>>>>
>>>> Please let me know your thoughts on it.
>>>>
>>>> Thanks and Regards
>>>> --
>>>> Amardeep Singh Jhajj
>>>>
>>>>
>>>>
>

[Pranay Pandey-3]

+1 Amardeep, mentioned approach is looking reasonable to me.

Best regards,

Pranay Pandey
HotWax Systems
http://www.hotwaxsystems.com/

On Tue, Jun 28, 2016 at 11:21 AM, Amardeep Singh Jhajj <
[hidden email]> wrote:

> Hello Jacques,
>
> Making branch is a good idea to handle regressions but I would prefer to
> work in trunk itself. Here are the things we should consider before
> creating new branch:
>
> 1. Branch can be abandoned, I would prefer to have code changes in trunk in
> proper steps instead of merging the complete branch work later in trunk.
> 2. Currently, lot of changes is coming in trunk, so different branch need
> to updated regularly. Its also an additional work.
>
> To avoid regressions, we can do our work in granular level tasks for
> various functionality (wherever needed) and proper testing steps will be
> there. The code changes will only be committed after thorough testing.
>
> First, I would like to start with cleanup of inline javascripts so that all
> javascript code will only in js files which helps us to follow best
> practices of javascript.
> Here is the steps can be taken to do it:
>
> 1. Start with one component. For example: Accounting.
> 2. Pick its various functionality one by one where javascript is added
> inline.
> 3. Do cleanup in it.
> 4. Do thorough testing for it with testing steps over ticket.
>
> Once the all cleanup (inline js cleanup) is done, we would have javascript
> files for further work. We can further break the js work by functionality
> (if needed) for improvements.
>
> The above process will assure us that nothing will break. I will not work
> on this effort alone, the team of developers having two or more year
> experience in javascript will work with me.
>
> I will create the parent ticket for selenium tests as well and we will see
> how we can work on it.
>
> Thanks & Regards
> --
> Amardeep Singh Jhajj
> www.hotwaxsystems.com
>
> On Sat, Jun 25, 2016 at 1:06 PM, Jacques Le Roux <
> [hidden email]> wrote:
>
> > Hi Amardeep,
> >
> > What I mean is we should be cautious. Hence the suggestion to create a
> > branch for the refactoring. And to benefit from this opportunity to put
> > some Selenium tests related with js (eg: calendar - could also use HTML5
> > now -, autocompletion, lookups, dependent dropdowns). That would be a
> start
> > for Selenium, no needs to have tons of it. A Jira subtask would be
> perfect.
> >
> > Hope I'm clearer
> >
> > Thanks
> >
> > Jacques
> >
> >
> >
> > Le 24/06/2016 à 15:53, Amardeep Singh Jhajj a écrit :
> >
> >> Thanks all for approval.
> >>
> >> Thanks Taher and Deepak for valuable suggestions. I will think on them.
> >>
> >> Jacques,
> >>
> >> I am bit confused by your reply, could you please elaborate your point.
> >>
> >> Regards,
> >> --
> >> Amardeep Singh Jhajj
> >>
> >>
> >> On Fri, Jun 24, 2016 at 4:17 PM, Jacques Le Roux <
> >> [hidden email]> wrote:
> >>
> >> Amardeep,
> >>>
> >>> I agree with your points, I'd just request that we do that in a branch
> >>> with a load of UI tests (good occasion to use Selenium).
> >>> Our js code is complex and fragile, I think notably at the global
> >>> variables in fieldlookup.js and selectall.js which are maybe hard to
> >>> avoid.
> >>> IMO those files are the main pains.
> >>>
> >>> Thanks
> >>>
> >>> Jacques
> >>>
> >>>
> >>>
> >>> Le 24/06/2016 à 09:20, Amardeep Singh Jhajj a écrit :
> >>>
> >>> Hello everyone,
> >>>>
> >>>> Currently, OFBiz javascript code (except third party libraries) is not
> >>>> written with the best practices which can cause following problems -
> >>>>
> >>>> 1. Increases the code maintenance effort.
> >>>> 2. Impact page performance.
> >>>> 3. Present not good examples to new contributors which leads to C/P to
> >>>> various areas of js code.
> >>>>
> >>>> Here are things we should do for cleanup and improvements in js code.
> >>>>
> >>>> 1. Remove unused javascript code and files if any.
> >>>> 2. Use best practices for javascript coding to improve performance (I
> >>>> have
> >>>> listed some of it below).
> >>>> 3. Move utility js functions to one js file.
> >>>> 4. Remove deprecated code and use latest. For ex: We are still using
> >>>> "language='javascript'" attribute at script tag which is deprecated a
> >>>> years
> >>>> ago.
> >>>> 5. js should be loaded at bottom of the page, currently its in Header.
> >>>> Its
> >>>> a tedious task now to move it into footer because we have lot of js
> code
> >>>> inline in ftls.
> >>>> 6. js should not be written inline, it should be enough generic to be
> in
> >>>> minimum number of files and have generic code for doing the common set
> >>>> of
> >>>> operations over DOM.
> >>>> 7. Currently our macros of rendering pages has inline scripts, they
> can
> >>>> be
> >>>> moved to one macrorenderer.js with generic code as we can use classes,
> >>>> ids
> >>>> and data-attributes for doing any operation over html DOM.
> >>>> 8. After all cleanup work, we can think of build tool (like grunt) for
> >>>> various javascript build tasks (minification, concatenation of files)
> if
> >>>> needed. Its just a thought.
> >>>>
> >>>> I know its a huge effort and need to be done carefully. So before
> doing
> >>>> any
> >>>> major changes, I would like to start work with first 4 points.
> >>>>
> >>>> Here is the list of some best practices to start with:
> >>>>
> >>>> 1. Use [] Instead of New Array()
> >>>> 2. Long list of variables? Omit the "Var" keyword and use commas
> >>>> instead.
> >>>> 3. Reduce global variables
> >>>> 4. Use explicit blocks
> >>>> 5. Start blocks on the same line
> >>>> 6. Always, Always Use Semicolons - Having said that, this is a very
> bad
> >>>> practice that can potentially lead to much bigger, and harder to find,
> >>>> issues.
> >>>> 7. Optimize loops. Avoid calculating the length of array in for loop
> >>>> iteration.
> >>>> 8. Avoid multiple redundant jQuery DOM manupulation by saving
> reference
> >>>> to
> >>>> any object.
> >>>> 9. Try to use meaningful comments.
> >>>> 10. Many more.
> >>>>
> >>>> Here are some links of best practices information-
> >>>>
> >>>> https://www.w3.org/wiki/JavaScript_best_practices
> >>>> http://www.codeproject.com/Articles/580165/JavaScript-Best-Practices
> >>>> https://developer.yahoo.com/performance/rules.html
> >>>>
> >>>> If everyone agrees, I would like to start on this work.
> >>>>
> >>>> Please let me know your thoughts on it.
> >>>>
> >>>> Thanks and Regards
> >>>> --
> >>>> Amardeep Singh Jhajj
> >>>>
> >>>>
> >>>>
> >
>

[taher]

+1 on approach
On Jun 28, 2016 8:53 AM, "Pranay Pandey" <[hidden email]>
wrote:

> +1 Amardeep, mentioned approach is looking reasonable to me.
>
> Best regards,
>
> Pranay Pandey
> HotWax Systems
> http://www.hotwaxsystems.com/
>
> On Tue, Jun 28, 2016 at 11:21 AM, Amardeep Singh Jhajj <
> [hidden email]> wrote:
>
> > Hello Jacques,
> >
> > Making branch is a good idea to handle regressions but I would prefer to
> > work in trunk itself. Here are the things we should consider before
> > creating new branch:
> >
> > 1. Branch can be abandoned, I would prefer to have code changes in trunk
> in
> > proper steps instead of merging the complete branch work later in trunk.
> > 2. Currently, lot of changes is coming in trunk, so different branch need
> > to updated regularly. Its also an additional work.
> >
> > To avoid regressions, we can do our work in granular level tasks for
> > various functionality (wherever needed) and proper testing steps will be
> > there. The code changes will only be committed after thorough testing.
> >
> > First, I would like to start with cleanup of inline javascripts so that
> all
> > javascript code will only in js files which helps us to follow best
> > practices of javascript.
> > Here is the steps can be taken to do it:
> >
> > 1. Start with one component. For example: Accounting.
> > 2. Pick its various functionality one by one where javascript is added
> > inline.
> > 3. Do cleanup in it.
> > 4. Do thorough testing for it with testing steps over ticket.
> >
> > Once the all cleanup (inline js cleanup) is done, we would have
> javascript
> > files for further work. We can further break the js work by functionality
> > (if needed) for improvements.
> >
> > The above process will assure us that nothing will break. I will not work
> > on this effort alone, the team of developers having two or more year
> > experience in javascript will work with me.
> >
> > I will create the parent ticket for selenium tests as well and we will
> see
> > how we can work on it.
> >
> > Thanks & Regards
> > --
> > Amardeep Singh Jhajj
> > www.hotwaxsystems.com
> >
> > On Sat, Jun 25, 2016 at 1:06 PM, Jacques Le Roux <
> > [hidden email]> wrote:
> >
> > > Hi Amardeep,
> > >
> > > What I mean is we should be cautious. Hence the suggestion to create a
> > > branch for the refactoring. And to benefit from this opportunity to put
> > > some Selenium tests related with js (eg: calendar - could also use
> HTML5
> > > now -, autocompletion, lookups, dependent dropdowns). That would be a
> > start
> > > for Selenium, no needs to have tons of it. A Jira subtask would be
> > perfect.
> > >
> > > Hope I'm clearer
> > >
> > > Thanks
> > >
> > > Jacques
> > >
> > >
> > >
> > > Le 24/06/2016 à 15:53, Amardeep Singh Jhajj a écrit :
> > >
> > >> Thanks all for approval.
> > >>
> > >> Thanks Taher and Deepak for valuable suggestions. I will think on
> them.
> > >>
> > >> Jacques,
> > >>
> > >> I am bit confused by your reply, could you please elaborate your
> point.
> > >>
> > >> Regards,
> > >> --
> > >> Amardeep Singh Jhajj
> > >>
> > >>
> > >> On Fri, Jun 24, 2016 at 4:17 PM, Jacques Le Roux <
> > >> [hidden email]> wrote:
> > >>
> > >> Amardeep,
> > >>>
> > >>> I agree with your points, I'd just request that we do that in a
> branch
> > >>> with a load of UI tests (good occasion to use Selenium).
> > >>> Our js code is complex and fragile, I think notably at the global
> > >>> variables in fieldlookup.js and selectall.js which are maybe hard to
> > >>> avoid.
> > >>> IMO those files are the main pains.
> > >>>
> > >>> Thanks
> > >>>
> > >>> Jacques
> > >>>
> > >>>
> > >>>
> > >>> Le 24/06/2016 à 09:20, Amardeep Singh Jhajj a écrit :
> > >>>
> > >>> Hello everyone,
> > >>>>
> > >>>> Currently, OFBiz javascript code (except third party libraries) is
> not
> > >>>> written with the best practices which can cause following problems -
> > >>>>
> > >>>> 1. Increases the code maintenance effort.
> > >>>> 2. Impact page performance.
> > >>>> 3. Present not good examples to new contributors which leads to C/P
> to
> > >>>> various areas of js code.
> > >>>>
> > >>>> Here are things we should do for cleanup and improvements in js
> code.
> > >>>>
> > >>>> 1. Remove unused javascript code and files if any.
> > >>>> 2. Use best practices for javascript coding to improve performance
> (I
> > >>>> have
> > >>>> listed some of it below).
> > >>>> 3. Move utility js functions to one js file.
> > >>>> 4. Remove deprecated code and use latest. For ex: We are still using
> > >>>> "language='javascript'" attribute at script tag which is deprecated
> a
> > >>>> years
> > >>>> ago.
> > >>>> 5. js should be loaded at bottom of the page, currently its in
> Header.
> > >>>> Its
> > >>>> a tedious task now to move it into footer because we have lot of js
> > code
> > >>>> inline in ftls.
> > >>>> 6. js should not be written inline, it should be enough generic to
> be
> > in
> > >>>> minimum number of files and have generic code for doing the common
> set
> > >>>> of
> > >>>> operations over DOM.
> > >>>> 7. Currently our macros of rendering pages has inline scripts, they
> > can
> > >>>> be
> > >>>> moved to one macrorenderer.js with generic code as we can use
> classes,
> > >>>> ids
> > >>>> and data-attributes for doing any operation over html DOM.
> > >>>> 8. After all cleanup work, we can think of build tool (like grunt)
> for
> > >>>> various javascript build tasks (minification, concatenation of
> files)
> > if
> > >>>> needed. Its just a thought.
> > >>>>
> > >>>> I know its a huge effort and need to be done carefully. So before
> > doing
> > >>>> any
> > >>>> major changes, I would like to start work with first 4 points.
> > >>>>
> > >>>> Here is the list of some best practices to start with:
> > >>>>
> > >>>> 1. Use [] Instead of New Array()
> > >>>> 2. Long list of variables? Omit the "Var" keyword and use commas
> > >>>> instead.
> > >>>> 3. Reduce global variables
> > >>>> 4. Use explicit blocks
> > >>>> 5. Start blocks on the same line
> > >>>> 6. Always, Always Use Semicolons - Having said that, this is a very
> > bad
> > >>>> practice that can potentially lead to much bigger, and harder to
> find,
> > >>>> issues.
> > >>>> 7. Optimize loops. Avoid calculating the length of array in for loop
> > >>>> iteration.
> > >>>> 8. Avoid multiple redundant jQuery DOM manupulation by saving
> > reference
> > >>>> to
> > >>>> any object.
> > >>>> 9. Try to use meaningful comments.
> > >>>> 10. Many more.
> > >>>>
> > >>>> Here are some links of best practices information-
> > >>>>
> > >>>> https://www.w3.org/wiki/JavaScript_best_practices
> > >>>>
> http://www.codeproject.com/Articles/580165/JavaScript-Best-Practices
> > >>>> https://developer.yahoo.com/performance/rules.html
> > >>>>
> > >>>> If everyone agrees, I would like to start on this work.
> > >>>>
> > >>>> Please let me know your thoughts on it.
> > >>>>
> > >>>> Thanks and Regards
> > >>>> --
> > >>>> Amardeep Singh Jhajj
> > >>>>
> > >>>>
> > >>>>
> > >
> >
>

[Rishi Solanki]

After merging the separate branch we may have regression, picking one item
do regression testing over trunk will minimize the regression.

+1 Amardeep, good way to go.

Rishi Solanki
Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: [phone]
http://www.hotwaxsystems.com

On Tue, Jun 28, 2016 at 11:21 AM, Amardeep Singh Jhajj <
[hidden email]> wrote:

> Hello Jacques,
>
> Making branch is a good idea to handle regressions but I would prefer to
> work in trunk itself. Here are the things we should consider before
> creating new branch:
>
> 1. Branch can be abandoned, I would prefer to have code changes in trunk in
> proper steps instead of merging the complete branch work later in trunk.
> 2. Currently, lot of changes is coming in trunk, so different branch need
> to updated regularly. Its also an additional work.
>
> To avoid regressions, we can do our work in granular level tasks for
> various functionality (wherever needed) and proper testing steps will be
> there. The code changes will only be committed after thorough testing.
>
> First, I would like to start with cleanup of inline javascripts so that all
> javascript code will only in js files which helps us to follow best
> practices of javascript.
> Here is the steps can be taken to do it:
>
> 1. Start with one component. For example: Accounting.
> 2. Pick its various functionality one by one where javascript is added
> inline.
> 3. Do cleanup in it.
> 4. Do thorough testing for it with testing steps over ticket.
>
> Once the all cleanup (inline js cleanup) is done, we would have javascript
> files for further work. We can further break the js work by functionality
> (if needed) for improvements.
>
> The above process will assure us that nothing will break. I will not work
> on this effort alone, the team of developers having two or more year
> experience in javascript will work with me.
>
> I will create the parent ticket for selenium tests as well and we will see
> how we can work on it.
>
> Thanks & Regards
> --
> Amardeep Singh Jhajj
> www.hotwaxsystems.com
>
> On Sat, Jun 25, 2016 at 1:06 PM, Jacques Le Roux <
> [hidden email]> wrote:
>
> > Hi Amardeep,
> >
> > What I mean is we should be cautious. Hence the suggestion to create a
> > branch for the refactoring. And to benefit from this opportunity to put
> > some Selenium tests related with js (eg: calendar - could also use HTML5
> > now -, autocompletion, lookups, dependent dropdowns). That would be a
> start
> > for Selenium, no needs to have tons of it. A Jira subtask would be
> perfect.
> >
> > Hope I'm clearer
> >
> > Thanks
> >
> > Jacques
> >
> >
> >
> > Le 24/06/2016 à 15:53, Amardeep Singh Jhajj a écrit :
> >
> >> Thanks all for approval.
> >>
> >> Thanks Taher and Deepak for valuable suggestions. I will think on them.
> >>
> >> Jacques,
> >>
> >> I am bit confused by your reply, could you please elaborate your point.
> >>
> >> Regards,
> >> --
> >> Amardeep Singh Jhajj
> >>
> >>
> >> On Fri, Jun 24, 2016 at 4:17 PM, Jacques Le Roux <
> >> [hidden email]> wrote:
> >>
> >> Amardeep,
> >>>
> >>> I agree with your points, I'd just request that we do that in a branch
> >>> with a load of UI tests (good occasion to use Selenium).
> >>> Our js code is complex and fragile, I think notably at the global
> >>> variables in fieldlookup.js and selectall.js which are maybe hard to
> >>> avoid.
> >>> IMO those files are the main pains.
> >>>
> >>> Thanks
> >>>
> >>> Jacques
> >>>
> >>>
> >>>
> >>> Le 24/06/2016 à 09:20, Amardeep Singh Jhajj a écrit :
> >>>
> >>> Hello everyone,
> >>>>
> >>>> Currently, OFBiz javascript code (except third party libraries) is not
> >>>> written with the best practices which can cause following problems -
> >>>>
> >>>> 1. Increases the code maintenance effort.
> >>>> 2. Impact page performance.
> >>>> 3. Present not good examples to new contributors which leads to C/P to
> >>>> various areas of js code.
> >>>>
> >>>> Here are things we should do for cleanup and improvements in js code.
> >>>>
> >>>> 1. Remove unused javascript code and files if any.
> >>>> 2. Use best practices for javascript coding to improve performance (I
> >>>> have
> >>>> listed some of it below).
> >>>> 3. Move utility js functions to one js file.
> >>>> 4. Remove deprecated code and use latest. For ex: We are still using
> >>>> "language='javascript'" attribute at script tag which is deprecated a
> >>>> years
> >>>> ago.
> >>>> 5. js should be loaded at bottom of the page, currently its in Header.
> >>>> Its
> >>>> a tedious task now to move it into footer because we have lot of js
> code
> >>>> inline in ftls.
> >>>> 6. js should not be written inline, it should be enough generic to be
> in
> >>>> minimum number of files and have generic code for doing the common set
> >>>> of
> >>>> operations over DOM.
> >>>> 7. Currently our macros of rendering pages has inline scripts, they
> can
> >>>> be
> >>>> moved to one macrorenderer.js with generic code as we can use classes,
> >>>> ids
> >>>> and data-attributes for doing any operation over html DOM.
> >>>> 8. After all cleanup work, we can think of build tool (like grunt) for
> >>>> various javascript build tasks (minification, concatenation of files)
> if
> >>>> needed. Its just a thought.
> >>>>
> >>>> I know its a huge effort and need to be done carefully. So before
> doing
> >>>> any
> >>>> major changes, I would like to start work with first 4 points.
> >>>>
> >>>> Here is the list of some best practices to start with:
> >>>>
> >>>> 1. Use [] Instead of New Array()
> >>>> 2. Long list of variables? Omit the "Var" keyword and use commas
> >>>> instead.
> >>>> 3. Reduce global variables
> >>>> 4. Use explicit blocks
> >>>> 5. Start blocks on the same line
> >>>> 6. Always, Always Use Semicolons - Having said that, this is a very
> bad
> >>>> practice that can potentially lead to much bigger, and harder to find,
> >>>> issues.
> >>>> 7. Optimize loops. Avoid calculating the length of array in for loop
> >>>> iteration.
> >>>> 8. Avoid multiple redundant jQuery DOM manupulation by saving
> reference
> >>>> to
> >>>> any object.
> >>>> 9. Try to use meaningful comments.
> >>>> 10. Many more.
> >>>>
> >>>> Here are some links of best practices information-
> >>>>
> >>>> https://www.w3.org/wiki/JavaScript_best_practices
> >>>> http://www.codeproject.com/Articles/580165/JavaScript-Best-Practices
> >>>> https://developer.yahoo.com/performance/rules.html
> >>>>
> >>>> If everyone agrees, I would like to start on this work.
> >>>>
> >>>> Please let me know your thoughts on it.
> >>>>
> >>>> Thanks and Regards
> >>>> --
> >>>> Amardeep Singh Jhajj
> >>>>
> >>>>
> >>>>
> >
>

[akash jain-2]

+1 Amardeep, approach looks good to me.

Thanks and Regards
--
Akash Jain

On Tue, Jun 28, 2016 at 11:21 AM, Amardeep Singh Jhajj <
[hidden email]> wrote:

> Hello Jacques,
>
> Making branch is a good idea to handle regressions but I would prefer to
> work in trunk itself. Here are the things we should consider before
> creating new branch:
>
> 1. Branch can be abandoned, I would prefer to have code changes in trunk in
> proper steps instead of merging the complete branch work later in trunk.
> 2. Currently, lot of changes is coming in trunk, so different branch need
> to updated regularly. Its also an additional work.
>
> To avoid regressions, we can do our work in granular level tasks for
> various functionality (wherever needed) and proper testing steps will be
> there. The code changes will only be committed after thorough testing.
>
> First, I would like to start with cleanup of inline javascripts so that all
> javascript code will only in js files which helps us to follow best
> practices of javascript.
> Here is the steps can be taken to do it:
>
> 1. Start with one component. For example: Accounting.
> 2. Pick its various functionality one by one where javascript is added
> inline.
> 3. Do cleanup in it.
> 4. Do thorough testing for it with testing steps over ticket.
>
> Once the all cleanup (inline js cleanup) is done, we would have javascript
> files for further work. We can further break the js work by functionality
> (if needed) for improvements.
>
> The above process will assure us that nothing will break. I will not work
> on this effort alone, the team of developers having two or more year
> experience in javascript will work with me.
>
> I will create the parent ticket for selenium tests as well and we will see
> how we can work on it.
>
> Thanks & Regards
> --
> Amardeep Singh Jhajj
> www.hotwaxsystems.com
>
> On Sat, Jun 25, 2016 at 1:06 PM, Jacques Le Roux <
> [hidden email]> wrote:
>
> > Hi Amardeep,
> >
> > What I mean is we should be cautious. Hence the suggestion to create a
> > branch for the refactoring. And to benefit from this opportunity to put
> > some Selenium tests related with js (eg: calendar - could also use HTML5
> > now -, autocompletion, lookups, dependent dropdowns). That would be a
> start
> > for Selenium, no needs to have tons of it. A Jira subtask would be
> perfect.
> >
> > Hope I'm clearer
> >
> > Thanks
> >
> > Jacques
> >
> >
> >
> > Le 24/06/2016 à 15:53, Amardeep Singh Jhajj a écrit :
> >
> >> Thanks all for approval.
> >>
> >> Thanks Taher and Deepak for valuable suggestions. I will think on them.
> >>
> >> Jacques,
> >>
> >> I am bit confused by your reply, could you please elaborate your point.
> >>
> >> Regards,
> >> --
> >> Amardeep Singh Jhajj
> >>
> >>
> >> On Fri, Jun 24, 2016 at 4:17 PM, Jacques Le Roux <
> >> [hidden email]> wrote:
> >>
> >> Amardeep,
> >>>
> >>> I agree with your points, I'd just request that we do that in a branch
> >>> with a load of UI tests (good occasion to use Selenium).
> >>> Our js code is complex and fragile, I think notably at the global
> >>> variables in fieldlookup.js and selectall.js which are maybe hard to
> >>> avoid.
> >>> IMO those files are the main pains.
> >>>
> >>> Thanks
> >>>
> >>> Jacques
> >>>
> >>>
> >>>
> >>> Le 24/06/2016 à 09:20, Amardeep Singh Jhajj a écrit :
> >>>
> >>> Hello everyone,
> >>>>
> >>>> Currently, OFBiz javascript code (except third party libraries) is not
> >>>> written with the best practices which can cause following problems -
> >>>>
> >>>> 1. Increases the code maintenance effort.
> >>>> 2. Impact page performance.
> >>>> 3. Present not good examples to new contributors which leads to C/P to
> >>>> various areas of js code.
> >>>>
> >>>> Here are things we should do for cleanup and improvements in js code.
> >>>>
> >>>> 1. Remove unused javascript code and files if any.
> >>>> 2. Use best practices for javascript coding to improve performance (I
> >>>> have
> >>>> listed some of it below).
> >>>> 3. Move utility js functions to one js file.
> >>>> 4. Remove deprecated code and use latest. For ex: We are still using
> >>>> "language='javascript'" attribute at script tag which is deprecated a
> >>>> years
> >>>> ago.
> >>>> 5. js should be loaded at bottom of the page, currently its in Header.
> >>>> Its
> >>>> a tedious task now to move it into footer because we have lot of js
> code
> >>>> inline in ftls.
> >>>> 6. js should not be written inline, it should be enough generic to be
> in
> >>>> minimum number of files and have generic code for doing the common set
> >>>> of
> >>>> operations over DOM.
> >>>> 7. Currently our macros of rendering pages has inline scripts, they
> can
> >>>> be
> >>>> moved to one macrorenderer.js with generic code as we can use classes,
> >>>> ids
> >>>> and data-attributes for doing any operation over html DOM.
> >>>> 8. After all cleanup work, we can think of build tool (like grunt) for
> >>>> various javascript build tasks (minification, concatenation of files)
> if
> >>>> needed. Its just a thought.
> >>>>
> >>>> I know its a huge effort and need to be done carefully. So before
> doing
> >>>> any
> >>>> major changes, I would like to start work with first 4 points.
> >>>>
> >>>> Here is the list of some best practices to start with:
> >>>>
> >>>> 1. Use [] Instead of New Array()
> >>>> 2. Long list of variables? Omit the "Var" keyword and use commas
> >>>> instead.
> >>>> 3. Reduce global variables
> >>>> 4. Use explicit blocks
> >>>> 5. Start blocks on the same line
> >>>> 6. Always, Always Use Semicolons - Having said that, this is a very
> bad
> >>>> practice that can potentially lead to much bigger, and harder to find,
> >>>> issues.
> >>>> 7. Optimize loops. Avoid calculating the length of array in for loop
> >>>> iteration.
> >>>> 8. Avoid multiple redundant jQuery DOM manupulation by saving
> reference
> >>>> to
> >>>> any object.
> >>>> 9. Try to use meaningful comments.
> >>>> 10. Many more.
> >>>>
> >>>> Here are some links of best practices information-
> >>>>
> >>>> https://www.w3.org/wiki/JavaScript_best_practices
> >>>> http://www.codeproject.com/Articles/580165/JavaScript-Best-Practices
> >>>> https://developer.yahoo.com/performance/rules.html
> >>>>
> >>>> If everyone agrees, I would like to start on this work.
> >>>>
> >>>> Please let me know your thoughts on it.
> >>>>
> >>>> Thanks and Regards
> >>>> --
> >>>> Amardeep Singh Jhajj
> >>>>
> >>>>
> >>>>
> >
>

[Jacques Le Roux]

Fair enough, +1

Jacques


Le 28/06/2016 à 07:59, Taher Alkhateeb a écrit :

> +1 on approach
> On Jun 28, 2016 8:53 AM, "Pranay Pandey" <[hidden email]>
> wrote:
>
>> +1 Amardeep, mentioned approach is looking reasonable to me.
>>
>> Best regards,
>>
>> Pranay Pandey
>> HotWax Systems
>> http://www.hotwaxsystems.com/
>>
>> On Tue, Jun 28, 2016 at 11:21 AM, Amardeep Singh Jhajj <
>> [hidden email]> wrote:
>>
>>> Hello Jacques,
>>>
>>> Making branch is a good idea to handle regressions but I would prefer to
>>> work in trunk itself. Here are the things we should consider before
>>> creating new branch:
>>>
>>> 1. Branch can be abandoned, I would prefer to have code changes in trunk
>> in
>>> proper steps instead of merging the complete branch work later in trunk.
>>> 2. Currently, lot of changes is coming in trunk, so different branch need
>>> to updated regularly. Its also an additional work.
>>>
>>> To avoid regressions, we can do our work in granular level tasks for
>>> various functionality (wherever needed) and proper testing steps will be
>>> there. The code changes will only be committed after thorough testing.
>>>
>>> First, I would like to start with cleanup of inline javascripts so that
>> all
>>> javascript code will only in js files which helps us to follow best
>>> practices of javascript.
>>> Here is the steps can be taken to do it:
>>>
>>> 1. Start with one component. For example: Accounting.
>>> 2. Pick its various functionality one by one where javascript is added
>>> inline.
>>> 3. Do cleanup in it.
>>> 4. Do thorough testing for it with testing steps over ticket.
>>>
>>> Once the all cleanup (inline js cleanup) is done, we would have
>> javascript
>>> files for further work. We can further break the js work by functionality
>>> (if needed) for improvements.
>>>
>>> The above process will assure us that nothing will break. I will not work
>>> on this effort alone, the team of developers having two or more year
>>> experience in javascript will work with me.
>>>
>>> I will create the parent ticket for selenium tests as well and we will
>> see
>>> how we can work on it.
>>>
>>> Thanks & Regards
>>> --
>>> Amardeep Singh Jhajj
>>> www.hotwaxsystems.com
>>>
>>> On Sat, Jun 25, 2016 at 1:06 PM, Jacques Le Roux <
>>> [hidden email]> wrote:
>>>
>>>> Hi Amardeep,
>>>>
>>>> What I mean is we should be cautious. Hence the suggestion to create a
>>>> branch for the refactoring. And to benefit from this opportunity to put
>>>> some Selenium tests related with js (eg: calendar - could also use
>> HTML5
>>>> now -, autocompletion, lookups, dependent dropdowns). That would be a
>>> start
>>>> for Selenium, no needs to have tons of it. A Jira subtask would be
>>> perfect.
>>>> Hope I'm clearer
>>>>
>>>> Thanks
>>>>
>>>> Jacques
>>>>
>>>>
>>>>
>>>> Le 24/06/2016 à 15:53, Amardeep Singh Jhajj a écrit :
>>>>
>>>>> Thanks all for approval.
>>>>>
>>>>> Thanks Taher and Deepak for valuable suggestions. I will think on
>> them.
>>>>> Jacques,
>>>>>
>>>>> I am bit confused by your reply, could you please elaborate your
>> point.
>>>>> Regards,
>>>>> --
>>>>> Amardeep Singh Jhajj
>>>>>
>>>>>
>>>>> On Fri, Jun 24, 2016 at 4:17 PM, Jacques Le Roux <
>>>>> [hidden email]> wrote:
>>>>>
>>>>> Amardeep,
>>>>>> I agree with your points, I'd just request that we do that in a
>> branch
>>>>>> with a load of UI tests (good occasion to use Selenium).
>>>>>> Our js code is complex and fragile, I think notably at the global
>>>>>> variables in fieldlookup.js and selectall.js which are maybe hard to
>>>>>> avoid.
>>>>>> IMO those files are the main pains.
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>
>>>>>>
>>>>>> Le 24/06/2016 à 09:20, Amardeep Singh Jhajj a écrit :
>>>>>>
>>>>>> Hello everyone,
>>>>>>> Currently, OFBiz javascript code (except third party libraries) is
>> not
>>>>>>> written with the best practices which can cause following problems -
>>>>>>>
>>>>>>> 1. Increases the code maintenance effort.
>>>>>>> 2. Impact page performance.
>>>>>>> 3. Present not good examples to new contributors which leads to C/P
>> to
>>>>>>> various areas of js code.
>>>>>>>
>>>>>>> Here are things we should do for cleanup and improvements in js
>> code.
>>>>>>> 1. Remove unused javascript code and files if any.
>>>>>>> 2. Use best practices for javascript coding to improve performance
>> (I
>>>>>>> have
>>>>>>> listed some of it below).
>>>>>>> 3. Move utility js functions to one js file.
>>>>>>> 4. Remove deprecated code and use latest. For ex: We are still using
>>>>>>> "language='javascript'" attribute at script tag which is deprecated
>> a
>>>>>>> years
>>>>>>> ago.
>>>>>>> 5. js should be loaded at bottom of the page, currently its in
>> Header.
>>>>>>> Its
>>>>>>> a tedious task now to move it into footer because we have lot of js
>>> code
>>>>>>> inline in ftls.
>>>>>>> 6. js should not be written inline, it should be enough generic to
>> be
>>> in
>>>>>>> minimum number of files and have generic code for doing the common
>> set
>>>>>>> of
>>>>>>> operations over DOM.
>>>>>>> 7. Currently our macros of rendering pages has inline scripts, they
>>> can
>>>>>>> be
>>>>>>> moved to one macrorenderer.js with generic code as we can use
>> classes,
>>>>>>> ids
>>>>>>> and data-attributes for doing any operation over html DOM.
>>>>>>> 8. After all cleanup work, we can think of build tool (like grunt)
>> for
>>>>>>> various javascript build tasks (minification, concatenation of
>> files)
>>> if
>>>>>>> needed. Its just a thought.
>>>>>>>
>>>>>>> I know its a huge effort and need to be done carefully. So before
>>> doing
>>>>>>> any
>>>>>>> major changes, I would like to start work with first 4 points.
>>>>>>>
>>>>>>> Here is the list of some best practices to start with:
>>>>>>>
>>>>>>> 1. Use [] Instead of New Array()
>>>>>>> 2. Long list of variables? Omit the "Var" keyword and use commas
>>>>>>> instead.
>>>>>>> 3. Reduce global variables
>>>>>>> 4. Use explicit blocks
>>>>>>> 5. Start blocks on the same line
>>>>>>> 6. Always, Always Use Semicolons - Having said that, this is a very
>>> bad
>>>>>>> practice that can potentially lead to much bigger, and harder to
>> find,
>>>>>>> issues.
>>>>>>> 7. Optimize loops. Avoid calculating the length of array in for loop
>>>>>>> iteration.
>>>>>>> 8. Avoid multiple redundant jQuery DOM manupulation by saving
>>> reference
>>>>>>> to
>>>>>>> any object.
>>>>>>> 9. Try to use meaningful comments.
>>>>>>> 10. Many more.
>>>>>>>
>>>>>>> Here are some links of best practices information-
>>>>>>>
>>>>>>> https://www.w3.org/wiki/JavaScript_best_practices
>>>>>>>
>> http://www.codeproject.com/Articles/580165/JavaScript-Best-Practices
>>>>>>> https://developer.yahoo.com/performance/rules.html
>>>>>>>
>>>>>>> If everyone agrees, I would like to start on this work.
>>>>>>>
>>>>>>> Please let me know your thoughts on it.
>>>>>>>
>>>>>>> Thanks and Regards
>>>>>>> --
>>>>>>> Amardeep Singh Jhajj
>>>>>>>
>>>>>>>
>>>>>>>

[Amardeep Singh Jhajj-2]

Thanks all for approval. I will start work on it.

Regards,
--
Amardeep Singh Jhajj
www.hotwaxsystems.com

On Tue, Jun 28, 2016 at 11:51 AM, Jacques Le Roux <
[hidden email]> wrote:

> Fair enough, +1
>
> Jacques
>
>
>
> Le 28/06/2016 à 07:59, Taher Alkhateeb a écrit :
>
>> +1 on approach
>> On Jun 28, 2016 8:53 AM, "Pranay Pandey" <[hidden email]
>> >
>> wrote:
>>
>> +1 Amardeep, mentioned approach is looking reasonable to me.
>>>
>>> Best regards,
>>>
>>> Pranay Pandey
>>> HotWax Systems
>>> http://www.hotwaxsystems.com/
>>>
>>> On Tue, Jun 28, 2016 at 11:21 AM, Amardeep Singh Jhajj <
>>> [hidden email]> wrote:
>>>
>>> Hello Jacques,
>>>>
>>>> Making branch is a good idea to handle regressions but I would prefer to
>>>> work in trunk itself. Here are the things we should consider before
>>>> creating new branch:
>>>>
>>>> 1. Branch can be abandoned, I would prefer to have code changes in trunk
>>>>
>>> in
>>>
>>>> proper steps instead of merging the complete branch work later in trunk.
>>>> 2. Currently, lot of changes is coming in trunk, so different branch
>>>> need
>>>> to updated regularly. Its also an additional work.
>>>>
>>>> To avoid regressions, we can do our work in granular level tasks for
>>>> various functionality (wherever needed) and proper testing steps will be
>>>> there. The code changes will only be committed after thorough testing.
>>>>
>>>> First, I would like to start with cleanup of inline javascripts so that
>>>>
>>> all
>>>
>>>> javascript code will only in js files which helps us to follow best
>>>> practices of javascript.
>>>> Here is the steps can be taken to do it:
>>>>
>>>> 1. Start with one component. For example: Accounting.
>>>> 2. Pick its various functionality one by one where javascript is added
>>>> inline.
>>>> 3. Do cleanup in it.
>>>> 4. Do thorough testing for it with testing steps over ticket.
>>>>
>>>> Once the all cleanup (inline js cleanup) is done, we would have
>>>>
>>> javascript
>>>
>>>> files for further work. We can further break the js work by
>>>> functionality
>>>> (if needed) for improvements.
>>>>
>>>> The above process will assure us that nothing will break. I will not
>>>> work
>>>> on this effort alone, the team of developers having two or more year
>>>> experience in javascript will work with me.
>>>>
>>>> I will create the parent ticket for selenium tests as well and we will
>>>>
>>> see
>>>
>>>> how we can work on it.
>>>>
>>>> Thanks & Regards
>>>> --
>>>> Amardeep Singh Jhajj
>>>> www.hotwaxsystems.com
>>>>
>>>> On Sat, Jun 25, 2016 at 1:06 PM, Jacques Le Roux <
>>>> [hidden email]> wrote:
>>>>
>>>> Hi Amardeep,
>>>>>
>>>>> What I mean is we should be cautious. Hence the suggestion to create a
>>>>> branch for the refactoring. And to benefit from this opportunity to put
>>>>> some Selenium tests related with js (eg: calendar - could also use
>>>>>
>>>> HTML5
>>>
>>>> now -, autocompletion, lookups, dependent dropdowns). That would be a
>>>>>
>>>> start
>>>>
>>>>> for Selenium, no needs to have tons of it. A Jira subtask would be
>>>>>
>>>> perfect.
>>>>
>>>>> Hope I'm clearer
>>>>>
>>>>> Thanks
>>>>>
>>>>> Jacques
>>>>>
>>>>>
>>>>>
>>>>> Le 24/06/2016 à 15:53, Amardeep Singh Jhajj a écrit :
>>>>>
>>>>> Thanks all for approval.
>>>>>>
>>>>>> Thanks Taher and Deepak for valuable suggestions. I will think on
>>>>>>
>>>>> them.
>>>
>>>> Jacques,
>>>>>>
>>>>>> I am bit confused by your reply, could you please elaborate your
>>>>>>
>>>>> point.
>>>
>>>> Regards,
>>>>>> --
>>>>>> Amardeep Singh Jhajj
>>>>>>
>>>>>>
>>>>>> On Fri, Jun 24, 2016 at 4:17 PM, Jacques Le Roux <
>>>>>> [hidden email]> wrote:
>>>>>>
>>>>>> Amardeep,
>>>>>>
>>>>>>> I agree with your points, I'd just request that we do that in a
>>>>>>>
>>>>>> branch
>>>
>>>> with a load of UI tests (good occasion to use Selenium).
>>>>>>> Our js code is complex and fragile, I think notably at the global
>>>>>>> variables in fieldlookup.js and selectall.js which are maybe hard to
>>>>>>> avoid.
>>>>>>> IMO those files are the main pains.
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Le 24/06/2016 à 09:20, Amardeep Singh Jhajj a écrit :
>>>>>>>
>>>>>>> Hello everyone,
>>>>>>>
>>>>>>>> Currently, OFBiz javascript code (except third party libraries) is
>>>>>>>>
>>>>>>> not
>>>
>>>> written with the best practices which can cause following problems -
>>>>>>>>
>>>>>>>> 1. Increases the code maintenance effort.
>>>>>>>> 2. Impact page performance.
>>>>>>>> 3. Present not good examples to new contributors which leads to C/P
>>>>>>>>
>>>>>>> to
>>>
>>>> various areas of js code.
>>>>>>>>
>>>>>>>> Here are things we should do for cleanup and improvements in js
>>>>>>>>
>>>>>>> code.
>>>
>>>> 1. Remove unused javascript code and files if any.
>>>>>>>> 2. Use best practices for javascript coding to improve performance
>>>>>>>>
>>>>>>> (I
>>>
>>>> have
>>>>>>>> listed some of it below).
>>>>>>>> 3. Move utility js functions to one js file.
>>>>>>>> 4. Remove deprecated code and use latest. For ex: We are still using
>>>>>>>> "language='javascript'" attribute at script tag which is deprecated
>>>>>>>>
>>>>>>> a
>>>
>>>> years
>>>>>>>> ago.
>>>>>>>> 5. js should be loaded at bottom of the page, currently its in
>>>>>>>>
>>>>>>> Header.
>>>
>>>> Its
>>>>>>>> a tedious task now to move it into footer because we have lot of js
>>>>>>>>
>>>>>>> code
>>>>
>>>>> inline in ftls.
>>>>>>>> 6. js should not be written inline, it should be enough generic to
>>>>>>>>
>>>>>>> be
>>>
>>>> in
>>>>
>>>>> minimum number of files and have generic code for doing the common
>>>>>>>>
>>>>>>> set
>>>
>>>> of
>>>>>>>> operations over DOM.
>>>>>>>> 7. Currently our macros of rendering pages has inline scripts, they
>>>>>>>>
>>>>>>> can
>>>>
>>>>> be
>>>>>>>> moved to one macrorenderer.js with generic code as we can use
>>>>>>>>
>>>>>>> classes,
>>>
>>>> ids
>>>>>>>> and data-attributes for doing any operation over html DOM.
>>>>>>>> 8. After all cleanup work, we can think of build tool (like grunt)
>>>>>>>>
>>>>>>> for
>>>
>>>> various javascript build tasks (minification, concatenation of
>>>>>>>>
>>>>>>> files)
>>>
>>>> if
>>>>
>>>>> needed. Its just a thought.
>>>>>>>>
>>>>>>>> I know its a huge effort and need to be done carefully. So before
>>>>>>>>
>>>>>>> doing
>>>>
>>>>> any
>>>>>>>> major changes, I would like to start work with first 4 points.
>>>>>>>>
>>>>>>>> Here is the list of some best practices to start with:
>>>>>>>>
>>>>>>>> 1. Use [] Instead of New Array()
>>>>>>>> 2. Long list of variables? Omit the "Var" keyword and use commas
>>>>>>>> instead.
>>>>>>>> 3. Reduce global variables
>>>>>>>> 4. Use explicit blocks
>>>>>>>> 5. Start blocks on the same line
>>>>>>>> 6. Always, Always Use Semicolons - Having said that, this is a very
>>>>>>>>
>>>>>>> bad
>>>>
>>>>> practice that can potentially lead to much bigger, and harder to
>>>>>>>>
>>>>>>> find,
>>>
>>>> issues.
>>>>>>>> 7. Optimize loops. Avoid calculating the length of array in for loop
>>>>>>>> iteration.
>>>>>>>> 8. Avoid multiple redundant jQuery DOM manupulation by saving
>>>>>>>>
>>>>>>> reference
>>>>
>>>>> to
>>>>>>>> any object.
>>>>>>>> 9. Try to use meaningful comments.
>>>>>>>> 10. Many more.
>>>>>>>>
>>>>>>>> Here are some links of best practices information-
>>>>>>>>
>>>>>>>> https://www.w3.org/wiki/JavaScript_best_practices
>>>>>>>>
>>>>>>>> http://www.codeproject.com/Articles/580165/JavaScript-Best-Practices
>>>
>>>> https://developer.yahoo.com/performance/rules.html
>>>>>>>>
>>>>>>>> If everyone agrees, I would like to start on this work.
>>>>>>>>
>>>>>>>> Please let me know your thoughts on it.
>>>>>>>>
>>>>>>>> Thanks and Regards
>>>>>>>> --
>>>>>>>> Amardeep Singh Jhajj
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>

[Gavin Mabie-2]

+1

On Wed, Jun 29, 2016 at 1:10 PM, Amardeep Singh Jhajj <
[hidden email]> wrote:

> Thanks all for approval. I will start work on it.
>
> Regards,
> --
> Amardeep Singh Jhajj
> www.hotwaxsystems.com
>
> On Tue, Jun 28, 2016 at 11:51 AM, Jacques Le Roux <
> [hidden email]> wrote:
>
> > Fair enough, +1
> >
> > Jacques
> >
> >
> >
> > Le 28/06/2016 à 07:59, Taher Alkhateeb a écrit :
> >
> >> +1 on approach
> >> On Jun 28, 2016 8:53 AM, "Pranay Pandey" <
> [hidden email]
> >> >
> >> wrote:
> >>
> >> +1 Amardeep, mentioned approach is looking reasonable to me.
> >>>
> >>> Best regards,
> >>>
> >>> Pranay Pandey
> >>> HotWax Systems
> >>> http://www.hotwaxsystems.com/
> >>>
> >>> On Tue, Jun 28, 2016 at 11:21 AM, Amardeep Singh Jhajj <
> >>> [hidden email]> wrote:
> >>>
> >>> Hello Jacques,
> >>>>
> >>>> Making branch is a good idea to handle regressions but I would prefer
> to
> >>>> work in trunk itself. Here are the things we should consider before
> >>>> creating new branch:
> >>>>
> >>>> 1. Branch can be abandoned, I would prefer to have code changes in
> trunk
> >>>>
> >>> in
> >>>
> >>>> proper steps instead of merging the complete branch work later in
> trunk.
> >>>> 2. Currently, lot of changes is coming in trunk, so different branch
> >>>> need
> >>>> to updated regularly. Its also an additional work.
> >>>>
> >>>> To avoid regressions, we can do our work in granular level tasks for
> >>>> various functionality (wherever needed) and proper testing steps will
> be
> >>>> there. The code changes will only be committed after thorough testing.
> >>>>
> >>>> First, I would like to start with cleanup of inline javascripts so
> that
> >>>>
> >>> all
> >>>
> >>>> javascript code will only in js files which helps us to follow best
> >>>> practices of javascript.
> >>>> Here is the steps can be taken to do it:
> >>>>
> >>>> 1. Start with one component. For example: Accounting.
> >>>> 2. Pick its various functionality one by one where javascript is added
> >>>> inline.
> >>>> 3. Do cleanup in it.
> >>>> 4. Do thorough testing for it with testing steps over ticket.
> >>>>
> >>>> Once the all cleanup (inline js cleanup) is done, we would have
> >>>>
> >>> javascript
> >>>
> >>>> files for further work. We can further break the js work by
> >>>> functionality
> >>>> (if needed) for improvements.
> >>>>
> >>>> The above process will assure us that nothing will break. I will not
> >>>> work
> >>>> on this effort alone, the team of developers having two or more year
> >>>> experience in javascript will work with me.
> >>>>
> >>>> I will create the parent ticket for selenium tests as well and we will
> >>>>
> >>> see
> >>>
> >>>> how we can work on it.
> >>>>
> >>>> Thanks & Regards
> >>>> --
> >>>> Amardeep Singh Jhajj
> >>>> www.hotwaxsystems.com
> >>>>
> >>>> On Sat, Jun 25, 2016 at 1:06 PM, Jacques Le Roux <
> >>>> [hidden email]> wrote:
> >>>>
> >>>> Hi Amardeep,
> >>>>>
> >>>>> What I mean is we should be cautious. Hence the suggestion to create
> a
> >>>>> branch for the refactoring. And to benefit from this opportunity to
> put
> >>>>> some Selenium tests related with js (eg: calendar - could also use
> >>>>>
> >>>> HTML5
> >>>
> >>>> now -, autocompletion, lookups, dependent dropdowns). That would be a
> >>>>>
> >>>> start
> >>>>
> >>>>> for Selenium, no needs to have tons of it. A Jira subtask would be
> >>>>>
> >>>> perfect.
> >>>>
> >>>>> Hope I'm clearer
> >>>>>
> >>>>> Thanks
> >>>>>
> >>>>> Jacques
> >>>>>
> >>>>>
> >>>>>
> >>>>> Le 24/06/2016 à 15:53, Amardeep Singh Jhajj a écrit :
> >>>>>
> >>>>> Thanks all for approval.
> >>>>>>
> >>>>>> Thanks Taher and Deepak for valuable suggestions. I will think on
> >>>>>>
> >>>>> them.
> >>>
> >>>> Jacques,
> >>>>>>
> >>>>>> I am bit confused by your reply, could you please elaborate your
> >>>>>>
> >>>>> point.
> >>>
> >>>> Regards,
> >>>>>> --
> >>>>>> Amardeep Singh Jhajj
> >>>>>>
> >>>>>>
> >>>>>> On Fri, Jun 24, 2016 at 4:17 PM, Jacques Le Roux <
> >>>>>> [hidden email]> wrote:
> >>>>>>
> >>>>>> Amardeep,
> >>>>>>
> >>>>>>> I agree with your points, I'd just request that we do that in a
> >>>>>>>
> >>>>>> branch
> >>>
> >>>> with a load of UI tests (good occasion to use Selenium).
> >>>>>>> Our js code is complex and fragile, I think notably at the global
> >>>>>>> variables in fieldlookup.js and selectall.js which are maybe hard
> to
> >>>>>>> avoid.
> >>>>>>> IMO those files are the main pains.
> >>>>>>>
> >>>>>>> Thanks
> >>>>>>>
> >>>>>>> Jacques
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> Le 24/06/2016 à 09:20, Amardeep Singh Jhajj a écrit :
> >>>>>>>
> >>>>>>> Hello everyone,
> >>>>>>>
> >>>>>>>> Currently, OFBiz javascript code (except third party libraries) is
> >>>>>>>>
> >>>>>>> not
> >>>
> >>>> written with the best practices which can cause following problems -
> >>>>>>>>
> >>>>>>>> 1. Increases the code maintenance effort.
> >>>>>>>> 2. Impact page performance.
> >>>>>>>> 3. Present not good examples to new contributors which leads to
> C/P
> >>>>>>>>
> >>>>>>> to
> >>>
> >>>> various areas of js code.
> >>>>>>>>
> >>>>>>>> Here are things we should do for cleanup and improvements in js
> >>>>>>>>
> >>>>>>> code.
> >>>
> >>>> 1. Remove unused javascript code and files if any.
> >>>>>>>> 2. Use best practices for javascript coding to improve performance
> >>>>>>>>
> >>>>>>> (I
> >>>
> >>>> have
> >>>>>>>> listed some of it below).
> >>>>>>>> 3. Move utility js functions to one js file.
> >>>>>>>> 4. Remove deprecated code and use latest. For ex: We are still
> using
> >>>>>>>> "language='javascript'" attribute at script tag which is
> deprecated
> >>>>>>>>
> >>>>>>> a
> >>>
> >>>> years
> >>>>>>>> ago.
> >>>>>>>> 5. js should be loaded at bottom of the page, currently its in
> >>>>>>>>
> >>>>>>> Header.
> >>>
> >>>> Its
> >>>>>>>> a tedious task now to move it into footer because we have lot of
> js
> >>>>>>>>
> >>>>>>> code
> >>>>
> >>>>> inline in ftls.
> >>>>>>>> 6. js should not be written inline, it should be enough generic to
> >>>>>>>>
> >>>>>>> be
> >>>
> >>>> in
> >>>>
> >>>>> minimum number of files and have generic code for doing the common
> >>>>>>>>
> >>>>>>> set
> >>>
> >>>> of
> >>>>>>>> operations over DOM.
> >>>>>>>> 7. Currently our macros of rendering pages has inline scripts,
> they
> >>>>>>>>
> >>>>>>> can
> >>>>
> >>>>> be
> >>>>>>>> moved to one macrorenderer.js with generic code as we can use
> >>>>>>>>
> >>>>>>> classes,
> >>>
> >>>> ids
> >>>>>>>> and data-attributes for doing any operation over html DOM.
> >>>>>>>> 8. After all cleanup work, we can think of build tool (like grunt)
> >>>>>>>>
> >>>>>>> for
> >>>
> >>>> various javascript build tasks (minification, concatenation of
> >>>>>>>>
> >>>>>>> files)
> >>>
> >>>> if
> >>>>
> >>>>> needed. Its just a thought.
> >>>>>>>>
> >>>>>>>> I know its a huge effort and need to be done carefully. So before
> >>>>>>>>
> >>>>>>> doing
> >>>>
> >>>>> any
> >>>>>>>> major changes, I would like to start work with first 4 points.
> >>>>>>>>
> >>>>>>>> Here is the list of some best practices to start with:
> >>>>>>>>
> >>>>>>>> 1. Use [] Instead of New Array()
> >>>>>>>> 2. Long list of variables? Omit the "Var" keyword and use commas
> >>>>>>>> instead.
> >>>>>>>> 3. Reduce global variables
> >>>>>>>> 4. Use explicit blocks
> >>>>>>>> 5. Start blocks on the same line
> >>>>>>>> 6. Always, Always Use Semicolons - Having said that, this is a
> very
> >>>>>>>>
> >>>>>>> bad
> >>>>
> >>>>> practice that can potentially lead to much bigger, and harder to
> >>>>>>>>
> >>>>>>> find,
> >>>
> >>>> issues.
> >>>>>>>> 7. Optimize loops. Avoid calculating the length of array in for
> loop
> >>>>>>>> iteration.
> >>>>>>>> 8. Avoid multiple redundant jQuery DOM manupulation by saving
> >>>>>>>>
> >>>>>>> reference
> >>>>
> >>>>> to
> >>>>>>>> any object.
> >>>>>>>> 9. Try to use meaningful comments.
> >>>>>>>> 10. Many more.
> >>>>>>>>
> >>>>>>>> Here are some links of best practices information-
> >>>>>>>>
> >>>>>>>> https://www.w3.org/wiki/JavaScript_best_practices
> >>>>>>>>
> >>>>>>>>
> http://www.codeproject.com/Articles/580165/JavaScript-Best-Practices
> >>>
> >>>> https://developer.yahoo.com/performance/rules.html
> >>>>>>>>
> >>>>>>>> If everyone agrees, I would like to start on this work.
> >>>>>>>>
> >>>>>>>> Please let me know your thoughts on it.
> >>>>>>>>
> >>>>>>>> Thanks and Regards
> >>>>>>>> --
> >>>>>>>> Amardeep Singh Jhajj
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >
>

[Pierre Smits]

The suggestion sound very reasonable and actionable, so:

+1

I suggest a JIRA issue is opened for this that references this thread,
accompanied by the necessary sub-tasks (if any, and to be able to keep the
patch files(s) as concise as possible per component [1]) regarding
depending aspects (e.g. documentation). That way we can tie this in to
future releases and not forget the other elements of the bigger picture.

[1] large patch files are very hard to evaluate, and might lead to stale
code improvements when not addressed in an appropriate time span.

Best regards,

Pierre Smits

ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Wed, Jun 29, 2016 at 1:32 PM, Gavin Mabie <[hidden email]> wrote:

> +1
>
> On Wed, Jun 29, 2016 at 1:10 PM, Amardeep Singh Jhajj <
> [hidden email]> wrote:
>
> > Thanks all for approval. I will start work on it.
> >
> > Regards,
> > --
> > Amardeep Singh Jhajj
> > www.hotwaxsystems.com
> >
> > On Tue, Jun 28, 2016 at 11:51 AM, Jacques Le Roux <
> > [hidden email]> wrote:
> >
> > > Fair enough, +1
> > >
> > > Jacques
> > >
> > >
> > >
> > > Le 28/06/2016 à 07:59, Taher Alkhateeb a écrit :
> > >
> > >> +1 on approach
> > >> On Jun 28, 2016 8:53 AM, "Pranay Pandey" <
> > [hidden email]
> > >> >
> > >> wrote:
> > >>
> > >> +1 Amardeep, mentioned approach is looking reasonable to me.
> > >>>
> > >>> Best regards,
> > >>>
> > >>> Pranay Pandey
> > >>> HotWax Systems
> > >>> http://www.hotwaxsystems.com/
> > >>>
> > >>> On Tue, Jun 28, 2016 at 11:21 AM, Amardeep Singh Jhajj <
> > >>> [hidden email]> wrote:
> > >>>
> > >>> Hello Jacques,
> > >>>>
> > >>>> Making branch is a good idea to handle regressions but I would
> prefer
> > to
> > >>>> work in trunk itself. Here are the things we should consider before
> > >>>> creating new branch:
> > >>>>
> > >>>> 1. Branch can be abandoned, I would prefer to have code changes in
> > trunk
> > >>>>
> > >>> in
> > >>>
> > >>>> proper steps instead of merging the complete branch work later in
> > trunk.
> > >>>> 2. Currently, lot of changes is coming in trunk, so different branch
> > >>>> need
> > >>>> to updated regularly. Its also an additional work.
> > >>>>
> > >>>> To avoid regressions, we can do our work in granular level tasks for
> > >>>> various functionality (wherever needed) and proper testing steps
> will
> > be
> > >>>> there. The code changes will only be committed after thorough
> testing.
> > >>>>
> > >>>> First, I would like to start with cleanup of inline javascripts so
> > that
> > >>>>
> > >>> all
> > >>>
> > >>>> javascript code will only in js files which helps us to follow best
> > >>>> practices of javascript.
> > >>>> Here is the steps can be taken to do it:
> > >>>>
> > >>>> 1. Start with one component. For example: Accounting.
> > >>>> 2. Pick its various functionality one by one where javascript is
> added
> > >>>> inline.
> > >>>> 3. Do cleanup in it.
> > >>>> 4. Do thorough testing for it with testing steps over ticket.
> > >>>>
> > >>>> Once the all cleanup (inline js cleanup) is done, we would have
> > >>>>
> > >>> javascript
> > >>>
> > >>>> files for further work. We can further break the js work by
> > >>>> functionality
> > >>>> (if needed) for improvements.
> > >>>>
> > >>>> The above process will assure us that nothing will break. I will not
> > >>>> work
> > >>>> on this effort alone, the team of developers having two or more year
> > >>>> experience in javascript will work with me.
> > >>>>
> > >>>> I will create the parent ticket for selenium tests as well and we
> will
> > >>>>
> > >>> see
> > >>>
> > >>>> how we can work on it.
> > >>>>
> > >>>> Thanks & Regards
> > >>>> --
> > >>>> Amardeep Singh Jhajj
> > >>>> www.hotwaxsystems.com
> > >>>>
> > >>>> On Sat, Jun 25, 2016 at 1:06 PM, Jacques Le Roux <
> > >>>> [hidden email]> wrote:
> > >>>>
> > >>>> Hi Amardeep,
> > >>>>>
> > >>>>> What I mean is we should be cautious. Hence the suggestion to
> create
> > a
> > >>>>> branch for the refactoring. And to benefit from this opportunity to
> > put
> > >>>>> some Selenium tests related with js (eg: calendar - could also use
> > >>>>>
> > >>>> HTML5
> > >>>
> > >>>> now -, autocompletion, lookups, dependent dropdowns). That would be
> a
> > >>>>>
> > >>>> start
> > >>>>
> > >>>>> for Selenium, no needs to have tons of it. A Jira subtask would be
> > >>>>>
> > >>>> perfect.
> > >>>>
> > >>>>> Hope I'm clearer
> > >>>>>
> > >>>>> Thanks
> > >>>>>
> > >>>>> Jacques
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> Le 24/06/2016 à 15:53, Amardeep Singh Jhajj a écrit :
> > >>>>>
> > >>>>> Thanks all for approval.
> > >>>>>>
> > >>>>>> Thanks Taher and Deepak for valuable suggestions. I will think on
> > >>>>>>
> > >>>>> them.
> > >>>
> > >>>> Jacques,
> > >>>>>>
> > >>>>>> I am bit confused by your reply, could you please elaborate your
> > >>>>>>
> > >>>>> point.
> > >>>
> > >>>> Regards,
> > >>>>>> --
> > >>>>>> Amardeep Singh Jhajj
> > >>>>>>
> > >>>>>>
> > >>>>>> On Fri, Jun 24, 2016 at 4:17 PM, Jacques Le Roux <
> > >>>>>> [hidden email]> wrote:
> > >>>>>>
> > >>>>>> Amardeep,
> > >>>>>>
> > >>>>>>> I agree with your points, I'd just request that we do that in a
> > >>>>>>>
> > >>>>>> branch
> > >>>
> > >>>> with a load of UI tests (good occasion to use Selenium).
> > >>>>>>> Our js code is complex and fragile, I think notably at the global
> > >>>>>>> variables in fieldlookup.js and selectall.js which are maybe hard
> > to
> > >>>>>>> avoid.
> > >>>>>>> IMO those files are the main pains.
> > >>>>>>>
> > >>>>>>> Thanks
> > >>>>>>>
> > >>>>>>> Jacques
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> Le 24/06/2016 à 09:20, Amardeep Singh Jhajj a écrit :
> > >>>>>>>
> > >>>>>>> Hello everyone,
> > >>>>>>>
> > >>>>>>>> Currently, OFBiz javascript code (except third party libraries)
> is
> > >>>>>>>>
> > >>>>>>> not
> > >>>
> > >>>> written with the best practices which can cause following problems -
> > >>>>>>>>
> > >>>>>>>> 1. Increases the code maintenance effort.
> > >>>>>>>> 2. Impact page performance.
> > >>>>>>>> 3. Present not good examples to new contributors which leads to
> > C/P
> > >>>>>>>>
> > >>>>>>> to
> > >>>
> > >>>> various areas of js code.
> > >>>>>>>>
> > >>>>>>>> Here are things we should do for cleanup and improvements in js
> > >>>>>>>>
> > >>>>>>> code.
> > >>>
> > >>>> 1. Remove unused javascript code and files if any.
> > >>>>>>>> 2. Use best practices for javascript coding to improve
> performance
> > >>>>>>>>
> > >>>>>>> (I
> > >>>
> > >>>> have
> > >>>>>>>> listed some of it below).
> > >>>>>>>> 3. Move utility js functions to one js file.
> > >>>>>>>> 4. Remove deprecated code and use latest. For ex: We are still
> > using
> > >>>>>>>> "language='javascript'" attribute at script tag which is
> > deprecated
> > >>>>>>>>
> > >>>>>>> a
> > >>>
> > >>>> years
> > >>>>>>>> ago.
> > >>>>>>>> 5. js should be loaded at bottom of the page, currently its in
> > >>>>>>>>
> > >>>>>>> Header.
> > >>>
> > >>>> Its
> > >>>>>>>> a tedious task now to move it into footer because we have lot of
> > js
> > >>>>>>>>
> > >>>>>>> code
> > >>>>
> > >>>>> inline in ftls.
> > >>>>>>>> 6. js should not be written inline, it should be enough generic
> to
> > >>>>>>>>
> > >>>>>>> be
> > >>>
> > >>>> in
> > >>>>
> > >>>>> minimum number of files and have generic code for doing the common
> > >>>>>>>>
> > >>>>>>> set
> > >>>
> > >>>> of
> > >>>>>>>> operations over DOM.
> > >>>>>>>> 7. Currently our macros of rendering pages has inline scripts,
> > they
> > >>>>>>>>
> > >>>>>>> can
> > >>>>
> > >>>>> be
> > >>>>>>>> moved to one macrorenderer.js with generic code as we can use
> > >>>>>>>>
> > >>>>>>> classes,
> > >>>
> > >>>> ids
> > >>>>>>>> and data-attributes for doing any operation over html DOM.
> > >>>>>>>> 8. After all cleanup work, we can think of build tool (like
> grunt)
> > >>>>>>>>
> > >>>>>>> for
> > >>>
> > >>>> various javascript build tasks (minification, concatenation of
> > >>>>>>>>
> > >>>>>>> files)
> > >>>
> > >>>> if
> > >>>>
> > >>>>> needed. Its just a thought.
> > >>>>>>>>
> > >>>>>>>> I know its a huge effort and need to be done carefully. So
> before
> > >>>>>>>>
> > >>>>>>> doing
> > >>>>
> > >>>>> any
> > >>>>>>>> major changes, I would like to start work with first 4 points.
> > >>>>>>>>
> > >>>>>>>> Here is the list of some best practices to start with:
> > >>>>>>>>
> > >>>>>>>> 1. Use [] Instead of New Array()
> > >>>>>>>> 2. Long list of variables? Omit the "Var" keyword and use commas
> > >>>>>>>> instead.
> > >>>>>>>> 3. Reduce global variables
> > >>>>>>>> 4. Use explicit blocks
> > >>>>>>>> 5. Start blocks on the same line
> > >>>>>>>> 6. Always, Always Use Semicolons - Having said that, this is a
> > very
> > >>>>>>>>
> > >>>>>>> bad
> > >>>>
> > >>>>> practice that can potentially lead to much bigger, and harder to
> > >>>>>>>>
> > >>>>>>> find,
> > >>>
> > >>>> issues.
> > >>>>>>>> 7. Optimize loops. Avoid calculating the length of array in for
> > loop
> > >>>>>>>> iteration.
> > >>>>>>>> 8. Avoid multiple redundant jQuery DOM manupulation by saving
> > >>>>>>>>
> > >>>>>>> reference
> > >>>>
> > >>>>> to
> > >>>>>>>> any object.
> > >>>>>>>> 9. Try to use meaningful comments.
> > >>>>>>>> 10. Many more.
> > >>>>>>>>
> > >>>>>>>> Here are some links of best practices information-
> > >>>>>>>>
> > >>>>>>>> https://www.w3.org/wiki/JavaScript_best_practices
> > >>>>>>>>
> > >>>>>>>>
> > http://www.codeproject.com/Articles/580165/JavaScript-Best-Practices
> > >>>
> > >>>> https://developer.yahoo.com/performance/rules.html
> > >>>>>>>>
> > >>>>>>>> If everyone agrees, I would like to start on this work.
> > >>>>>>>>
> > >>>>>>>> Please let me know your thoughts on it.
> > >>>>>>>>
> > >>>>>>>> Thanks and Regards
> > >>>>>>>> --
> > >>>>>>>> Amardeep Singh Jhajj
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >
> >
>