#dynamic html and javascript

By Felipe Lodi

Imagine HTML as a limited (though big) set of commands that the Browsers are prepared to interpret and behave accordingly with the programmed mark-ups. As discussed before, there is no way to make HTML evolving and changing its behavior in response to users’ actions, system configuration or database content. HTML is static in the end when it reached the user’s browser, even though it might have been transformed milliseconds before.

This transformation is made by scripting languages and they happen either on the server-side or client-side. There are scripting languages that build HTML and there are scripting languages that transform existing HTML. The latter might be working on either dynamically created pages or static pages. Actually client-side scripting languages do not care how the pages they need to work with were created, as long as the HTML is well formed, they can do their job.

One of the most well-succeed scripting languages is the famous JavaScript. It is important to mention that despite of name and syntax similarity, Java and JavaScript are two completely different things. In the early 1990s when Internet was becoming popular there were basically two different Web browsers, Internet Explorer and Netscape Navigator. The latter was the first to identify that the Web pages would become interactive and they built a language called Livescript. (Chapman, n.d.)

Netscape had this embedded, and pages using this language did not need to be compiled. Users using this Browser were able to use pages developed using this language without having to install anything, differently that pages built in Java which required a plugin to be installed on the computer. What Netscape did was to take advantage of the name Java migrating Livescript to JavaScript. (Chapman, n.d.) That is just a brief history that also includes the beginnings of VBScript and Jscript, also good alternatives to client-side scripting languages.

It shows how important these scripting languages were and are to the user’s experience. Furthermore, not only end users’ experience at stake but businesses and the whole Internet concept and its evolution. The Web 2.0 for instance, would not be possible without scripting languages. Sharon Housley says on hers interesting article that in Web 2.0, “interactive content is the norm” and that the key components of the Web 2.0 are the Web itself, collaboration and syndication rather than power and complex web technologies. (Housley, n.d.)

I agree with her and I would say further that the collaboration is the strongest key. Imagine a user who wants to create his study workplace online. He first finds a (usually) free service that permits him creating an environment likewise his desk: File Cabinets, Calendars, Notepads and others tools. Scripting languages are already there on the Browser when he drags from the Web site’s tool box the desired component (e.g. File Cabinet) and drops onto the virtual desk. Then, after selecting all components he will need for his studying, he organizes his environment, putting the Calendar on the right, Notepads on the middle and File Cabinets on the left. Scripting languages are there too.

What the scripting languages do at this stage is transforming the former HTML page. This is more complex because the scripting languages also changes CSS properties dynamically at the client-side. For example, the coordinates and colors of his components are stored in helpful files called Cascade Style Sheets, that are responsible (in a well-developed Web site) for saving information regarding to positions, colors, borders, fonts and navigation amongst others.

On the other side, on the server-side, this information about his virtual desk is being saved on some sort of database (or perhaps XML files) to be properly retrieved every time he accesses the Web site. At that side, there is another role to be played by another scripting language. This coding will get the user’s information from the database, his used components, how he organized and configured them on the virtual desk and builds the HTML page to be delivered back to his Browser.

This HTML page, though built dynamically, has to keep working as it should, enabling all commands such as dragging and dropping. Therefore it has references to common client-side scripts saved on the server (meaning by “common” that all Web site users also share the same script files as they need the very same functionality). The pages are different, the users can configure as they want and save, but the functionality is common. For the sake of simplicity, they have the same enabled functionality.

Using only HTML would be impossible to build such Web site, such product. As illustrated, different scripting languages are used in different layers and steps to make this simple functionality. I do not see HTML doing this by itself. I cannot see how only HTML would, after identifying the user click, enable the dragging on the page. I cannot see either how only HTML would save the state of the page to be retrieved later.

HTML has though very important events to identify what the user wants to do. But this is the edge, I would say. After identifying what the user wants to do, HTML has to hand over to another powerful language, the scripting language. Whether only the client-side, server-side or both is a technical choice, but certainly scripts have to be there.

REFERENCES LIST

Chapman, S., n.d. A Brief History of Javascript. [Online] Available at: http://javascript.about.com/od/reference/a/history.htm [Accessed 19 March 2011].

