We hope you enjoy your visit.

You're currently viewing our forum as a guest. This means you are limited to certain areas of the board and there are some features you can't use. If you join our community, you'll be able to access member-only sections, and use many member-only features such as customizing your profile, sending personal messages, and voting in polls. Registration is simple, fast, and completely free.


Join our community!


If you're already a member please log in to your account to access all of our features:

Username:   Password:
Add Reply
  • Pages:
  • 1
-
Topic Started: May 12 2015, 12:35 PM (1,193 Views)
l1r72
Member Avatar
Member
[ *  *  * ]
-
Edited by l1r72, Jun 8 2018, 04:34 AM.
Offline Profile Quote Post Goto Top
 
Viral
Member Avatar
Viral
[ *  *  *  *  *  * ]
Modifying the DOM of a page will break many existing codes. I assume that's also why many of the variables are left in - for backwards compatability.

I'm pretty sure 99% of all codes would blow up if you removed `main_url`.
Edited by Viral, May 12 2015, 12:53 PM.
Offline Profile Quote Post Goto Top
 
l1r72
Member Avatar
Member
[ *  *  * ]
-
Edited by l1r72, Jun 8 2018, 04:34 AM.
Offline Profile Quote Post Goto Top
 
Viral
Member Avatar
Viral
[ *  *  *  *  *  * ]
Except, it is. It's not just your modifications, there are hundreds of modifications that would break. `main_url` is used in practically any code more than 1 line long. Adding/ removing things may not break as many codes, but it could break some (a recent addition of the multi login link broke many codes for example). Changing some more trivial things like removing [ or ] would again not break as many codes, but it could break some. Codes use different things on the page for manipulation. With the number of codes around now, nearly everything on the page is valuable and shouldn't be changed. A `<br>` tag may not be much of a deal, but it could break codes which look for `<br>` for manipulation. In addition, you're forgetting that this would also cause problems with current themes that have been designed around it.
Offline Profile Quote Post Goto Top
 
Arrogant
Member Avatar
Member
[ *  *  *  * ]
Viral
May 12 2015, 12:59 PM
Except, it is. It's not just your modifications, there are hundreds of modifications that would break. `main_url` is used in practically any code more than 1 line long. Adding/ removing things may not break as many codes, but it could break some (a recent addition of the multi login link broke many codes for example). Changing some more trivial things like removing [ or ] would again not break as many codes, but it could break some. Codes use different things on the page for manipulation. With the number of codes around now, nearly everything on the page is valuable and shouldn't be changed. A `<br>` tag may not be much of a deal, but it could break codes which look for `<br>` for manipulation. In addition, you're forgetting that this would also cause problems with current themes that have been designed around it.
So, what? Is ZetaBoards supposed to never move forward because removing, changing, or adding something could break any number of scripts that were written years ago?

Improvements should be prioritized over backwards compatibility. If scripts are broken, board owners that use them will come here eventually. Brandon could even add a notice to the ACP informing board owners that some scripts may have been broken in a recent improvement, and that they can visit the support board for a solution.
Offline Profile Quote Post Goto Top
 
Ferby
Member Avatar
Developer
[ *  *  *  *  * ]
Arrogant
May 12 2015, 02:03 PM
Viral
May 12 2015, 12:59 PM
Except, it is. It's not just your modifications, there are hundreds of modifications that would break. `main_url` is used in practically any code more than 1 line long. Adding/ removing things may not break as many codes, but it could break some (a recent addition of the multi login link broke many codes for example). Changing some more trivial things like removing [ or ] would again not break as many codes, but it could break some. Codes use different things on the page for manipulation. With the number of codes around now, nearly everything on the page is valuable and shouldn't be changed. A `<br>` tag may not be much of a deal, but it could break codes which look for `<br>` for manipulation. In addition, you're forgetting that this would also cause problems with current themes that have been designed around it.
So, what? Is ZetaBoards supposed to never move forward because removing, changing, or adding something could break any number of scripts that were written years ago?

Improvements should be prioritized over backwards compatibility. If scripts are broken, board owners that use them will come here eventually. Brandon could even add a notice to the ACP informing board owners that some scripts may have been broken in a recent improvement, and that they can visit the support board for a solution.
Whilst I agree, removing a simple variable is not the way to go about this. Many great codes are old and many of those developers aren't around anymore to fix their codes. I know the Like/Dislike code would break and the developer hasn't been around to update it any further, which has inspired Viral to add it to the to-do list of ZB Dynamo. By all means move forward with development but removing a variable which brings more good than harm is not the way to go about it.
Offline Profile Quote Post Goto Top
 
l1r72
Member Avatar
Member
[ *  *  * ]
-
Edited by l1r72, Jun 8 2018, 04:35 AM.
Offline Profile Quote Post Goto Top
 
