Flickr Flash Player
I added a flickr flash player to the site under photos to replace the old flickrRSS feed reader which rarely worked. FYI If you want to do this to your site just use the following code and replace the user_id with yours (obtained here):
< iframe align=center src=http://www.flickr.com/slideShow/index.gne?user_id=12345678@N00&tags=foo frameBorder=0 width=500 scrolling=no height=500 > < /iframe >
Aop
K so I was going to have an entire AOP example finished tonight but the family ended up stopping by to see the new baby <excuses, excuses> which means the example will have to come tomorrow. However here is a great synopsis on aspectj to tide you over till then (I want my AOP!):
Java, Struts and Outputing an Excel File
In a project I was working on last night I needed to output sets of data on demand in excel. I found various ways to do this however this was the most simplistic and worked every time on all my computers. (Mac, Linux, XP).
response.setContentType("application/vnd.ms-excel");
response.setHeader("Content-Disposition","inline" );
Those 2 lines make the instant translation of the HTML I put in the page go to excel. Now something massive to remember here: The formatting is pretty unpredictable if you use css or any fruity styles. Luckally in my case I didn't need to use either; just output the data.
In either case you simply draw the HTML as you would to output a basic page with the response lines telling your browser that excel owns the page.
Java Reflection
In a project I was confronted with a reason to use Java Reflection. What I found was a way to dynamically scale a class to find out its variables, methods, etc. During this process fortunately we changed gears and moved away from the design which was forcing this way of thinking. I have, ever since, been looking into it more and more and trying to discover why it isn't more commonly used. Aside from the inherent complexity and detracting from readability I found a list of "draw backs" to using reflection which I will paste below:
http://java.sun.com/docs/books/tutorial/reflect/
Drawbacks of Reflection
Reflection is powerful, but should not be used indiscriminately. If it is possible to perform an operation without using reflection, then it is preferable to avoid using it. The following concerns should be kept in mind when accessing code via reflection.
- Performance Overhead
- Because reflection involves types that are dynamically resolved, certain Java virtual machine optimizations can not be performed. Consequently, reflective operations have slower performance than their non-reflective counterparts, and should be avoided in sections of code which are called frequently in performance-sensitive applications.
- Security Restrictions
- Reflection requires a runtime permission which may not be present when running under a security manager. This is in an important consideration for code which has to run in a restricted security context, such as in an Applet.
- Exposure of Internals
- Since reflection allows code to perform operations that would be illegal in non-reflective code, such as accessing
privatefields and methods, the use of reflection can result in unexpected side-effects, which may render code dysfunctional and may destroy portability. Reflective code breaks abstractions and therefore may change behavior with upgrades of the platform.