Near Finish

I'm so happy! Since yesterday, I've been asking God to enlighten me in initializing default values for the <@s.select> tag, whether multiple or not. Just now, I was able to give the roles default values whenever I edit the user. What I did was I have a List<Integer>, that is the container of the existing roleIds of the user, and put it to the value attribute of the select tag. It's quite simple, only that I've been experimenting with the wrong attributes. Many forums claim it's the property attribute, though it might have been right, there was no right example showing how it should be done. With the value attribute, I kind of experimented on it a bit and thank God, I was able to make it right.

*****

I was able to transfer the role identification to the User model. I added the isAdmin function in the User model, as how sir Butch suggested. And now, the loginAction is really much cleaner.

*****

I added 2 kinds of Login Interceptors: the one that simply assures that the user session is not null, and the other one that assures that the user session has an admin role. Jo mentioned (Anna said) Spring security. I wasn't able to experiment with this feature though.

*****

Another component is to be added: Exception. Just where should I put it? I have two kinds of exceptions, the one that we made to prevent duplicate values, and the Validation exception, the one Tina did. The validation exceptions weren't caught yet and I'm still finding the right spot for it. Also, the validation mechanism Tina implemented wasn't quite that easy to comprehend. I think it's not implemented as the usual interceptor. It doesn't have an interceptor reference, simply it has a mapping mechanism in the web.xml: patterns com.orangeandbronze.service.* so I think it maps itself automatically. Catching the exception is also another thing. Uhh, can you wait 'til I understand it (the validation impl)?

*****

Refactoring the bloodiest of them all: Book! I'm having a hard time right now understanding the literally messy code. What was I thinking that time? I couldn't effectively add the author – book mapping til I refactor this completely. Right now, I just migrated some unnecessary functions from the action to the service.

Refactoring

I'm currently on to refactoring our codes; making action classes not bulky, services simple and precise, and daos not calling other daos. I'm also sharing some of the parameterized mapper.

*****

I just finished refactoring category and role actions, services and daos. I just find something weird. In my category/update-cat.ftl, from the textfield, when I hit the enter key, it automatically "clicks" the Save button. However, in my role/update-rol.ftl, from the textfield, when I hit the enter key, it throws an exception: that I didn't declare a SUCCESS result type in my struts.xml, so I had to manually click the button save to make it work. I'm comparing the 2 ftls and struts.xml and currently, I can find no reason why such a thing is happening. Also, my two actions never return SUCCESS nor do I have execute methods.

*****

I just added role-user mapping when adding users. I wanted to eliminate the roleIdList of List<Integer> type in my user action but the strut's select tag wants it badly cause it returns a list of role ids, and there's no way to automatically map it to the id field of role.

One of the good things in my userAction is that the user-role initialization is now done inside user dao and not on user service. I'm now into providing an edit user function.

*****

Let me call it a day. In theory, we already did more than 80% of the project. But, yes "but", the integration didn't seem to have gone smoothly. The borrowing, and returning, can't be committed to the SVN due to an unknown reason.

I've already created a smooth navigation between login – admin – logout – login – employee etc. First thing tomorrow, we got to make the borrowing and returning fully functional. I also have to do a lot of refactoring still especially in status, author, books, and especially borrowedBooks. And yeah, we are planning to add the log in the services.

A New Blog

Finally, I have a new blogger blog. It's so easy to customize things with Microsoft Office (Blog), including add, and non-spontaneous editing of blog entries.

*****

Back to work – I've already distributed tickets to my group mates. The first four tickets that I issued were about: Validator, Login Interceptor, Borrow, and Request Book. I'm also trying to refactor the codes in my admin feature. I announced a new convention: no method should start with get/set unless they are getters and setters. Use "query***List" in the query methods inside the Daos. This is to enable me to easily filter methods in my outline explorer.

*****
Bad interceptors! The interceptors go before the action methods are accessed making my fields unset by the time the method actions are actually called. I'm looking for references on chaining interceptors to actions. Currently, the add functions are totally not working.

*****

Before calling our loginInterceptor, we now add a call to basicStack interceptor. This way, it kinds of "backup" the values of our fields before going to loginInterceptor and then restores them back.