[jira] [Commented] (OFBIZ-1319) Split javascript files to have more generic ones includable in all screens, and the more specific ones included more locally

[Nicolas Malin (Jira)]

    [ https://issues.apache.org/jira/browse/OFBIZ-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15360207#comment-15360207 ]

Amardeep Singh Jhajj commented on OFBIZ-1319:
---------------------------------------------

I agree with you that having smaller files with their related topics. But I would suggest to have one file for now for all utilities because increasing number of js files in page will increase the HTTP request. Please read - Minimize HTTP Requests

https://developer.yahoo.com/performance/rules.html

Here, one thing can be done in future that we may add some mechanism for concatenation of js files (using build tools) into one file, which normally done for js files which includes in all pages. This one file further minimized during build. So concatenation, minification can be a part of build process. I am not currently planned or thought about the build process for it.

In that case we can break current selectall.js into smaller files. So its just my thought, i am open to suggestions from you :)

Currently, I am focusing on following things-

1. Simplify and improve currently written utilities so that it can be used from any where using class, id or data attributes. It will help us to remove inline js in ftls.
2. Removing unused code from selectall.js

> Split javascript files to have more generic ones includable in all screens, and the more specific ones included more locally
> ----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: OFBIZ-1319
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-1319
>             Project: OFBiz
>          Issue Type: Improvement
>          Components: framework
>    Affects Versions: Trunk
>            Reporter: Jacques Le Roux
>            Assignee: Jacques Le Roux
>            Priority: Minor
>
> From a David's E. Jones comment on ML :
> We should split up javascript files to have the more generic ones includable in all screens, and the more specific ones (like the toggle* and selectAll* methods in there) into a file that can be included more locally.

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[Ron Wheeler]

On 02/07/2016 11:10 AM, Amardeep Singh Jhajj (JIRA) wrote:
>      [ https://issues.apache.org/jira/browse/OFBIZ-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15360207#comment-15360207 ]
>
> Amardeep Singh Jhajj commented on OFBIZ-1319:
> ---------------------------------------------
>
> I agree with you that having smaller files with their related topics. But I would suggest to have one file for now for all utilities because increasing number of js files in page will increase the HTTP request. Please read - Minimize HTTP Requests
Separating modules that are always required from modules that are only
required for specific pages or groups of pages will increase the number
of http requests but make them smaller. Depending on caching, the extra
http requests might not be an issue. The organization's internal caching
policies (local proxies or squid for example) might be easier to
optimize the static code if the js files being cached are separate and
identified.
> https://developer.yahoo.com/performance/rules.html
>
> Here, one thing can be done in future that we may add some mechanism for concatenation of js files (using binng uild tools) into one file, which normally done for js files which includes in all pages. This one file further minimized during build. So concatenation, minification can be a part of build process. I am not currently planned or thought about the build process for it.

Separating delivery packaging from coding packaging is almost always a
good idea.

>
> In that case we can break current selectall.js into smaller files. So its just my thought, i am open to suggestions from you :)
>
> Currently, I am focusing on following things-
>
> 1. Simplify and improve currently written utilities so that it can be used from any where using class, id or data attributes. It will help us to remove inline js in ftls.
> 2. Removing unused code from selectall.js
>
>
>> Split javascript files to have more generic ones includable in all screens, and the more specific ones included more locally
>> ----------------------------------------------------------------------------------------------------------------------------
>>
>>                  Key: OFBIZ-1319
>>                  URL: https://issues.apache.org/jira/browse/OFBIZ-1319
>>              Project: OFBiz
>>           Issue Type: Improvement
>>           Components: framework
>>     Affects Versions: Trunk
>>             Reporter: Jacques Le Roux
>>             Assignee: Jacques Le Roux
>>             Priority: Minor
>>
>>  From a David's E. Jones comment on ML :
>> We should split up javascript files to have the more generic ones includable in all screens, and the more specific ones (like the toggle* and selectAll* methods in there) into a file that can be included more locally.
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)
>

