...

View Full Version : Is there a way of accessing the source code of all the predefined JavaScript methods,



SpiritualStorms
06-26-2004, 05:43 AM
and objects?

I was sort of wondering if there was a way of accessing the methods, objects, and functions of all the javascript predefined concepts?

Can anyone tell me why javascript is not the same as server side programming? What exactly are the limitations? I ask, because from what i understand, one can technically create objects with javascript, so in a sense, you could do classes, like in Java, but yet, i am also to understand that javascript is only a client side language, and not a server side, like Java. This being the case, what exactly are the technicalities that makes this language incapable of going into the regions that other languages can?

shlagish
06-26-2004, 05:50 AM
The difference between a client-side language and a server-side language is this:
client-side: Is installed on the clients browser. It can use the info that is passed to the browser only.
server-side: Is installed on the server. It can use all the info stored on the server.

the way it works:
you make a page.
when the browser requests this page, the server-side scripts are executed BY THE SERVER. The result of all these scripts is a nice html document. the server than sends this document to the browser.
the browser loads the page and only then does it execute the client-side scripts..
So, with client-side, you can't, for example, take a file stored on the server, edit it, and save the changes since you only have access to the small bit of html the server gave to the browser.
With server-side, you can't detect events (click of mouse for example) since you only prepare the page for the browser to read and then have no power over it...
I'm not very good at words nor at server and client side technologies, lol, but this is my best explanation. If you need anything more, just tell me and I'll explain furthur with more examples and stuf like that :)

SpiritualStorms
06-26-2004, 06:44 AM
Ok, i understood that server, and client side differed more or less of where things were located in terms of certain things, like files, and the what not. This part i understand. What i dont understand is how the bounderies are drawn in terms of the conceptual framework. Is it an arbitrary boundery, or a boundary that relates to something revelant?

In other words, i understood that the main difference between a server, and a client side computer is that servers have more horse power as it were, hence why they are used for the storing of massive information that be recieved by a pc. But over, and beyond this, i do not know why a distinction must exist between a client, and a server. The analogy is that the client is like a car that pulls up to a gas station, and gets gas. A server, is the gas station that 'serves' the gas, which is more often than not, the files that are viewed as a webpage, like the actual html file, the images, or the other types of mime type resources, such as sounds, and videos.

But from the perspective of programming, i dont know why a distinction has to be made, since as far as i am concerned all of this is programming, so why must there be a distinction? i dont know if i can better phrase my question, but i am looking for a much more technical explanation than, "well, servers simply have more horse power!" Am i making sense?

Terry
06-26-2004, 02:16 PM
The distinction is real. Client side programming works with code that resides on the client. All that is necessary is served to the client by the server. A very solid line and a major distinction.

Javascript works when the whole document has loaded and all the necessary code for it to work has been cached by your pc. The server's job is done at that point. Now, whatever has been included as script in the document can do its job. Javascript works "on the fly" at that point. It responds to events, that is the key. The doc could already have been loaded hours ago but that same code (now cached on the client) will obediently respond to a user's interaction with the webpage. Specifically, events triggered by an onBlur, onChange, onClick, onDblClick, onDragDrop, onError, onFocus, onKeyDown, onKeyPress, onKeyUp, onLoad, onMouseDown, onMouseMove, onMouseOut, onMouseOver, onMouseUp, onMove, onReset, onResize, onSelect, onSubmit, onUnload etc, etc. All these events, and many more, trigger certain behaviours that were programmed to take place in response to the users interaction with html elements. Just looking at the names of these methods and you can see the possibilities inherent in an event-driven scripting language.

shlagish
06-26-2004, 06:45 PM
Much better than my explanation :thumbsup:

So in a car..
The server gives the gas to the car.
then, the client, via client-side scripting, can use this gas to, say, accelerate using the onPedalPress event... This, the server (gas station) can't do, of course.

Terry
06-26-2004, 07:03 PM
Actually the server owns the blueprints for the car and when you come knocking it instructs the scripting language (php, asp) that resides in the plant to make you a car from scratch! Wanting to take it for a ride depends on whether there is client-side scripting - if there isn't then it is a static piece of junk that will sit there and rust because there was never a gas tank to begin with. You need to create a new car from scratch with a gas tank (js) if you want to cruise :) Without js, all you can do is look at the thing.

Perhaps the browser can be likened to a parking garage ... one that can hold many vehicles within it.

