CTV15 Sandbox

Transaction methodologistics

2007-07-17T10:18:00.001-07:00

The current version of Cassander (2.2RC3) uses templates to format data. These templates are processed by PHP and then sent to the client. The program currently uses a muxed retardation of AJAX and server-side processing. The main page is drawn once, by admin.php (or another page like login.php) and then each subsequent request (for each module) is handled in the same frame without refreshing the page. The frame itself is not a frame element, but a div that changes its contents. A problem arises from this method. When should admin.php draw the container frame and when should it just draw the inside content. A quick workaround was written for this to solve the issue but while it fixed the issue, it created more problems than it solved. Sometimes a page would need to be redraw (to refresh a cached page) and sometimes the same page would need to be drawn in the frame. This was solved by moving the "inside" check to the global header. If "inside" was sent to the server, it did not draw the outside frame because it is "inside". This became complicated because sometimes the page wouldn't know if it was inside or outside and the inside content couldn't talk to the outside content (because of scope resolution problems).

What if the content didn't need to specify inside or outside? What if the content could know automatically if it was inside or outside, and if it needed to call an inside or outside request? There are two ways that this can be accomplished. The first way requires no significant modification to the current infrastructure, but it does not facilitate growth or expansion very easily. The second method requires a very significant amount of change but will allow easier implementation of future features.

The first method

To track whether a request is inside or outside, append a pseudo-unique transaction ID to the end of each request by making a function that would be used to get data instead of doing it by hand each time. This transaction ID would track whether the request was INSIDE or OUTSIDE. Any subsequent request made by the current transaction would carry the inside flag.

The second method

Make one container for the site ("The wrapper"). The wrapper then requests data which is then returned via a JSON-style request. The data is then interpreted and printed on the site, no refreshing is ever done. Each request will return a template ID along with the data. If the template ID is not in the cache (There is a list of templates and ID's) then it will download the template and cache it. This way, the wrapper does not need to know how to draw data that it hasn't had to draw, but if it has to draw it again, it will be able to draw it again without asking for template data. This method moves Cassander towards being a total AJAX application.

Conclusion

Based on the information provided above, the second method is most appropriate. While it may take longer for this method to be implemented, it will allow for faster implementation of features down the road. The second method will provide a faster interface, better usability and an overall improvement on the current interface. Because the data will be sent in a generic format, it will allow for better third-party interpolation and integration.

XHTML vs. HTML

2007-01-17T09:59:00.000-08:00

Right now, the "web" is filled with poorly-formed documents. That is, websites that do not conform to the HTML 4.01 standard. Believe it or not, there are specific rules for coding in HTML. XHTML is a combination of XML and HTML. XHTML, when properly formed, is compatible with every XML reader (that conforms to the XML standard). Rather than separating web browsers and XML browsers, they can be combined.

Most browsers now-a-days (Firefox and Internet Explorer included) are very forgiving when it comes to poorly-formed HTML documents. For example, it is required that every meta tag be closed.

<b>Hello World</b>

Traditionally, some tags were never closed:

<p>Hello World!

This caused problems. The browser would have to determine where the tag was to end and when you present this feature in an XML document (A tree based architecture, nodes, branches, etc...) the

tag represents a node and the node MUST be closed.

XHTML is the first step to document standardization. It requires four aspects of programming to be considered a well-formed document. They are:

All elements must be properly nested.
All elements must be closed.
All elements must be lowercase.
All documents must have one root node (I.E. <html>)

This is why XHTML should be used instead of HTML. It is the first step to standardizing the web.

DOM: The Document Object Model

2007-01-16T14:16:00.000-08:00

While DOM is not a new thing, I have finally jumped into understanding it. I've been using elements of DOM (parts of DOM, not the elements themselves... even though that's what they are) for quite some time: manipulating HTML after it has been rendered using Javascript. Basically it is the aspect of AJAX and DHTML that make it Asynchronous and Dynamic.

DOM treats the entire HTML page as an XML document. The document is an object. Each element of HTML is an object as well, called a node. This allows one to control any aspect of anything on a website.

Like I said, this is not new and I am not just discovering this now, but I am finally exploring its manifest functions and its overall purpose.

I wrote a small script to demonstrate the essence of DOM which you can view at http://sandbox.ctv15.org/domexample1.html.

Here is the main function of the page:

function do_nodes(){
var parent = document.getElementById("parent");
nodeList = parent.childNodes;
child1 = nodeList[1];
child1prime = document.getElementById("child1");
if (child1 == child1prime){
alert("True");
}else{
alert("False");
}

}

As you can see from the example that child1 is in fact the same as child1prime. This proves that the object in the child list (nodeList) is the same as the one returned by getElementById.

I will expand on this later with a better example of the full features of DOM.

Pseudo-Ascynchronous File Transfer

2007-01-15T11:58:00.000-08:00

As you may have seen on some websites such as gmail.com, files are uploaded asynchronously. That is, the website does not reload or refresh or go to any other location, the file simply starts uploading. It is not possible to upload a file via HTTP without submitting a page request because XMLHttpRequest does not handle file uploads. One technique to accomplish the task of uploading a file without reloading a page is to use an iframe. An iframe is an inline frame (As opposed to a block-level frame which takes up an entire segment of a website). Instead of refreshing the document (The parent object), you simply use an iframe to hold the form and do your uploading from that.

This technique is easy to implement. Simply make an iframe with the file upload form in it, and put the iframe on your page. I have used a similar method but employed DTK (DojoToolkit). Dojo has a special transport called IframeTransport.

You can see it in action here: http://sandbox.ctv15.org/async2.html Locate a file on your computer and click upload. While the file is uploading you can switch between tabs. It will also inform you if the upload fails or not. You can view the dynamic source here: http://sandbox.ctv15.org/async1engine.php

My first test before I found that part of dojo was to create two different forms, one in an iframe and one not. Then, when the user submits the original form, it copies the data to the hidden iframe form and submits that one. Unfortunately Firefox won't let you do that:

Error: uncaught exception: [Exception... "Security error" code: "1000" nsresult: "0x805303e8 (NS_ERROR_DOM_SECURITY_ERR)" location: "http://sandbox.ctv15.org/.

It took a long four hours to figure that one out.

The Sandbox Devlog

2007-01-15T11:51:00.000-08:00

Here I will post scripts and documents regarding programming techniques with which I have been experimenting. I will post links to scripts that will demonstrate the technique. I cannot guarantee that the link will work, or you will understand what happens in the script. You may play around with them in any way you wish. These scripts are experimental, do not report any errors to me.