| Author |
 Topic  |
|
Deleted
deleted
4116 Posts |
 Posted - 06 March 2002 : 14:51:16
|
Jack, I know this method, but this is CLIENT SIDE javascript. First, ASP code is executed by the server and sent to the client browser. Here JS code is executed afterwards. This way or the other, keeping language variables in JS means, that the ASP code generates necessary JS code.
Think PinkPost v40b03 Patches< |
 |
|
|
tutzauer
Starting Member
Panama
28 Posts |
Posted - 06 March 2002 : 18:03:52
|
quote:
Jack, I know this method, but this is CLIENT SIDE javascript. First, ASP code is executed by the server and sent to the client browser. Here JS code is executed afterwards. This way or the other, keeping language variables in JS means, that the ASP code generates necessary JS code.
I guess that there is no such thing as a free lunch.
First, CLIENT SIDE processing, I think, is a good thing. It should decrease bandwidth problems and decrease load on the server. That would indicate a JavaScript mix because VBScript is an IE thing. JavaScript is not foolproof either. The same browser versions may have different versions of the scripting runtime.
The question, it seems to me, (and I'm sure you have put more time into thinking about this than I have) is how to get the processing such as string substitution off the server and on to the client.
I feel that there should be a way (outside of XML) to do it. For example, when you use events to validate form entries you are doing something similar to string substitutions on the client. You can replace anything in IE. In Netscape it is almost impossible to change a page once it is drawn. In IE you can change any text included between identifyable tags, such as <span id=mySpan>text</span>, on the fly. In Netscape the only way I know to change text is to put the entire page in a JavaScript string, using literal text combined with variables (not an easy thing to code), that string in a function. When you call the function it redraws the whole page with the new variable values client side.
I'm brainstroming here. I haven't tried it.
In frameName1:
<script>
if(whatever){
LCID = "1034"
}
else{
LCID = "1055"
}
function doWritePage(){
var thePage = "";
thePage = "html header stuff, more html literal text";
thePage = thePage + parent.frameName.someVariable1;
thePage = thePage + "some more literal stuff";
</script>
}
=====
In frameName:
<script>
if(parent.frameName1.LCID = 1055){
someVariable1 = "some text1";
someVariable2 = "some text2";
someVariable3 = "some text3";
}
if(parent.frameName1.LCID = 1034){
someVariable1 = "some text1a";
someVariable2 = "some text2a";
someVariable3 = "some text3a";
}
else{
whatever;
}
</script>
It seems to me that something similar to this would redraw the page in different languages without making a call to the server. Again, I'm just thinking out loud. I would have to design some tests to prove it. Also, I think that all the server side includes would have to be stored in string variables as well.
I'm just thinking out loud to see if anything of worth comes out. Right now it seems that the programming effort will not be worth the gains. As I said before, the www.istanbulmuzesi.org solution is good enough for me.
Bottom line: if it aint broke, don't fix it.
Thanks, for taking time to read my post and bringing me up to speed on Snitz Forums 2000 - International.
Jack Tutzauer< |
|
|
|
Deleted
deleted
4116 Posts |
Posted - 06 March 2002 : 20:41:35
|
I agree with you on positive facts of client side processing, but we need to have some test before we choose the final method.
The bad thing about JS (in addition to browser issues) is that some people (especially in large componies) have their scripting capabilities disabled because of security reasons. The idea we have in mind (for the future) is to provide both: If the user is JS enabled, then use it, else let the server work for them. This has its own difficulties with the current implementation of v4.
Current implementation is somehow temporary, although it works. Current emphasis is to collect the strings and prepare some LangPacks for next development stages. You may wonder why I have a function called fLang() which does "nothing". It's just a placeholder for future functionality  .
Jack, thank you for sharing your thoughts with us. We really appreciate that .
Think PinkPost v40b03 Patches< |
|
|
|
tutzauer
Starting Member
Panama
28 Posts |
Posted - 07 March 2002 : 14:59:03
|
quote:
I agree with you on positive facts of client side processing, but we need to have some test before we choose the final method.
The bad thing about JS (in addition to browser issues) is that some people (especially in large componies) have their scripting capabilities disabled because of security reasons. The idea we have in mind (for the future) is to provide both: If the user is JS enabled, then use it, else let the server work for them. This has its own difficulties with the current implementation of v4.
Are there are enough end user who can not use scripts to warrant supporting two versions of Snitz? They would have to be big corporate users who are using a Snitz 2000 forum outside the company for corporate business (not personal which they can do at home) and who are working for a corporation which does not allow scripts. If the forum is internal, the corporation can BUY a pay-per-view forum.
Also, if there were a real need the corporation could give script access to certain machines.
Maybe a solution would be to lock in 'server only' at say version 3.xx. Releases beyond that would require client side scripting ability. Each forum administrator could do the math to see if he should upgrade.
I think that you should give it some serious thought before deciding to support two versions...of course, we could double your salary to cover the double effort...let's see 2 x 0 = ??
Jack Tutzauer< |
|
|
|
Topic |
|
|
|
Forum Locked