shlagish
06-26-2004, 09:06 PM
ahhhhh,
Terry, master of analogies :)

Roy Sinclair
06-28-2004, 10:18 PM
Perhaps the most important distinction here is that "client side" scripts are served by a remote host which probably doesn't have the client's best interests in mind. Because of that there are severe limitations on what a client side script is allowed to do on client's machine since unresticted scripting would allow the client script to monitor the client's activities and other spying or less than honest activities. If client side script were not restricted, the internet would ba very dangerous place to be indeed.

Willy Duitt
06-28-2004, 10:29 PM
PERL used alongside of javascript is a dangerous combination indeed....

SpiritualStorms
06-29-2004, 07:27 AM
Want to expand on the following:


PERL used alongside of javascript is a dangerous combination indeed.... ?

glenngv
06-29-2004, 07:41 AM
I would say IE alongside with javascript is the dangerous combination.
That is because of ActiveX. With ActiveX enabled in IE, you can do anything on the client's computer.

jbot
06-29-2004, 10:28 AM
i am also to understand that javascript is only a client side language, and not a server side

er ... actually, you can code javascript on the serverside. this is funnily enuff called Serverside Javascript (SSJS), as opposed to the Clientside Javascript (CSJS) we're all accustomed too.

to code JS on the server you'll need a compatible server. this used to be Netscape Enterprise Server, and latterly IPlanet. this has subsequently been bought by Sun, so no doubt it'll have died or be in the process of dying. which is a pity because SSJS was very powerful and probably way ahead of it's time. it preceeded ASP, JSP and PHP as a serverside programming language.

