Learning bLog

Note: This blog is extension to the post blogged here , the OP has used one level tree to display in grid, whereas I used multilevel tree. From last 2-3 months I'm working on Flex, developing our in-house map editor. We've a requirement to show a grid with some column containing multilevel tree data, I googled it and found the above link which was matching to our requirement but got one problem, it didn't work correctly for multilevel tree. The problem is - It failed to adjust height when you expand inner child element. The whole tree get collapsed when you collapse the inner element. To provide a solution to above problems, you have to - Keep a flag which tells if root is closing or not, if root is closing keep the original height. For all other child expansion, count the children from existing "open items" and adjust height accordingly. The below code explains it all.

You want to test what your application logging and you don't know how to do that in simplest manner, well we've logback to rescue. (If your using slf4j but with other than logback as a implementation, then you have to add logback as a test dependency with logback.xml in src/test/resources) One (not exactly) caveat is that, for testing logs using logback we need to use Mockito for creating mock Appnder and asserting for the exact log string in argument. Here is the actual code- 1. Create a base test class for log testing. public abstract class BaseLoggerTest { final Appender mockAppender = mock(Appender.class); @Before public void setup() { when(mockAppender.getName()).thenReturn("MOCK"); (ch.qos.logback.classic.Logger)LoggerFactory .getLogger(ACCESS_LOGGER_NAME)) .addAppender(mockAppender); } protected void verifyLog(final String expectedLog, final Level level) { verify(mockAppender, atLeastOnce()) ...

We always have some good programmers around us who are capable of doing work at hand, but to success in long term we need better programmers. Here are some traits I found important to become better programmer. Good programmer start coding right away after picking up the task, better programmer first do some little design upfront (may be draw some UML, flowcharts etc), write the simplest readable tests first and then write minimum production code which makes that test pass. Good programmer stick to the tool, framework, workflow he/she knows best, better programmer keep the affinity towards any technology aside and evaluate and use the best possible tool, framework available.  Good programmer focuses on working code, better programmer too focused on working code but also gives the utmost importance to code readability, flexibility and other design principles . Good programmer ever read technology books when he/she was in college, better programmer subscribed to feeds, question...

Problem: There are cases when you want to test whether two objects are equal, mean did they contain same state or not ? This occurs mostly when you're trying to test JAXB generated beans or any VO/DTO which doesn’t' implement Object#equals() method or/and whose source code you can't modify . Solution: I knew there is a class (Commons lib's EqualsBuilder class) available which "reflectively" creates the equals method for you taking care all the rules for writing good equals method. But that class doesn’t have a method to test whether two object are equal or not. At back of my mind, I know Mockito library internally uses the same commons class to solve my problem. I quickly scan the mockito jar and found this class. Here is the code snippet for the same (please note, you have to add mockito jar on classpath for this) import org.mockito.internal.matchers.apachecommons.ReflectionEquals; . . . public <T> void assertObjectEquals(final T expected, final T...