White List

<?php

// White List
// userid from 1 to 10
if ($userid == 1 || 3 || 5) {
// then allow access to manager admin module
} else {
// normal member module
}

?>

Black List

<?php

// Black List
// userid from 1 to 10
if ($userid != 1 || 3 || 5) {
// normal member module
} else {
// then allow access to manager admin module
}

?>

Both White List and Black List has its own advantage. White List offers better control and security (take the above for instance, when you forgotten to add a particular userid to the black list, anonymous access to admin module would happen; while missing an userid in whitelist would simply cause that user not able to access admin module which is less damaging); while Black List can help reduce the length of the code to get the same logic done.

In my opinion, lots of developers would pick Black List as the preferred approach, since it’s shorter and faster to write.

There are two guideline which i would suggest to follow when making the decision:

1. Security Concern: Try to use White List whenever possible since it provide better security (this is an important factor especially when your application is already serving more than million of people).
2. Efficiency: Only use Black List when you have a huge amount of checking to do, which make White List not reasonable. (e.g. White-Listing over thousands/millions of tags created by users)

So far i have been following the above rules as far as possible, and it reduces logic bugs and gives better code readability.

// HTML Snippet
<div id="test-area">
  <ul>
    <li>row 1</li>
    <li class="even-row">row 2</li>
    <li>row 3</li>
    <li class="even-row">row 4</li>
    <li>row 5</li>
    <li class="even-row">row 6</li>
    <li>row 7</li>
    <li class="even-row">row 8</li>
    <li>row 9</li>
    <li class="even-row">row 10</li>
  </ul>
</div>

// CSS Snippet
ul {
  list-style: none;
}

// color the even rows
.even-row {
  background-color: #ccc;
}

The above method is okay when you are working with simple rule, but how about if i only want 1, 7, 13, 19…(6n+1)th rows to be highlighted. Then you probably need to write some javascript and do calculation to do it. However, with HTML 5, we got a better yet easier way to accomplish this. We will be using the new property “nth-child”. Let me illustrate by rewriting the example above:

// HTML Snippet
<div id="test-area">
  <ul>
    <li>row 1</li>
    <li>row 2</li>
    <li>row 3</li>
    <li>row 4</li>
    <li>row 5</li>
    <li>row 6</li>
    <li>row 7</li>
    <li>row 8</li>
    <li>row 9</li>
    <li>row 10</li>
  </ul>
</div>

// CSS Snippet
ul {
  list-style: none;
}

// Note that n is a special symbol here
li:nth-child(2n) {
  background-color: #ccc;
}

See the power of nth-child? We now no longer need to label alternate rows, instead, we use the nth-child property. We simply tell nth-child with the calculation (e.g. any integers like “1″, “3″, “5″ or using the special “n” variable for help, like: “2n” representing alternative rows, “5n” representing every fifth rows or even the word “odd” and “even”… you might try to edit the code above to use “even” instead of “2n” to accomplish the same effect.), and it will apply the CSS for you. To learn more, you might try the demo page i made.

To begin, we have to prepare the appropriate directory.

sample.xpi

/install.rdf
/components/
/defaults/
/plugins/
/chrome.manifest
/chrome/icons/default/
/chrome/
/chrome/content
/chrome/skin

Then, we have to work on the install.rdf. It’s an RDF file to document about the extension’s information.

<?xml version="1.0"?>

<RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:em="http://www.mozilla.org/2004/em-rdf#">

<Description about="urn:mozilla:install-manifest">
<em:id>sample@steve.chan</em:id>
<em:name>Sample Plugin</em:name>
<em:version>1.0</em:version>
<em:creator>Steve Chan</em:creator>
<em:description>First Plugin on Mozilla Thunderbird</em:description>
<em:homepageURL>http://www.codetter.com/</em:homepageURL>

<em:targetApplication>
<Description>
<em:id>GUID</em:id>
<em:minVersion>1.5</em:minVersion>
<em:maxVersion>2.0.0.*</em:maxVersion>
</Description>
</em:targetApplication>

</Description>
</RDF>

Note that,

