This is the first post of the new year. I was busy writing SOP and other applying's bullshit and could not update Wickoo. Most likely I would be busy during next month either. As I told you in one of my last posts, I'm working on a very bad-written (if you ever could use the verb write) code base. My aim is to change the data access layer from Oracle to DB2. DB2 instance is a legacy database and it forced me to change some data model and structure of code. I wish I didn't do that! As I'm going deeper into the code, I find amazing stuff. Although rewriting the 80% of this project was a pain in ass, I have learned a lot. It was also a real geeky fun. In a series of posts I wanna share some screenshots from the code with you. They are really good stuff! ;)
1) How to initialize a backing bean:
Suppose you want to initialize a property by calling a method on corresponding backing bean before rendering the page. What would you do? The answer is not obvious in JSF, especially if the request is not a post-back. With Seam you can set the method to be executed in pages.xml file. See how they solved this problem. This project is in fact a Seam/JSF project:
Binding an OutputText to a method???? The name of the method is interesting too. It depicts that they knew themselves that it was a dummy way for initialization. It is worth to note that you can not use method expressions in JSF standard for values of the components. This initialization technique was possible only through Seam and JBoss EL and they actually abused both Seam and JSF!
2) Layering in Java application
Since I entered the Enterprise programming field, layering was the heart of our architecture. Usually there were a DAO layer that hid the JPA or Hibernate Session from above layers. Look at this two code snippets that are taken from a controller:
Yes, they are from a single controller. DAO instance is also injected into this controller. The first one shows apparently the interest of the programmer in Criteria API, so he exposed Session to use it! The second case is really amazing. The programmer wanted to presumably cancel an edit operation. because the entities were managed, they've got changed and this changes were visible to the user. (Although they were not actually persisted)See what he has done! Totally stupid: Clearing the entity manager and also flushing it. The answer in this case is to simply use refresh method on entity manager to clear changes made to the managed entity. Clearing the persistent context causes all entities become unmanaged and you must merge them again before any operation. One of the goals of Seam and Conversational scopes is to avoid merging and LazyInitializationException! and even if you want to clear it, why flushing it back to the database!
There is even something more interesting. It seems that the cancel method did not work properly for the developer, so he injected an entity manager right before the method and used a combination of its methods to solve the problem. For God's sake, learn the concept of technologies that you use!
If you have any other ideas, or maybe think you've understood the intent of the programmer better, please leave a comment.
Next time with two other examples of how you should not write your JSF code! After these series, I wanna start Java EE 6 tutorial here.
هیچ نظری موجود نیست:
ارسال یک نظر