--
Ron Wheeler
President
Artifact Software Inc
email: [hidden email]
skype: ronaldmwheeler
phone: [phone], ext 102

[Amardeep Singh Jhajj-2]

Separating modules that are always required from modules that are only
required for specific pages or groups of pages will increase the number of
http requests but make them smaller
-- I agree, specific modules should be separated from generic (common)
modules thats why we have selectall.js (which will be renamed to Utility.js
and it include only common utility functionality) and currently page
specific code is in separate js files.
I am not talking about page specific or group of pages js code, I just
tried to say common code which is required on almost all the screens and
was the part of global decorator of page till now should be in one file, we
can further break it in smaller utility functions in future and build tools
can be used to merge it if needed.

And specific page or group of pages js can be in separate js files. And
caching can help here.

The organization's internal caching policies (local proxies or squid for
example) might be easier to optimize the static code if the js files being
cached are separate and identified.
-- Yes I agree, caching can be done. It is also included in performance
rules link that I given above.

Thanks
--
Amardeep Singh Jhajj


On Sat, Jul 2, 2016 at 9:30 PM, Ron Wheeler <[hidden email]>
wrote:

> On 02/07/2016 11:10 AM, Amardeep Singh Jhajj (JIRA) wrote:
>
>>      [
>> https://issues.apache.org/jira/browse/OFBIZ-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15360207#comment-15360207
>> ]
>>
>> Amardeep Singh Jhajj commented on OFBIZ-1319:
>> ---------------------------------------------
>>
>> I agree with you that having smaller files with their related topics. But
>> I would suggest to have one file for now for all utilities because
>> increasing number of js files in page will increase the HTTP request.
>> Please read - Minimize HTTP Requests
>>
> Separating modules that are always required from modules that are only
> required for specific pages or groups of pages will increase the number of
> http requests but make them smaller. Depending on caching, the extra http
> requests might not be an issue. The organization's internal caching
> policies (local proxies or squid for example) might be easier to optimize
> the static code if the js files being cached are separate and identified.
>
>> https://developer.yahoo.com/performance/rules.html
>>
>> Here, one thing can be done in future that we may add some mechanism for
>> concatenation of js files (using binng uild tools) into one file, which
>> normally done for js files which includes in all pages. This one file
>> further minimized during build. So concatenation, minification can be a
>> part of build process. I am not currently planned or thought about the
>> build process for it.
>>
>
> Separating delivery packaging from coding packaging is almost always a
> good idea.
>
>
>
>> In that case we can break current selectall.js into smaller files. So its
>> just my thought, i am open to suggestions from you :)
>>
>> Currently, I am focusing on following things-
>>
>> 1. Simplify and improve currently written utilities so that it can be
>> used from any where using class, id or data attributes. It will help us to
>> remove inline js in ftls.
>> 2. Removing unused code from selectall.js
>>
>>
>> Split javascript files to have more generic ones includable in all
>>> screens, and the more specific ones included more locally
>>>
>>> ----------------------------------------------------------------------------------------------------------------------------
>>>
>>>                  Key: OFBIZ-1319
>>>                  URL: https://issues.apache.org/jira/browse/OFBIZ-1319
>>>              Project: OFBiz
>>>           Issue Type: Improvement
>>>           Components: framework
>>>     Affects Versions: Trunk
>>>             Reporter: Jacques Le Roux
>>>             Assignee: Jacques Le Roux
>>>             Priority: Minor
>>>
>>>  From a David's E. Jones comment on ML :
>>> We should split up javascript files to have the more generic ones
>>> includable in all screens, and the more specific ones (like the toggle* and
>>> selectAll* methods in there) into a file that can be included more locally.
>>>
>>
>>
>> --
>> This message was sent by Atlassian JIRA
>> (v6.3.4#6332)
>>
>>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: [hidden email]
> skype: ronaldmwheeler
> phone: [phone], ext 102
>
>