to read up on SSJS, go to
Devedge (http://devedge.netscape.net)

that is all ... :cool:

jbot
06-29-2004, 10:35 AM
I would say IE alongside with javascript is the dangerous combination.
That is because of ActiveX. With ActiveX enabled in IE, you can do anything on the client's computer.

this all depends on the user's security settings. yes, you can do quite a lot, but in many cases the user has to be able to give permission first.

then again, given that M$ have a great deal of problem coding without bugs these days, there are ways to get at the user's machine without their knowledge. but that involves bug exploits and is hacking, which is not something we condone or want to encourage here. so, we'll say no more about it, never mind delve into how it's done. :rolleyes:

nonetheless, ActiveX is very powerful, especially for intranets and applications where the user might need to work with other M$ applications. sweet.
:D

SpiritualStorms
06-29-2004, 10:55 AM
..by others? I thought it funny how spy ware ends up on my system. Never could figure out how my machine seems to be controlled by others through viruses, and the what not.

Terry
06-29-2004, 12:27 PM
er ... actually, you can code javascript on the serverside. this is funnily enuff called Serverside Javascript (SSJS), as opposed to the Clientside Javascript (CSJS) we're all accustomed too.


Server side javascript's still available in IIS servers and can be used in place of VBScript in ASP pages. Actually it has morphed into JScript, IE proprietary. I have a book here called Pure Javascript (http://www.informit.com/title/0672321416) that has nearly 200 pages at the end, and more on the pdf, devoted to both MS and NN flavors of the server side part.

I wish PHP had been created with a JS/C syntax instead of a Perl/C syntax. Perl programmers would disagree, I'm sure, but at least with JS everything's an object to begin with. Instead of serializing code just to comunicate back and forth between JS and PHP, we could've had a much more powerful implementation between server, client and even Java.

jbot
06-29-2004, 12:46 PM
Server side javascript's still available in IIS servers and can be used in place of VBScript in ASP pages. Actually it has morphed into JScript, IE proprietary.

yes, i know of JScipt/ASP. but it's still not proper serverside JS, since it's encapsulated thru ASP. Serverside JS is the only proper javascript implementation on the server.




I wish PHP had been created with a JS/C syntax instead of a Perl/C syntax. Perl programmers would disagree, I'm sure, but at least with JS everything's an object to begin with. Instead of serializing code just to comunicate back and forth between JS and PHP, we could've had a much more powerful implementation between server, client and even Java.

that's wot SSJS was, I believe. but it was ahead of it's time, so hasn't had the same impact as ASP, PHP or JSP have had. pity.

here's a link to SSJS: http://devedge.netscape.com/library/manuals/2000/javascript/1.3/guide/intro.html#1022316

SpiritualStorms
06-29-2004, 03:58 PM
I did also say in my original post, the following:


It seems like i lost a part of the main tread to another post, so i will repost here:

Is there a way of accessing the source code of all the predefined JavaScript methods, objects, and the what not?

glenngv
06-30-2004, 04:05 AM
I did also say in my original post, the following:


It seems like i lost a part of the main tread to another post, so i will repost here:

Is there a way of accessing the source code of all the predefined JavaScript methods, objects, and the what not?

You mean you want to see the code inside Javascript built-in methods, objects? Like for example, the String method indexOf, you want to see what's exactly going on inside that method? The answer is NO, you can't access that.

Just curious, why do you want to access that?

jkd
06-30-2004, 05:20 AM
Sure you can. http://lxr.mozilla.org
See the mad C++ at work.

jamescover
06-30-2004, 06:13 AM
Copy and past the below script, add your own image, form, whatever, then change the Object and Object Name in the event handler:

<html>
<head>
<title>Object Properties Loop</title>

<script>
<!--

function showProperties(inputObject,inputObjectName){
result="";
for (eachProperty in inputObject){
result +=inputObjectName
+ "."
+ eachProperty
+ "="
+ inputObject[eachProperty]
+ "<br>"
}
oDIV1.innerHTML=result;
}

//-->
</script>

</head>

<body>

<img name="myImage" src="myImage.jpg" border="0" width="50" height="50" />
<br />
<a href="javascript:void(0);" onClick="javascript:showProperties(document.myImage,'myImage');">Show Properties</a>

<div id="oDIV1" style="position:absolute;left:25;top:100;width:750;font-family:verdana;font-size:8pt;">
</div>

</body>
</html>



-james

glenngv
06-30-2004, 06:24 AM
Sure you can. http://lxr.mozilla.org
See the mad C++ at work.

I'm talking in the context of programmatically accessing the inner codes of built-in methods. Is that possible in the link you posted? :rolleyes:

SpiritualStorms
06-30-2004, 08:33 AM
You understood my question, perfectly:


You mean you want to see the code inside Javascript built-in methods, objects? Like for example, the String method indexOf, you want to see what's exactly going on inside that method? The answer is NO, you can't access that.

Just curious, why do you want to access that?


Why? Because i want to know how they did theirs. Some times, if you want to know how to build a clock, you first need to disassemble those clocks you already have. Seems pretty logical to me.

glenngv
06-30-2004, 08:57 AM
Why? Because i want to know how they did theirs. Some times, if you want to know how to build a clock, you first need to disassemble those clocks you already have. Seems pretty logical to me.
Then you don't want to access it programmatically. You can manually browse through the inner codes of Mozilla js engine in the links posted by jkd. Well, good luck! :)

SpiritualStorms
06-30-2004, 09:21 AM
Please explain what you mean:


Then you don't want to access it programmatically.

glenngv
06-30-2004, 09:44 AM
I thought you want to know the native codes of built-in methods during run-time of your javascript codes until you mention the "clock" analogy and your purpose of just wanting to know how it was done. That's why I came to the conclusion that you actually want to manually look into the native code.

SpiritualStorms
06-30-2004, 09:52 AM
i want to open up the clock itself, and see how its built. That's what i wanted to know. So it is possible then? To see the native code as you call it. I call it the source code. I here one can design their own browsers, so i am sort of curious about exploring that possibility.

glenngv
06-30-2004, 10:01 AM
Follow the link that jkd posted.

Good luck! :D

jbot
07-02-2004, 11:24 AM
Server side javascript's still available in IIS servers and can be used in place of VBScript in ASP pages. Actually it has morphed into JScript, IE proprietary. I have a book here called Pure Javascript (http://www.informit.com/title/0672321416) that has nearly 200 pages at the end, and more on the pdf, devoted to both MS and NN flavors of the server side part.

I wish PHP had been created with a JS/C syntax instead of a Perl/C syntax. Perl programmers would disagree, I'm sure, but at least with JS everything's an object to begin with. Instead of serializing code just to comunicate back and forth between JS and PHP, we could've had a much more powerful implementation between server, client and even Java.

just discovered that you can script JSPs using Javascript, using the Bean Scripting Framework. Combined with Java Server Faces (JSF), we could potentially have a very powerful tool for creating web applications. That may even address your last point, Terry.

just some new thoughts :D



EZ Archive Ads Plugin for vBulletin Copyright 2006 Computer Help Forum