Lack of interest Move most of jQuery.extend to external file

This suggestion has been closed automatically because it did not receive enough votes over an extended period of time. If you wish to see this, please search for an open suggestion and, if you don't find any, post a new one.

Marcus

Well-known member
Most of that javascript, with the exception of some very minor data might be put into an external file:
PHP:
<script>
jQuery.extend(true, XenForo,
{
visitor: { user_id: 166 },
serverTimeInfo:
{
now: 1382694736,
today: 1382652000,
todayDow: 5
},
_lightBoxUniversal: "1",
_enableOverlays: "1",
_animationSpeedMultiplier: "1",
_overlayConfig:
{
top: "10%",
speed: 200,
closeSpeed: 100,
mask:
{
color: "rgb(255, 255, 255)",
opacity: "0.6",
loadSpeed: 200,
closeSpeed: 100
}
},
_ignoredUsers: {"1":"a","2":"b"},
_loadedScripts: {"node_list":true,"node_category":true,"node_forum":true,"node_link":true,"node_page":true,"sidebar_share_page":true,"xfcom_page_wrapper":true},
_cookieConfig: { path: "/", domain: "", prefix: "xf_"},
_csrfToken: "166,234,123",
_csrfRefreshUrl: "login/csrf-token-refresh",
_jsVersion: "4fb209a0"
});
jQuery.extend(XenForo.phrases,
{
cancel: "Cancel",
a_moment_ago: "A moment ago",
one_minute_ago: "1 minute ago",
x_minutes_ago: "%minutes% minutes ago",
today_at_x: "Today at %time%",
yesterday_at_x: "Yesterday at %time%",
day_x_at_time_y: "%day% at %time%",
day0: "Sunday",
day1: "Monday",
day2: "Tuesday",
day3: "Wednesday",
day4: "Thursday",
day5: "Friday",
day6: "Saturday",
_months: "January,February,March,April,May,June,July,August,September,October,November,December",
_daysShort: "Sun,Mon,Tue,Wed,Thu,Fri,Sat",
following_error_occurred: "The following error occurred",
server_did_not_respond_in_time_try_again: "The server did not respond in time. Please try again.",
logging_in: "Logging in",
click_image_show_full_size_version: "Click this image to show the full-size version.",
show_hidden_content_by_x: "Show hidden content by {names}"
});
// Facebook Javascript SDK
XenForo.Facebook.appId = "146201428725181";
XenForo.Facebook.forceInit = true;
</script>
 
Upvote 0
This suggestion has been closed. Votes are no longer accepted.
You can't move anything of this into a static file;)

this variables are
  • phrases
  • xenforo options
  • other dynamic variables (like visitor data)
The phrases "could" be moved to an automatic generated JS file, but not sure if it's worth because of all the possible troubles like the write permissions for the files

and the files would also probably be REALLY big, which could cause performance problems when you load them the first time. (and you would need to rebuild them after each phrase CRUD operation like addon installation, addon deinstallation, phrase edit via acp)
 
Last edited:
Maybe one could put this in an external file setting-{$latest-setting-id}:

_lightBoxUniversal: "1",_enableOverlays: "1",_animationSpeedMultiplier: "1",_overlayConfig:
{top: "10%",speed: 200,closeSpeed: 100,mask:
{color: "rgb(255, 255, 255)",opacity: "0.6",loadSpeed: 200,closeSpeed: 100}

_lightBoxUniversal: "1",_enableOverlays: "1",_animationSpeedMultiplier: "1",_overlayConfig:
{top: "10%",speed: 200,closeSpeed: 100,mask:
{color: "rgb(255, 255, 255)",opacity: "0.6",loadSpeed: 200,closeSpeed: 100}

And this in a file phrase-[$language-id}.js per language :

jQuery.extend(XenForo.phrases,
{cancel: "Cancel",a_moment_ago: "A moment ago",one_minute_ago: "1 minute ago",x_minutes_ago: "%minutes% minutes ago",today_at_x: "Today at %time%",yesterday_at_x: "Yesterday at %time%",day_x_at_time_y: "%day% at %time%",day0: "Sunday",day1: "Monday",day2: "Tuesday",day3: "Wednesday",day4: "Thursday",day5: "Friday",day6: "Saturday",_months: "January,February,March,April,May,June,July,August,September,October,November,December",_daysShort: "Sun,Mon,Tue,Wed,Thu,Fri,Sat",following_error_occurred: "The following error occurred",server_did_not_respond_in_time_try_again: "The server did not respond in time. Please try again.",logging_in: "Logging in",click_image_show_full_size_version: "Click this image to show the full-size version.",show_hidden_content_by_x: "Show hidden content by {names}"});
 
Then, all of a sudden, you've created a whole load of additional work for developers, an inability for add-on developers to extend XenForo.phrases easily (as we need to sometimes), a whole load of additional complexity for translators all for something that, overall, is incredibly minute in performance benefit.
 
If I change the phrase monday to "lunes" within the language "spanish ID 5", the file phrase-5.js would be updated to the new content. From what I understand addon developers would not have to touch this.

If phrases gets added, they will also be added to phrase-[$language-id}.js within the xenforo acp phrase system.

I am very eager to learn more about xenforo and I am happy to be teached more about the functionality, from my understanding this idea would work.
 
Whether it works or not is somewhat irrelevant - the costs outweigh the benefits. You're sacrificing simplicity and flexibility for externalising more of the JS. In this instance, you're simply complicating an issue that shouldn't require a lot of IO activity just for the sake of rendering a page without inline JS.

I'd like to throw the question back to you in case I'm making undue assumptions: why would we want to do this? What benefits would you feel this brings to the XenForo software?
 
Thanks for giving more information on how the xenforo system works, I learn a lot from it!

You can't move anything of this into a static file;)

this variables are
  • phrases
  • xenforo options
  • other dynamic variables (like visitor data)
The phrases "could" be moved to an automatic generated JS file, but not sure if it's worth because of all the possible troubles like the write permissions for the files

and the files would also probably be REALLY big, which could cause performance problems when you load them the first time. (and you would need to rebuild them after each phrase edit=> addon installation, addon deinstallation, phrase edit via acp)
Then, all of a sudden, you've created a whole load of additional work for developers, an inability for add-on developers to extend XenForo.phrases easily (as we need to sometimes), a whole load of additional complexity for translators all for something that, overall, is incredibly minute in performance benefit.
Whether it works or not is somewhat irrelevant - the costs outweigh the benefits. You're sacrificing simplicity and flexibility for externalising more of the JS. In this instance, you're simply complicating an issue that shouldn't require a lot of IO activity just for the sake of rendering a page without inline JS.

I'd like to throw the question back to you in case I'm making undue assumptions: why would we want to do this? What benefits would you feel this brings to the XenForo software?
 
Top Bottom