| Author |
 Topic  |
|
Deleted
deleted
4116 Posts |
 Posted - 11 March 2002 : 10:47:35
|
No problem. If we don't talk about these we cannot learn. I hope also you don't take me wrong on continuing this  .
You're right on saying "... people may think that this is necesary in everything they do...". No, they don't need this. I had a lot of A97 databases running in local environments using also lowercase and Turkish characters without a problem. Whenever I start to change things (change a host, change OS, upgrade to A2K etc) I've got problems.
What I was trying to say is: If you want to make your database locale independent, ENGLISH-ASCII character set will do this. The first two statements in chapter 4.2 is related to each other. We might also say "Use exactly the same case in SQL statements as the case in the table/field names". But this would not ease programming. It is best to assume a standart (just to continue the standart used in SF2K) and use uppercase in all table names and fields. Am I wrong?
Think PinkPost v40b03 Patches< |
 |
|
|
fatum
Junior Member
Belgium
281 Posts |
Posted - 11 March 2002 : 14:50:04
|
I have to agree with Bodzen that using all UPPER CASE or all lower case would simplify everything.
With such standards, the code will become more easily readable for other people (I'm talking about mods here).
It's true that UPPER CASE isn't really necessary, but a lot of "rules" that exist aren't really necessary, that just make life easier (I hope)
Dutch support forum | version4 beta3 Dutch testsite< |
|
|
|
Nathan
Help Moderator
USA
7664 Posts |
Posted - 11 March 2002 : 18:25:14
|
Like tabing/spacing and variable nomenclature.
Would almost be nice if we had a 'coding standards' system like I've seen other open souce projects have.
Nathan Bales - Romans 15:13
----------------------------------
Snitz Exchange | Do's and Dont's< |
|
|
|
Deleted
deleted
4116 Posts |
Posted - 11 March 2002 : 18:39:24
|
quote:
Like tabing/spacing and variable nomenclature.
Would almost be nice if we had a 'coding standards' system like I've seen other open souce projects have.
Nathan Bales - Romans 15:13
----------------------------------
Snitz Exchange | Do's and Dont's
There is a non-written standart in base forum files. I remember talks about when to use TAB (x chars) and when space. You can also recognize easily the variable naming standart.
A coding standart for MODs will be out of the scope of *this* (sf2k) open source project, I think. It will be too restrictive.
But I would agree if you mean this:
* If someone writes the standarts for the base forum code, it will/may be a good starting point for MOD writers.
* If we put some standarts on filenaming, not to restrict people, but just because they can/will interfare with future forum development.
I think I'm not the correct person to do these (if they get ever be done).
Think PinkPost v40b03 Patches< |
|
|
|
Nathan
Help Moderator
USA
7664 Posts |
Posted - 11 March 2002 : 19:45:53
|
quote:
But I would agree if you mean this:
* If someone writes the standarts for the base forum code, it will/may be a good starting point for MOD writers.
* If we put some standarts on filenaming, not to restrict people, but just because they can/will interfare with future forum development.
Bingo, exactly what I meant
Browsing around the base code you can tell what came in as mods (subscriptions_list.asp is the perfect example) because the code doesn't look like the other pages.
Nathan Bales - Romans 15:13
----------------------------------
Snitz Exchange | Do's and Dont's< |
|
|
|
fatum
Junior Member
Belgium
281 Posts |
Posted - 11 March 2002 : 20:05:49
|
Indeed, it should be a starting point, a reference.
If you try to inforce the "rules", people will stop developping mods, or admins would spend to much time checking the code for errors.
But as you say, we should try to teach people to respect some guidelines, so that future developments aren't compromised.
I think most mod writers are open to suggestions concerning code writing.
Dutch support forum | version4 beta3 Dutch testsite< |
|
|
|
Nathan
Help Moderator
USA
7664 Posts |
Posted - 11 March 2002 : 20:13:16
|
I think any coding standards would be more for the base code like Bozden said (to make it more readable and more managable)
Modderes could use it as reference (if they wanted)
Nathan Bales - Romans 15:13
----------------------------------
Snitz Exchange | Do's and Dont's< |
|
|
|
HuwR
Forum Admin
United Kingdom
20593 Posts |
Posted - 11 March 2002 : 20:22:42
|
As I said previously, I wasn't disagreeing, just pointing out WHY, so that people understand the reasons it is being done.
If people wish to write fully compatible MODS then they will have to follow these guidlines otherwise they will be getting support nightmares.
< |
|
|
|
tutzauer
Starting Member
Panama
28 Posts |
Posted - 12 March 2002 : 12:25:26
|
Hi all,
I have a couple of small issues with the MOD guidelines that I would like to put on the table for discussion.
FIRST:
quote:
Instead of using this
response.write "Gender: " & rs("GENDER")
use this:
response.write "Gender: " Switch Case rs("GENDER")
Case "1" response.write "Male"
Case "2" response.write "Female"
Case else response.write " " end switch
I would suggest:
Case "1" response.write strLangEventsEvents00010
Case "2" response.write strLangEventsEvents00020
where the first language variable, in English, would be "Male" and the second language variable, in English, would be "Female"...from the MODs language files.
SECOND:
I don't think that languages should be mixed (multiple) in one MOD language file. I believe that each language should have its own file as in the base forum. This would eliminate all the [NNNN] codeing. The International Snitz Forum program would just load the appropriate MOD language file where needed...no special coding required.
Also only the necessary (used) language files need to be on the system.
Also each individual language file could be updated by that language's workgroup (subject matter experts) without them having to be bothered with the other language data in which they have no interest.
I tried this method with the Events Calendar and the implimentation was easy. I just setup the languages in the basic Snitz Forum files and bingo, when I selected the language in the Snitz Forum the proper language text was displayed in the Events Calendar without any other coding changes except puting in the language variables because in the version of the Events Calendar that I had the text was hard coded. Of course, I had to create a MOD language file for each language.
Jack Tutzauer< |
|
|
|
Deleted
deleted
4116 Posts |
Posted - 12 March 2002 : 12:39:31
|
quote:
As I said previously, I wasn't disagreeing, just pointing out WHY, so that people understand the reasons it is being done.
If people wish to write fully compatible MODS then they will have to follow these guidlines otherwise they will be getting support nightmares.
Added a notice about this in section 4.2. Huw, thank you for your input .
Think PinkPost v40b03 Patches< |
|
|
|
Deleted
deleted
4116 Posts |
Posted - 12 March 2002 : 12:42:45
|
quote:
FIRST:
quote:
Instead of using this
response.write "Gender: " & rs("GENDER")
use this:
response.write "Gender: " Switch Case rs("GENDER")
Case "1" response.write "Male"
Case "2" response.write "Female"
Case else response.write " " end switch
I would suggest:
Case "1" response.write strLangEventsEvents00010
Case "2" response.write strLangEventsEvents00020
where the first language variable, in English, would be "Male" and the second language variable, in English, would be "Female"...from the MODs language files.
Yes you are right. But you probably missed the following phrase just above the code:
quote:
Taking this into account, the code that accesses the database will change also a bit. Note: The following code is just for demonstration purposes. Don't forget, the other textual info will actually be language variables.
Let me see how I can re-phrase it.
Think PinkPost v40b03 Patches< |
|
|
|
Deleted
deleted
4116 Posts |
Posted - 12 March 2002 : 12:51:35
|
quote:
SECOND:
I don't think that languages should be mixed (multiple) in one MOD language file. I believe that each language should have its own file as in the base forum. This would eliminate all the [NNNN] codeing. The International Snitz Forum program would just load the appropriate MOD language file where needed...no special coding required.
Also only the necessary (used) language files need to be on the system.
Also each individual language file could be updated by that language's workgroup (subject matter experts) without them having to be bothered with the other language data in which they have no interest.
I tried this method with the Events Calendar and the implimentation was easy. I just setup the languages in the basic Snitz Forum files and bingo, when I selected the language in the Snitz Forum the proper language text was displayed in the Events Calendar without any other coding changes except puting in the language variables because in the version of the Events Calendar that I had the text was hard coded. Of course, I had to create a MOD language file for each language.
Yes you are right with something like the events MOD. This is what I recall as "Large Scale MOD" in the document.
But some MODs are really small changes to the package, which usually change the existing forum code (such as adding some new fields for members, new icons for smilies etc). It will be not meaningful to make a "package" from them for a couple of lines. This is why LangMODS.asp is provided. This file will be loaded with each page, so that the contents is ready to use. The others will only included by related files which use that mode.
I'm also not very satisfied in providing two different ways for development, and stressed this fact by saying:
quote:
I would like to have a more general rule valid for every mode, but performance matters.
in chapter 4.1 under topic "SIZE".
If you read the document once more, you will understand what I mean. Any input on this problem may remedy this issue.
Think PinkPost v40b03 Patches< |
|
|
|
tutzauer
Starting Member
Panama
28 Posts |
Posted - 15 March 2002 : 01:40:22
|
I see what you mean. I guess that what bothers me is those 'small' MODs. In fact anything that changes the original application program code scares me.
For example: a program like Events Calendar which is a 'stand-alone' package does not change the original program. Eventhough it makes changes to the db those changes do not effect the original program. In fact I think the Events Calendar should not be a modification. The db tables should be in the release version and the Events programs included in the package. If the administrator wants to use it he just does the setup and includes the link. If not, he does nothing.
Any MOD which makes internal changes, small or otherwise, to the released version I think is a potential support problem.
Adding some new fields for members I would consider a support problem if new lines of code were entered into the released version. If the input form for members were a seperate file which could be swapped for a new input form file (or something similar), then I would not feel it was not as much of a support problem. A better solution would be to have the release version provide some 'extra' fileds to be assigned by the administrator, when needed. If they are assigned the release version would display their input/output as appropriate.
New icons for smilies etc should have a standard utility/file in the release version for their addition and should not be what I would call a modification.
Standards, standards, standards is the name of the game. Go to any lengths to avoid changes to the release version's internal code. If a modification is worthy, put it in the next release. If it is not worthy enough for inclusion into the next release then leave it to the brave at heart to use at their own risk.
Jack Tutzauer< |
|
|
|
Nathan
Help Moderator
USA
7664 Posts |
Posted - 15 March 2002 : 01:52:46
|
quote:
I see what you mean. I guess that what bothers me is those 'small' MODs. In fact anything that changes the original application program code scares me.
Why? Because its changed by a 'person.' How do you think the forum was written anyway 
quote:
For example: a program like Events Calendar which is a 'stand-alone' package does not change the original program. Eventhough it makes changes to the db those changes do not effect the original program. In fact I think the Events Calendar should not be a modification. The db tables should be in the release version and the Events programs included in the package. If the administrator wants to use it he just does the setup and includes the link. If not, he does nothing.
And then the forum base code becomes large and unmanageable with all the non forum related modules that most people arn't going to use anyway.
quote:
Any MOD which makes internal changes, small or otherwise, to the released version I think is a potential support problem.
We seem to get by just fine. Many times the author of the mod will take care of the support for it and do a really good job.
quote:
Adding some new fields for members I would consider a support problem if new lines of code were entered into the released version. If the input form for members were a seperate file which could be swapped for a new input form file (or something similar), then I would not feel it was not as much of a support problem. A better solution would be to have the release version provide some 'extra' fileds to be assigned by the administrator, when needed. If they are assigned the release version would display their input/output as appropriate.
Why, when the admin could just as easily create his own fields. They are going to be just as hard to support because they will be equally blind to the support staff as admin defined fields.
quote:
New icons for smilies etc should have a standard utility/file in the release version for their addition and should not be what I would call a modification.
There is currently a module for adding your own smilies. If someday it is deamed 'worthy' it might make it into the forum base code.
quote:
Standards, standards, standards is the name of the game. Go to any lengths to avoid changes to the release version's internal code. If a modification is worthy, put it in the next release. If it is not worthy enough for inclusion into the next release then leave it to the brave at heart to use at their own risk.
How else do you think Snitz has come to be what it is? Many cool features are mods that have been implemented, like private forums, subscriptions, and archives.
Quite frankly, I would get quite boared helping people if they didn't change the code. I think forums that have been customized and wolven into a site's main interface are so much more pleasing than a plain jain out of the box jobby.
Just my $0.02
Nathan Bales - Romans 15:13
----------------------------------
Snitz Exchange | Do's and Dont's< |
|
|
|
Deleted
deleted
4116 Posts |
Posted - 15 March 2002 : 17:05:03
|
Calm down boys. Theoratically what Jack said is correct in many aspects, and I'm sure that he has no intension to accuse anybody for something.
I won't go into details in this discussion because it will go nowhere. Current status is a "fact" for me as an engineer, I have to cope with this practical situation.
Jack, on the other hand, the main idea of Snitz Forums is not to provide a very well working plug and play superb forum. The main idea is, to make people learn ASP, Databases and similar. The forum is just a side effect (a good side effect).
Towards this goal, MODs have great value.
I, on the other hand... I do not like any non-standartization in v4. This is because I'm (nearly) alone. I cannot support all of the issues if people start to make non-standart things.
My $2000...
Think PinkPost v40b03 Patches< |
|
|
|
Topic |
|
Forum Locked