Arrogant
Member Avatar
Member
[ *  *  *  * ]
Ferby
May 12 2015, 02:12 PM
Whilst I agree, removing a simple variable is not the way to go about this. Many great codes are old and many of those developers aren't around anymore to fix their codes. I know the Like/Dislike code would break and the developer hasn't been around to update it any further, which has inspired Viral to add it to the to-do list of ZB Dynamo. By all means move forward with development but removing a variable which brings more good than harm is not the way to go about it.
Changing the HTML structure of the board would break scripts as well. The question is if changing those things is worth breaking scripts over. (We both seem to agree that it is, just not in all instances.)

The variables included on every page are a mess. main_url is an outlier and the others don't seem to follow a logical pattern. I think those variables should be redone and the older variables put into a legacy script that's phased out after the plugin database is added and becomes popular enough to rely on -- those plugins can be changed rather easily once they're in the database by Brandon, or so I'd hope, so he could change every instance of main_url to the newer variable.

Why put the older variables into a legacy script instead of leaving them where they are? So newer script authors won't use them over the new variables. If main_url is no longer in the page source, but loaded through an external script, people will stop using it because they won't know it even exists. Go the extra mile by adding a "help" page or something to the ACP that lists all the variables that are available for use and purposefully leave the old ones out.
Edited by Arrogant, May 12 2015, 02:28 PM.
Offline Profile Quote Post Goto Top
 
Viral
Member Avatar
Viral
[ *  *  *  *  *  * ]
Arrogant
May 12 2015, 02:03 PM
Viral
May 12 2015, 12:59 PM
Except, it is. It's not just your modifications, there are hundreds of modifications that would break. `main_url` is used in practically any code more than 1 line long. Adding/ removing things may not break as many codes, but it could break some (a recent addition of the multi login link broke many codes for example). Changing some more trivial things like removing [ or ] would again not break as many codes, but it could break some. Codes use different things on the page for manipulation. With the number of codes around now, nearly everything on the page is valuable and shouldn't be changed. A `<br>` tag may not be much of a deal, but it could break codes which look for `<br>` for manipulation. In addition, you're forgetting that this would also cause problems with current themes that have been designed around it.
So, what? Is ZetaBoards supposed to never move forward because removing, changing, or adding something could break any number of scripts that were written years ago?

Improvements should be prioritized over backwards compatibility. If scripts are broken, board owners that use them will come here eventually. Brandon could even add a notice to the ACP informing board owners that some scripts may have been broken in a recent improvement, and that they can visit the support board for a solution.
Arrogant, you know very well I'm with you on the development > backwards compatability forefront. But what good does removing `main_url` etc do? It doesn't develop anything, it only breaks existing codes. It would be pointless and a stupid move in anyone's books. I'm with you that ZetaBoards needs to look forward, but you've got to be reasonable. Why force 90% of the codes to be fixed, tested + the countless number of support topics etc because you wanted rid of 8 characters from each page?

EDIT: Looking at the other suggestions:

remove twitter code when twitter is turned off - I agree
remove links to changing a signature in the dropmenu and in the user cp - disagree. Why? If you don't want it, use JS. It serves a purpose.
remove the <br> before #forum_nav (jump menu) - disagree. Themes are designed around it, and it doesn't restrict development.
remove any square brackets in the design [] such as around the sign up and register and sign out, as well as from the post preview close button - disagree. This is a design decision. Again, if you don't like it, use JS.
remove any other characters which could be omitted as they serve little purpose (such as the ";" in a topic title with a description) - Not too sure why that's there to be honest. But it does give the user a clearer way of differentiating between the title and description in some themes. But I agree, it seems a lazy brute force method of differentiation.
remove $.zb.admin=0;$.zb.moderator=0; which are already part of $.zb.stat - disagree for backwards compatability problems. Again, leaving it there doesn't impede development, removing it does.
consistently name table cells and rows across the forum rather than having many names - definitely disagree. Yes it should have been named better at the start, but table classes (if that's what you're referring to) are used everywhere; themes, codes etc.
add class matching the page type to the body (index, portal, calendar, category view, thread list, thread view, post view, etc.) - I like this.
add js variables (there are some but could also add: page type, forum id, post id, user id, etc.) - forum id and post id can be found easily, no point. user id is in the $.zb.stat variable.
add class to ad tables (this allows me as a designer to more easily give them a different background so I can blend them in to the wrap as opposed to making the look like any other table) - I don't see this happening as it makes it too easy to hide.
add js variables to admin CP as well (same as on normal forum but including: forum url) - No one develops for the ACP as far as I'm aware?
add classes to forms to differentiate them when there are multiple forms per page - I like this.
Edited by Viral, May 12 2015, 03:48 PM.
Offline Profile Quote Post Goto Top
 
