#advanced java script programming

[lodiwayoflearning]

View Page Source

By Felipe Lodi

We have seen before how HTML though useful is limited. We have seen also that HTML is what the Browsers interpret in the end, on the client-side, on the user side. Scripts in the other hand are very important to either change dynamically the HTML on the client-side or create dynamically HTML code on the server-side sending these results to the client-side.

Scripts can work on HTML created by scripts as long as this coding is well formed. Actually one layer does not have to be aware of another, the Web developer however takes all this into account when planning, designing and developing, so he can provide the best results on each layer, either on the server-side or client-side.

The Web developer also knows that client-side code can be easily seen by everyone. All HTML code rendered by the Browser is accessible on the Browser itself. There are some way to do this either using built-in capabilities of the Browser (e.g. View Page Source on Google Chrome) or copying and pasting the content into a Web developing tool (e.g. Microsoft SharePoint Designer). There is an option also on main Browsers to save the current page. This option on the Internet Explorer for instance, saves the current page as a HTML file as well as the accessory files such as scripts, images and style sheets in a separated subfolder.

Client-side code, for example JavaScript code, can also be seen using all of these methods. It is important to mention that JavaScript code can be put along the HTML files or on “.js” files, this is an implementation choice, but on both cases the client-side code is exposed. On the later though, the advanced user has to figure out the reference tag to the external script file and then navigate to the files using as base the root URL. Therefore there is no way to protect client-side code, HTML and scripts.

On the server-side things are different though. All scripting hardly developed to generate the HTML to be shown on the client-side is protected. Starting from the fact that the server-side scripting does not have to obey the same URL structure the end user sees on his Browser. Server-side scripts usually are also in different number than the resulted HTML as Web developers can use the benefits of Frameworks, Assemblies and Object Models.

Using CGI (Common Gateway Interface) is another way that pages can be generated by an executable file. “A CGI executable is a standard executable file but such that the HTTP server can tell it in fact contains a program that is to be run” states Herme. (Herme, 1997) By executable, we can understand this code has been compiled and therefore, even if the advanced user gets this executable, the proprietary source code cannot be seen, so it is not possible to understand how pages are created from this file.

Besides dynamically created HTML code, server-side code usually has database connectivity details, business rules data and even more information about the Company that owns the code. Therefore it is highly recommended keeping all this source code safe and protected against threats.

Therefore, even if the advanced user gets the resulted HTML pages and client-side scripts, they cannot do much with that. They will not be able to know how these pages were created as he does not have access to the source code, the server-side code. For the sake of clarity, some examples of languages that work on the server-side are PHP, Java and Asp.Net.

REFERENCES LIST

Herme, 1997. Writing basic cgi-bin applications. [Online] Available at: http://clip.dia.fi.upm.es/miscdocs/pillow/pillow_www6/node2.html [Accessed 27 March 2011].

[lodiwayoflearning]

Democratic.DOM

By Felipe Lodi

Web development though exciting is challengeable. Depending of what you want to achieve or what you want to deliver, many tools and applications must be used. Amongst these tools sometimes three or even four Browsers must be used in determined phase of the project in order to test the pages. By pages I mean the behavior of client-scripts, HTML and CSS rendering. I got myself developing for Web using two, sometimes three monitors so I can keep opened different Browsers as keep things speeding up during the development.

But why this has to be done? If you are a developer and are reading this, you know what I am talking about it. You build a beautiful page, the UI (User Interface) people do their amazing job, coders also do their scripts and in the end what happens? The page works differently on the Internet Explorer than Mozilla Firefox (than Netscape, than Google Chrome, then Safari, then Opera). I basically do not consider the latter (and project managers during the project also recommend the same), given the low audience it has, it is waste of time. Opera had 1.17% on the last February 2011. (W3Counter, 2011)

As a Web developer, there are times I have to discard some cutting edge features of HTML because of this compatibility. Be developing for the first version of the Browser to assure compatibility is not the biggest exciting (and payable) work I wanted to do as well. Therefore I need to find out a thin line between what has to be done and what can be done considering the main aimed Browsers. Usually projects have scoped the audience and the aimed Browser, so it helps to narrow my choices.

An important point to mention: we are about to experience soon WebTV Browsers. Yes, they are coming and they have to be able to render these pages too. But if the project you are being paid to develop pages to, does not include WebTV audience, one less to achieve. The problem might become bigger, I can conclude.

It might become bigger because a new Browser on the market might have a new vendor that decides by using a Document Object Model (DOM) different that the one proposed by W3C. “The HTML DOM defines a standard way for accessing and manipulating HTML documents.” (W3Schools, n.d.) In my opinion, it should be the same across all Browsers.

The DOM is so important that rules the way HTML objects can be accessed in a Webpage. Starting from the document itself, which is the first object on the page, developers can reach nested objects and change their functionality, behavior and style. They can move them and they can remove them from the page. Using the same DOM, Web Browsers interpret the pages and show what “us”, the users, see and use.

Microsoft does not use the standard DOM from W3C. Instead they propose the Dynamic HTML (or simply DHTML) on their Internet Explorer versions. They state that their version 4 of the browser the developer can access almost everything on the document and that on the version 5 “Every element is exposed”. (MSDN, n.d.) It already explains some incompatibilities.

The Mozilla Firefox uses a DOM-like based on the W3C standards. They use their Gecko Engine that parsers the Document Object Model in a same way for all Mozilla-based Browsers. (TimeMachine3030, 2011) It also explains some incompatibilities against Internet Explorer. It is true that by validating the pages during the development, the chances of these pages are working fine on the Mozilla Firefox are great. Which it is not guaranteed when using Internet Explorer.

Being made and commercialized in a proprietary way, Microsoft tries to force their own standard that though based on the W3C DOM has some differences. In my opinion, since we are discussing Web and its standards and since W3C has been elected (and respected) as the International Community, their model should be used in all Browsers, in all platforms.

As a way to, as they say on their Website: “lead the Web to its full potential” (W3C, 2011), keep using standards rather than try taking the ownership of the Web would prevent a huge amount of wasted time during development, testing and validation procedures. As well as preventing frustrated final users: The aimed audience.

REFERENCES LIST

MSDN, n.d. About the W3C Document Object Model. [Online] Available at: http://msdn.microsoft.com/en-us/library/ms533043(v=vs.85).aspx [Accessed 25 March 2011].

TimeMachine3030, 2011. Preface. [Online] Available at: https://developer.mozilla.org/en/Gecko_DOM_Reference/Preface#What_is_Gecko.3F [Accessed 25 March 2011].

W3C, 2011. ABOUT W3C. [Online] Available at: http://www.w3.org/Consortium/ [Accessed 25 March 2011].

W3Counter, 2011. February 2011. [Online] Available at: http://www.w3counter.com/globalstats.php [Accessed 25 March 2011].

W3Schools, n.d. HTML DOM Tutorial. [Online] Available at: http://www.w3schools.com/htmldom/default.asp [Accessed 25 March 2011].