By Felipe Lodi

The whole Web content has been changing for better. The way the content is created and the authoring of this content are handed now to the users, to the audience. In an evolution timeline where the pages were used to be static, then dynamic, now it seems that the further step is the content unity.

Even in dynamic Websites, where the things seem to be made aimed to the right audience, pages, results and content are differently displayed to each different user: the unity. Users build their content all the time. Blogging, Micro-blogging, Profile pages, Social networks and Online Photo albums are amongst tools that enable them creating their own content: in the end, tools for self-expression.

Everyone can become a writer and what the Web professionals and specialized companies do currently is to provide tools, frameworks and models to these “hungry” users. Hungry for content, hungry for creating content. It is all amazing and exciting how there are no limits nowadays (however ethical rules are meant to be respected, not every content is permitted)

This unity of content that every user can create is spanning for content personalization. Meaning by content in this case, every link, every image and every piece of text in a Web site, Web professionals realized that would be impossible for humans to create fitted content for every taste. Obviously this barrier also spans to former static solutions where this would be technically impossible but yet, dynamic Websites needed to be improved in order to keep the audience.

The audience wins when navigating on a Website such as Amazon for instance, where the virtual seller offers bargains based on the user’s recent navigation. The user does not have to be logged, does not have to be registered at all that the Website will offer content based on the user’s recent “clicks”. Also, “Customers Who Viewed This Item Also Viewed” (Amazon.Com, n.d.), suggests a trail of navigation that usually leads the user to new purchases.

Amazon and others companies that perform Adaptive Web-Site Development think that personalization is the key for keeping the users satisfied and coming back. Indeed we are kind of lazy reading and reading and it is easier when things are put in a way we do not have to “look for”. A search field on the top of everything also proves that theory.

An important technique used to store users preferences and navigation is Cookies. A little controversial though knowing that Websites are saving your own information on your own computer. Hence, Web developers realized that Cookies would not be enough since that in order to retrieve all users’ likes and dislikes, the information should be sent to the server-side. User’s use several computers and sometimes different systems. (Bra, 1999)

By the time this great article by Paul De Bra was written, XML Files and Web services (which use XML to transit information) were not being considered to this purpose. This article also mentions how Cookies are limited for many reasons. Cookies have limitations on their sizes, quantity and on how they are saved in different platforms such as Windows and Unix. (Bra, 1999) Cookies can also be disabled by advanced users and in this case Web sites would not be able to save the users’ preferences either.

Therefore as an alternative to client-side Cookies, Web services can do the job in a more “professional” and “guaranteed” way. Imagine a Web service as a web-deployed Method of an online Class that “does” something. As Microsoft stated: “defined an XML Web service as a software service exposed on the Web through SOAP” (Walter, 2001)

Web services can be connected using the same native events in HTML and save the user’s navigation. Web services can save stored session on the server-side so the user can “resume” later. Web services can store even more information than Cookies and Web services can be accessed through client-side languages such as JavaScript.

Web services use XML files to transit information. A so much wider option to Cookies as the format of data can be tailored designed and better interpreted by programs. XML is a multi-platform file, therefore it can be read by different systems. XML is generated from Object Models, the same layer that can be either used internally on the systems and externally using Web services.

REFERENCES LIST

Amazon.Com, n.d. Citizen Men's AT0200-05E Eco-Drive Chronograph Canvas Watch. [Online] Available at: http://www.amazon.com/Citizen-AT0200-05E-Eco-Drive-Chronograph-Canvas/dp/B000EQR6H0/ref=amb_link_19995401_1?pf_rd_m=ATVPDKIKX0DER&pf_rd_s=center-3&pf_rd_r=0EXK9JQE0S437JG4Z8CZ&pf_rd_t=101&pf_rd_p=488790311&pf_rd_i=507846 [Accessed 20 March 2011].

Bra, P.D., 1999. Design Issues in Adaptive Web-Site Development. [Online] Available at: http://wwwis.win.tue.nl/~debra//asum99/debra/debra.html [Accessed 20 March 2011].