l1r72
Member Avatar
Member
[ *  *  * ]
-
Edited by l1r72, Jun 8 2018, 04:35 AM.
Offline Profile Quote Post Goto Top
 
Viral
Member Avatar
Viral
[ *  *  *  *  *  * ]
I agree with the ACP thing, I'd find it handy. Just saying I wouldn't expect anything as practically no one develops in the ACP (and it doesn't exactly serve the general user base :P ).
Offline Profile Quote Post Goto Top
 
Arrogant
Member Avatar
Member
[ *  *  *  * ]
Viral
May 12 2015, 03:39 PM
Arrogant, you know very well I'm with you on the development > backwards compatability forefront. But what good does removing `main_url` etc do? It doesn't develop anything, it only breaks existing codes. It would be pointless and a stupid move in anyone's books. I'm with you that ZetaBoards needs to look forward, but you've got to be reasonable. Why force 90% of the codes to be fixed, tested + the countless number of support topics etc because you wanted rid of 8 characters from each page?
Alright, alright. There is no need for removing it entirely, but it should at least be deprecated and hidden.

As far as variables go, we have:
  • main_url
  • $.zb.stat.admin
  • $.zb.stat.mod
  • $.zb.stat.mid
  • $.zb.stat.gid
  • $.zb.stat.bpath
  • $.zb.stat.server
  • $.zb.stat.url
  • $.zb.admin
  • $.zb.moderator
  • $.zb.logged_in
All items in bold are listed twice and all but four variables are part of the same object ($.zb.stat). They should be reorganized, with some being deprecated and hidden in an external JS file to (hopefully) discourage further use.

main_url is faster than $.zb.stat.url, but it also pollutes the global namespace and doesn't follow the same pattern as the rest (being part of the $.zb object).
$.zb.admin, $.zb.moderator, and $.zb.logged_in all make logical sense, but the first two are copies of $.zb.stat.admin and $.zb.stat.mod. Why?

Instead of referencing the same values with multiple variables, why not add new variables? Group name, user ID, username, user avatar, page type (thread, index, search, calendar), thread ID, etc.. There's so much more useful information that could be included on every page. It should also follow a logical pattern for ease of use, with each value being represented by only one variable.

Another thing we could use is documentation on existing API, mainly the contents of http://z5.ifrm.com/static/zb_api.js. So many times have I come across scripts that implement their own functions for writing to and reading from document.cookie -- why? Because most script authors probably have no idea that there are existing functions already being loaded for doing exactly that on every ZetaBoards forum. Not only do they handle cookies, but they also handle localStorage and sessionStorage if they're supported.
Edited by Arrogant, May 12 2015, 10:49 PM.
Offline Profile Quote Post Goto Top
 
Quozzo
Member Avatar
By the blood of Sanguinius!
[ *  *  *  *  * ]
I think removing or editing anything would be a bad idea as it would break many codes and even themes. Adding extra functionality is always a good idea, but the additional resources required would need to be considered, although they do seem like relatively minor additions.

Just FYI, my ZB Library mod adds a lot of those features to grab what page the user is on. It doesn't add them into the html element as a class though, that's something that is up to the developer to do, either by a script in a theme or a mod to call a function when only in a page for example.
Edited by Quozzo, May 13 2015, 01:05 AM.
Offline Profile Quote Post Goto Top
 
Cody
Member Avatar
Member
[ *  *  *  *  *  * ]
I think many of these suggestions are a little too precise to be edited at this point in ZetaBoards' life, but I agree 100% with a few of them, and a few others don't concern me since I don't use Javascript. Here are the ones I definitely agree with :
  • add class matching the page type to the body (index, portal, calendar, category view, thread list, thread view, post view, etc.)
  • add class to ad tables (this allows me as a designer to more easily give them a different background so I can blend them in to the wrap as opposed to making the look like any other table)
  • remove twitter code when twitter is turned off
  • consistently name table cells and rows across the forum rather than having many names
Offline Profile Quote Post Goto Top
 
ElementalAlchemist
Member Avatar


Regarding a lot of things:
The JS API hasn't existed for all that long. `main_url` predates it by a really long time (it actually dates back at least to when ZB was first released). This is why things like `main_url` and older codes that may do their own cookie handling are still around. (Newer codes that need cookies absolutely should use the built-in cookie API.)
Online Profile Quote Post Goto Top
 
1 user reading this topic (1 Guest and 0 Anonymous)
Go to Next Page
« Previous Topic · Service Discussion and Feedback · Next Topic »
Add Reply
  • Pages:
  • 1