| 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: |
| Plug-in System; Feature Request | |
|---|---|
| Topic Started: Jun 27 2009, 01:34 PM (666 Views) | |
| Nivexonix | Jun 27 2009, 01:34 PM Post #1 |
![]()
L o v e
![]() ![]() ![]() ![]() ![]() ![]()
|
Having recently gone through some codes, I began thinking about an easier way to approach coding so that coders don't have to worry as much about providing support for their codes. There are a few individuals who release many codes, so this could become very bothersome - for both the coder, who would have to take time to answer the questions, and to the individual who doesn't get his or her questions answered. While I am unfamiliar with coding - aside from HTML and CSS - I feel that a plug-in system would be able to solve the problems I have mentioned. I am fairly certain that this would be able to alleviate some of the issues coders face. It would also provide a wider range for coding possibilities in the future. I'm fairly certain that this could provide the room needed to create things that require more interaction with the database - though again, I cannot code so I can't really expand on this. |
![]() |
|
| ElementalAlchemist | Jun 27 2009, 01:43 PM Post #2 |
![]()
ERROR: This title does not exist.
![]() ![]() ![]() ![]() ![]() ![]() ![]()
|
While this could be a good idea, I can see it also being very destructive unless there's some sort of screening process, which depends on the staff's willingness and ability to do so. |
![]() |
|
| Tony | Jun 27 2009, 01:57 PM Post #3 |
|
Katorga-12
![]()
|
So who would support their codes? You can't surely expect others to do it? If someone creates something, they should offer support for it, regardless. I, and others, have mentioned a resource database a few times. In fact . . . . . .
|
![]() |
|
| Stephen | Jun 27 2009, 02:10 PM Post #4 |
|
Mine! Or I will help you not.
![]()
|
..in fact the worst kept secret on this network is the existance of a RDB.
|
![]() |
|
| Nivexonix | Jun 27 2009, 02:28 PM Post #5 |
![]()
L o v e
![]() ![]() ![]() ![]() ![]() ![]()
|
Theoretically, support wouldn't exist, or be needed. You would only need to upload the file, which isn't impossibly hard. ![]() The RDB is so long in waiting. I don't fully understand how that would operate, so I guess I will have to wait for more information. But, I think I see how these two systems wouldn't be needed simultaneously.
|
![]() |
|
| Tony | Jun 27 2009, 02:36 PM Post #6 |
|
Katorga-12
![]()
|
It would be the same thing no? ![]() Why would there be no support? Yes the system will hopefully have one-click-installs, but that won't prevent in-compatibility; or users having questions; or users not understanding something. Users will still need to speak to the creator in some way about something. ![]() With your idea of create, submit, forget; the RDB Team will not only have to screen everything, and make sure it works with other codes (and on its own); but answer questions about it, and chase people down to fix something; or up-date the code; or add something new people ask about. Maybe I'm not understanding you correctly?
|
![]() |
|
| SlothLikeSin | Jun 27 2009, 02:55 PM Post #7 |
|
D;
![]() ![]() ![]() ![]() ![]()
|
So.. what's a plug-in system? |
![]() |
|
| Nivexonix | Jun 27 2009, 05:45 PM Post #8 |
![]()
L o v e
![]() ![]() ![]() ![]() ![]() ![]()
|
Ah, ok. Now I see what you mean. I forgot about compatibility with other codes.
|
![]() |
|
| Lout | Jun 27 2009, 06:59 PM Post #9 |
|
Member
![]() ![]() ![]() ![]() ![]() ![]()
|
And there lies the major problem. So often we see codes conflicting with others, and as such questions will always be asked, which in turn will need to be answered. Nice idea though, and in a perfect world perhaps... |
![]() |
|
| Paper | Jun 28 2009, 06:48 AM Post #10 |
|
Member
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]()
|
A plug-in database is a very good idea, and would help to put Zetaboards in front of competitors such as Proboards. Currently Proboards have a kind of quality screening process, that ensure a certain standard of instruction, support and workability before it is added to the hack list. I would say though, that competition between different coders who make similar codes is important, as it drives up quality and features, so a plug in system should offer different coding solutions for the same thing, and allow users to choose and rate which one they wish to use. Proboards have stifled this in that similar codes to ones already in the hack list are rejected. Ultimately better codes sometimes end up being rejected. And I make no apology being critical on a Zetaboard forum! Compatibility is not really a huge issue. Naming variables correctly would avoid much incompatibility. Thorough testing, for example by installing all codes available in a plug-in database would determine if there are conflicts caused by the code. If such conflicts exist, each code in the database can be tested against a code until the two conflicting codes are found. The problem then can be corrected, or the codes can be marked as incompatible. Support is another easily solvable issue. If you have your code in the plug in database, you accept that you must provide periodic support for it. The plug in system could allow support tickets to be sent to the coder. |
![]() |
|
| Jory | Jun 28 2009, 11:32 AM Post #11 |
![]()
|
I have one major issue with any type of "centralised" plugin list: People will assume we (Zathyus staff) will be able to support them1. Sure, we can create a system that sends an email to the code creator. Maybe we can even create something central where somebody needs to register in order to submit a code, where they can then see and awnser tickets about their codes. But we won't be able to make sure they will. And then what? Then, we end up having to explain things, try to fix things ourselfs, etc. And just removing a code won't work either. Because then you have two options for boards that already use the code: Remove it and break things on that board, or leave it and be responsible for supporting the code. Don't get me wrong, I like this idea. (Or at least, I like the way I'm interpeting it.) It could make things much easier for our users. But from a support point of view, I for one do not want this. (Unless we can find a way to force code creators to provide support. But Brandon says our strike team is busy elsewhere. Bah. )1: Not that they don't assume things like that about custom codes not. But it would be far worse. Oh, I do know how to solve the compatebillity issue: Upon registration, you get a username. Each code also has a "codename". Both these names are valid Javascript class/variable names. Then if I where to want to make a code called "Banner Rotator", it would be something like this: That way, if somebody else wants to make a banner rotator, it would be in otherpersonsusername.BannerRotator.execute(). (FYI, execute() gets automatically called by our hypothetical system. )Do note I'm not sure this exact syntax is valid in Javascript. But I'm sure there is something close enough. |
![]() |
|
| Reid. | Jun 28 2009, 01:50 PM Post #12 |
|
C'est un piège!
![]() ![]() ![]() ![]() ![]()
|
That would be very hard to implement. This is the valid syntax: Or, you could always do things the long way. While you could, in theory, create something like this, it would have be interestingly done. For example, let's say you want to install Jory's banner rotator code. You'd go to his (your?) page and you'd see something like so: Now this is keeping your Name.Code.execute syntax intact, we could also just make the code name the function itself: That is a possibility as well, which makes the name itself also the function (i.e. to run the banner rotator, we would do Jory.BannerRotator()) Now this would install all of the user's codes and from there you could activate the ones you needed, which would solve the problem, I suppose. The only problem is making this fall linearly (I guess?) like this. If you search for a code, it would have to direct you to that user's page where you would get all of the user's codes and then activate the one code you need. JavaScript is an interesting language and even this syntax usage would not prevent all code conflicts. There are some systems that just aren't compatible for a multitude of reasons. For example, the thunder arcade and the AIO. Try debugging why those two won't work together; good luck. I don't think the two share any variables either, as I believe all of the AIO's variables, for the most part, begin with aio_ . There are some issues that are inherently difficult to fix. The plug-in database is a good idea, though, if you could manage to get everything to work in unison. That, I am afraid, would be quite the challenge. |
![]() |
|
| Paper | Jun 28 2009, 04:03 PM Post #13 |
|
Member
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]()
|
I'm afraid Jory that these aren't really significant problems. Codes should only really be accepted when they have been very well tested, screened and determined that no bugs remain. This would reduce the overall need to make bug reports on codes. It would be necessary to make clear that the codes are not produced by Zetaboards and that individual coders make them, therefore to contact these coders. A plug in system should facilitate in making it obvious. Anyone requesting support in the wrong place need simply only have their request closed. This slight nuisance really doesn't weigh against the advantage Zetaboards would gain over its competitors. Your latter point about either supporting or breaking a board are both extreme ends of the scale. After all, the codes in a plug in system do not belong to Zetaboards, and as such it should be up to a board owner as to whether they continue with a broken code or remove it from their board. No help should be given by Zeta Board staff, other than a recommendation to remove broken codes. Of course codes found to be broken should not be available to reinstall, the idea being that only quality should be permitted. A plug in system is merely something of a convenience, not a system offering codes produced by Zeta Boards. |
![]() |
|
| SlothLikeSin | Jun 28 2009, 07:49 PM Post #14 |
|
D;
![]() ![]() ![]() ![]() ![]()
|
I'm afraid that wouldn't solve most of the compatibility issues between certain plug-ins (unless I'm misunderstanding). If the community were to get involved with the plug-in database, things would be a lot easier. Well, not directly involved, but by feedback or bug and incompatibility reports, they'd help maintain it as much as the team behind it. Honestly though, if something like this were implemented, I'd like to see a standard or strict set of guidelines for how each plug-in is created. People have different styles when it comes to scripting, and a lot of them are extremely sloppy or overly complex. If a plug-in creator decided to neglect a plug-in, at least someone else would be able to support it without having to recreate it completely. |
![]() |
|
| HolySavior | Jun 28 2009, 09:45 PM Post #15 |
|
if( holy + alcohol){ happycoding()}
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]()
|
i would just like to see people who can actually code/script properly... dont get ahead of ourselves now people. i think more time should be spent enhancing the skills of the coders so they can produce working , non-buggy codes. that in itself will ease up on code support and problems. |
![]() |
|
| 1 user reading this topic (1 Guest and 0 Anonymous) | |
| Go to Next Page | |
| « Previous Topic · ZetaBoards Discussion · Next Topic » |






![]](http://209.85.62.24/static/1/pip_r.png)







I don't fully understand how that would operate, so I guess I will have to wait for more information. But, I think I see how these two systems wouldn't be needed simultaneously.

)
2:37 PM Nov 22