1. <em:id> shall be filled in with string formatted as “string”@”string” like an email.
2. under “targetApplication”, the <em:id> shall be a proper GUID, it could be easily gen with tools (Google it)
3. For minVersion and maxVersion, they determine which version of Thunderbird could install your plugin. View Valid Application Versions.

After finishing install.rdf, there’s another manifest to prepare. It’s chrome.manifest which describe the extension file structure of yours.

content sample chrome/content
overlay chrome://messenger/content/messenger.xul chrome://sample/content/message-overlay.xul

skin sample classic/1.0 chrome/skin/classic/

style chrome://messenger/content/messenger.xul chrome://sample/skin/style.css

1. content describes the location where content’s file and folder are located
2. overlay describes which UI of Thunderbird is to be worked on / Override. (Do read about XUL to get your familiar with this idea)
3. skin describes the location where the skin’s file and folder are located
4. style describes what stylesheet to apply on various UI.

Next step is to create an message-overlay.xul

<?xml version="1.0">
<overlay id="sample" xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">
<statusbar id="status-bar">
<statusbarpanel id="my-panel" label="Hello, World!" onclick="alert('Hello World!')"/>
</statusbar>
</overlay>

1. statusbar with id=”status-bar” states the merge point of the extension, the while xul describe the addition of an “Hello, World!” label on the bottom right corner of Thunderbird (status bar).
2. The onclick is given a javascript function to create an alert box when the “Hello, World!” label is being clicked. (XUL works with javascript!)

Last but not least, we have to package the extension

Zip all the Content of the extension (without the root folder), and rename .zip into .xpi, and it’s DONE! Congratulation.

Ref: https://developer.mozilla.org/en/Extensions/Thunderbird/Building_a_Thunderbird_extension

***Note: The extension describe in this post does not promise to build a proper extension, it just to give a rough idea on how the process is like, and this is a simplified one. If you need any help, you might leave your comment, and i will try help you as much as i can.

Suppose you got a request object with InputStream.

// request is the Request Object
// Turns InputStream into string
String base = IOUtils.toString(request.getInputStream());

// Whenever you need the InputStream
// Turn the string back to InputStream this way
InputStream in = new ByteArrayInputStream(base.getBytes());

The library i built relies on an open source library called PocketSoap. Its support on Attachment and its ease of use is appealing and i at last chosen to give it a try and build a POC on top of it. Below is a simple usage sample for the PocketSoap library.

using System;
using PocketSOAP;
using PocketSOAPAttachments;

namespace PSTryout
{
    public class psWS
    {
        CoEnvelope e = new CoEnvelopeClass();
        e.Body.Create("id", 1, "", null, null);
        e.EncodingStyle = "";

        HTTPTransport h = new HTTPTransport();
        h.SOAPAction = "query";
        h.Timeout = 30000;
        h.Send("http://localhost:8080/ws/", e.Serialize());

        string enc = "";
        e.Parse(h, enc);
    }
}

String newString = new String( oldString.subString(0, 5) );

Simple, Right?!

Never ever try to use meaningless or single-character name for variables. This could mess up the whole class. Even when doing temporary storage, we should stick to some kind of rules like, having a prefix of “tmp” followed by meaningful name.

2. Remove unnecessary header

Not only will this save the time of code compilation but also reduce the ambiguity when using certain implementation type.

3. When reusing code, NO CUT & PASTE

There’s always moments when we want to perform some sort of operation that has been coded before. DON’T COPY & PASTE. Rather, we should create a function to encapsulate them, and reuse it. This does not only reduce lines of code, but also provide more clean and generic approach on refactoring code which could ease the trouble of test-case writing.

4. Know what you are CATCHING

Catching exception has been widely adopted in java and it’s sort of compulsory. In CECID’s code base, this is true as well. So one important thing to note is that, we should understand what we are catching when writing “catch”. Often eclipse and other IDE will generate codes for you. But, do you know why? Always include useful error code/warning rather than empty catch blocks.

5. Don’t retain something useless

Often functions are written to return value. However, this does not necessary mean you MUST store that return value. Sometimes, in certain circumstances, return value are useless, don’t keep them, it could create confusion. When you keep them, i would expect it to be used somewhere.