Code Away

Opacity, Shadow and Rounded-corner control over rendered objects make CSS3 exciting stuff. Imagine creating a beautiful website with all these features, without using an image editing program! (ok, throw in @font-face and you have the font of your choice on the webpage as well. That’s it. Image editing is out)

Its safe to assume that not all developers will be using these features for mainstream websites unless our very dear IE supports them. So we still have time to see these beauties in action. But we have a lot of gray area for what happens when these are used together. The implementations are still juggling with these questions.

For example, what happens when opacity of a box is 50% and a drop-shadow attribute is used for the box? Or, what happens when a shadow drops on a box which is having less opacity? Should the shadow have rounded corners for a box with rounded corners? How should a shadow with bigger fade (black to transparent area) render on a shadow with smaller fade?

These are just some tricky “beginner” questions with no straight answers. Fortunately the community is pretty enthusiastic about rendering these effects with markup. Lot of such issues and fundamentals have been discussed.

In an image editor you can manipulate the effect rendered depending on which operation you perform first. This is not really clear for CSS, and with browser implementations which can vary, it might be a bit of a hassle for us to have consistent cross-browser CSS3 markup ready to use.

For I/O newbies in Java, the big question comes is which of the methods are to be used for I/O read/write. Anyway, unlike some other languages, Java insists on using the “explicit” way of coding:

Code for Python (Write to file)

f=open('scratch','wb')
for i in xrange(1000000):
f.write(str(i))
f.close()

Code for Java (Write to file)

File f = new File("scratch");
PrintWriter ps = new PrintWriter(new OutputStreamWriter
(new FileOutputStream(f)));
for (int i = 0; i < 1000000; i++) {
ps.print(String.valueOf(i));
}
ps.close();

Discounting the mandatory include statements for java.io, class name, try catch block for any and all I/O operations, we are still left with around 4 classes to be used for 1 write operation to a file.

So the question newbie posts in a forum is: I am writing to a file, but I’m not sure whether I should use BufferedOutputStream or BufferedWriter

The reply generally holds this: If you are inserting chars, use a Writer, else use the Stream

This is fairly accurate, but for a slightly deeper understanding let us break down the modules

Streams transfer bytes. Period.

So when you want to transfer any binary data, you use streams. You open the file, wrap it with FileInputStream, take out the data and process it. When you save it back, you make use of the FileOutputStream. Similar classes to be used for transferring though other streams.

In case you would like to use some text-friendly methods for your ascii text, you need chars or a char[] array. To get this, you convert bytes to chars while reading (and similarly chars to bytes while writing), with a simple wrapper, which happens to be InputStreamReader for reading and OutputStreamWriter for writing.

To have data formatting conversion done by Java, wrap the Writer objects in a PrintWriter

To increase performance, you wrap the objects in a buffer. Java uses internally allocated memory space to provide efficient read/write operations. The working of the buffer is transparent to the programmer, except for few methods like flush()

(Any) OutputStream => (wrap in) BufferedOutputStream

(Any) InputStream => (wrap in) BufferedInputStream

(Any) Writer => (wrap in) BufferedWriter

(Any) Reader => (wrap in) BufferedReader

The Buffer classes also provide some friendly methods: readLine() in BufferedReader and write(String, int, int) in BufferedWriter. These are more of a convenience which can be coded anyway in 2-3 lines. In case your app can’t afford to wait for the buffer to get full before transmitting or receiving data, it is always better to avoid using Buffers than to use and flush() them throughout your program.

Everyone who builds event the tiniest webapps has used a form submit. This involves (even if one uses flash, or any other front-end) use of http GET or http POST method to get the information from browser back to the server, where one can writhe and wrestle with it all one wants.

The big question often happens to be which method to use. The basic wisdom you get from the guy in the next cubicle (or from Microsoft) is

The GET method[...] appends name/value pairs to the URL. Unfortunately, the length of a URL is limited, so this method only works if there are only a few parameters. The URL could be truncated if the form uses a large number of parameters, or if the parameters contain large amounts of data.

Also, parameters passed on the URL are visible in the address field of the browser. Not the best place for a password to be displayed.

As always, there are some more things one ought to know as a responsible developer to get this distinction correct. Firstly the definition as per the HTML specification (which is extremely useful)

If the processing of a form is idempotent (i.e. it has no lasting observable effect on the state of the world), then the form method should be GET. Many database searches have no visible side-effects and make ideal applications of query forms.

If the service associated with the processing of a form has side effects (for example, modification of a database or subscription to a service), the method should be POST.

The keyword “idempotent” says a lot. If the state of your application does not change with the number of times a request is sent with a parameter (set salary of X as 10,000 bucks) then the operation is idempotent.

A safer deal is to have form method as GET when the application state does not change at all (search for text in a file or database).

We will look at other practical differences between the two methods which further influence our choice (some of them are already covered by Microsoft. Yay!)

I attempt a tabular distinction below. Lets hope it is clear enough.

Http GET	Http POST
Encodes form parameters into URL(example: http://mysite.com/mypg?key1=val1&key2=val2)	Sends form fields to server without encoding them in URL
Has limited width FF2 : 8182 bytes Safari 2 : 8184 bytes IE7 : 2057 bytes	No upper limit for transfer
Can enable encoding of form only as application/x-www-form-urlencoded. No binary data / files can be sent	Can encode form values as multipart/form-data or application/x-www-form-urlencoded. The former encoding enables users to transfer files to server.
Page targeted can be bookmarked, since bookmark just remembers the complete URL	A big NO for bookmark, since the page is influenced by some parameters sent specifically by POST method.**
Values in hidden and password fields will be shown in the address bar of browser, as a result of everything being appended in URL	That’s not gonna happen here
Sending non-ASCII characters isn’t quite reliable	All character sets are safely sent where proper encoding is used

Some more detail on this with additional perspective is available here and here. Some perspective from grandmother’s viewpoint is available here

---

** Unless the page is rendered independent of transferred parameters, which for all practical apps is not the case