I always felt annoyed casting ServletRequest object to HttpServletRequest whenever I am programming using java servlets. The servlet API is designed so that it abstract away Http protocol and looks at the big picture in which you may also have FtpServlet or PoP3Servlet. But, as every JSP developer knows, till date we have not seen any implementation of the servlet API for any other internet protocol so wasn't it much better that Sun Microsystems would have created the API specially for handling HTTP protocol based servlets allowing developers lot more hand-coding productivity?

In the above example I just wanted to show that casting the abstract object to specific type every time you want to use it is unnecessary.

In other cases, abstraction may adversely affect the performance and scalability of the overall/final application itself. Take the example of old EJB specification. A significant number of developers were using just jsp/servlet based client for connecting to EJB layer and so abstracting the whole business logic in EJB that too working on marshaling/unmarshaling using Remote objects was overkill! 

I was facing the same issue when designing a framework for our web applications. I was faced with choice of creating it very abstractly, making it easy later to make it independent of Http protocol thereby making is suitable for non-web / desktop applications as well. But finally I realized that if there is no shot term, there is no long term. So an ideal choice is to make it abstract as much as possible without losing the lightweightness, to the point and easy to understand naming conventions and developer productivity.  In short I choice 'abstraction' but not 'too much of it'!

Receiving payments from PayPal was always not a very convenient experience for PayPal merchants in India. Most small to medium digital product sellers use PayPal as it offers zero setup and monthly fee. PayPal used to send payments using Standard Check that too through standard postal mail. Now that they have enabled payment withdrawal directly to Indian Bank Accounts, a major issue hindering PayPal usage in India appears to be gone away.

 

This is really good for lots of merchants and for PayPal too.

A year ago, I was looking for a way to integrate complex/graphical reporting into our software offerings. I was sure that the way is to find a open source project that has the right kind of license and right kind of technology. Regarding licensing, I wanted to make sure that we should be able to use the reporting engine/technology in our commercial softwares. I evaluated JasperReport, JFree Report (now part of Pentaho) and of course, BIRT. Here is what I liked in BIRT

1. BIRT is an Eclipse project: This made sure that the project is going to be live and evolving (as an open source project) in the times to come and will become more feature rich as the time passes. We were not afraid that someone is going to close the source directly or indirectly (by selling documentation at high prices) by creating a future version that will require commerical support to do anything but trivial.
2. BIRT uses standard technologies to the maximum level: It uses HTML for layout related things, JavaScript for scripting and CSS for styling! It naturally means we can leverage the existing knowledge that our developers have in creating the kind of reports our customer want. Faster and at lower costs.
3. BIRT offers very good GUI Designer: A graphical designer not just makes your life easier while developing the reports but you can also give it to your customers so that they can also do some small changes that they might need here or there in the report. Most important thing is that BIRT designer is group of plugIns for Eclipse IDE and hence quality of the report designer is excellent.
4. BIRT has a very nice Web Viewer: Yes it comes with nice pre-integrated ajax enabled web viewer that your can run from Tomcat (our favourite) or any other Application Server in less than few minutes.
5. BIRT has quality documentation, sample database, example reports: All this reduced the learning curve to a very affordable level.

If you are looking for a serious reporting solution (open source), I will recommend that you should consider evaluating BIRT. May be you can find the technology you are looking for.

Normally external javascript and css files are supposed to be included in the header of a web page. But, at times we come across situations when we need to include some javascript or css file when we are into the body of the page (that is head portion has already been written).

To include the javascript and css resources you can use the following two methods.


function injectJS (fileName, jsbase){
    var src = jsbase + '/' + fileName + '.js';
    var ipts = document.getElementsByTagName("script");
    var found = false;
    for (i=0; i < ipts.length; i++){
        var type = ipts[i].src;
        if (type.indexOf(fileName) != -1){
                    found = true;
        }
      }
     if (!found){
    var headID = document.getElementsByTagName("head")[0];        
    var newScript = document.createElement('script');
    newScript.type = 'text/javascript';
    newScript.src = src;
    headID.appendChild(newScript);           
    }
 }   
 
 
 function injectCSS (fileName, cssbase){
    var ipts = document.getElementsByTagName("link");
    var found = false;
    for (i=0; i < ipts.length; i++){
        if ( ipts[i].rel != 'stylesheet') continue;
        var type = ipts[i].href;
        if (type.indexOf(fileName) != -1){
                    found = true;
        }
      }
     if (!found){
        var headID = document.getElementsByTagName("head")[0];        
        var c = document.createElement('link');
        c.type = 'text/css';
        c.rel = 'stylesheet';
        c.href = cssbase + '/' + fileName + '.css';
        headID.appendChild(c);           
    }
 }   


Note that the fileName should not contain the .js or .css extension.
The methods can be called from anywhere in the body of the html page (from inside standard script tags/block).

Above methods make sure that the resource being injected is not included more than once. Feel free to use the code and modify it to suit your heart's content. No strings attached!