Monday, October 22, 2007

the end of it all is near

The demo went well (not great) there was some technical issues. I think we could have expressed the demo a bit better, however i think with the little time available we still did ok.
I am doing thesis more than this subject for the next few weeks and then before the weekend of the presentations and the exam i'll do most of the study.

Saturday, October 20, 2007

integration - the great unfair night!!!

well the past week seemed to me to be very unfair, its 3:40am and i've got it all integrated (by all only my 3 on moday) fruther more i've changed the skin slightly.

There were many issues with the code that i hand to fix. The way hiberante was using databses had to change as the code was using to instances of hsqldb, i had to change it to one. also there was a conflict with a jar, so i had to revert it back to an older one and fix.

further more i had to inject data into the database, but the maven things were all commented out.

at the end of the day i'm bitching! i have a thesis i should be doing!!! anyways its done i'll make presentaion tomorrow. Since no one replies to emails or uses the wiki, doesnt seem very fair at all. People expect me to then help, i dont think i'll be able to, but hey, hope not too many people read this :)

Sunday, October 14, 2007

Discussion of sakai prototype

So its been a while, however i expect to do this as deatiled as i have recorded in my code and as part of SVN..

Overview
Firstly the task at hand was to move from and Spring MVC application into a fully integrated Sakai application. Now there are two approches here:
  1. Simply convert the system, into a sakai app by adding some extra information in the web.xml file, and register the tool with sakai using a registration file.
  2. The more complicated thing to do is to redesign the directory strucutre and enforce the full sakai tool, this separates api, tool, implementation, and model. Further create nested POM files.
It was clear from the start the second would be very hard to get working as it required a complete redesign of the system. At first it was daunting but I thought i'd try.

The Full Story
The first task was to install sakai, i downloaded the source of sakai, and then complied it using Maven. That was an issue in itself. Maven required several aspects that needed to be set up, at first I installed maven 2 and configured. On doing this i then fond out that Sakai 2.2.3 uses Maven 1.0.2. Thus i had to uninstall it and then remove the repoistory. All along i was using the eclipse plugin for maven. Now this became probalamatic as it included versions that were not comaptable with Sakai and was forcing sakai to use them.

On removing this and then using the correct version i realised that all this would be too much to get working in windows. So i decided to use my Linux box instead. I put maven on this, and then complied Sakai and was able to deploy it ease (LInux working i know its scary). It was now time to try and get the tool built. It was daunting to try and make the dir structure by hand. So at that point i decided to try and look for help from the Sakai community and everyones freind Google. On doing this i found the Sakai App Builder plugin for eclipse. This was perfect as it built the directory strucutre, and also was capable of building all the POM files, as well as the authentication service integration.

The Sakai App builder was used and it generated the whole structure that was needed. It was then my task to fill in the gaps. The following is what i had to change:
  • Change the Sakai registration file to include some new description and titles.
  • The base object that holds most of my logic i.e. the model data. This was the Club, and i also had to rewrite the hbm.xml file for it to ensure the mapping is correct.
  • The sakai.properties file to allow it to use the DB, at first MySQL was going to be used, but after some playing around HSQLDB was easier and quicker, so we used that.
  • The ClubBean that was responsible for control of the web app. It played the role as the connection between teh JSP and the Java files. Using dependency injection we are able to give it everything it needs. This was the Logic classes that allow for the saving, editing of Clubs. Secruity function via the external logic class, and finally performing searches using the searchingtool. Each of these have an interface and then an implmentation.
  • THe interfaces then became part of a libaray that was then added to the global Sakai shared library. This means that my tool can be used by others via the API. This is what i do with the Authz module, i simple use the API and the impl is hidden from me.
  • The JSP files were created to fit directly into the sakai format using certain classes for the CSS, and special Sakai-style tables. Using these we are able to create a tool with the SAkai look and feel.
  • The searching tool was played with alot, first i implemented a simple DB search tool, that wasnt very good at getting results. Next a regex version was used and this was much more succesful, this was finally used as the other versions did not work! This version used the search tool within sakai however it required me to implemnt a horible interface! Also relied on Enity tracking and producers which were quite difficult to grasp without much documentation. The search tool is run within the jsp, via the ClubBean which has the tool injected into it at start up.
At home it ended up working after alot of time and effortit was able to work, Maven proved to be difficult (again) it was unable to download the ocrrect version of the generic dao object. i wanted 0.91 but for some reason it could NOT! So i manually changed the POM files to only refer to 0.9. This then fixed that issue.

Then i got to uni and thought sweet its all good, just need to rebuild it all :) . How wrong i was it took forever and didn't work!
After a great deal of apin and anguisg it was because Maven dpl task was not copying the JSP and WEB-INF directory. This was manually fixed by moving the files over, however since i was using a full Sakai tool the files were split over many files. These include compoents folder for the package itself, and then the lib folder for the api. And most importantly the acutal web app that tomcat uses this is the JSP files and the beans.

So there it is simple if you use maven (1.0.2 and its nice and you configure some stuff and you great stressed) and SAKAI APP BUILDER this IS a life saver as it makes the dir structure and maven files as well as many of config xml files.

Sunday, August 26, 2007

project proposal

The scaffold for this proposal is taken from from the UOS website.

Purpose (problem statement):
To simplify the process whereby student's find clubs and societies that they are interested in. That is creating an new channel of communication between students and clubs and societies of the university.

Background:
Currently the only techniques in place to join students with the clubs and societies they are interested with is during O - Week in the week 0 of semester 1(and to a lesser extent Re - O Week week 1 of semester 2). Also there is a directory of all clubs that are registered on the Union website. Now the problem with this is that is hard to navigate, and is unsearchable. This web site does not provide a mechanism to formulate links between the students and the clubs.
By providing a new way to find the clubs and socs that students like it will help keep memberships in the clubs growing and allow more student's to have the complete university experience. The Clubs and Socs program provides an important part of the university experience.

Users / Actors:
The actors that will use the application are as follows:
1) Clubs and Socs Executive: It is their role to update and upload information about their particular club.
2) Clubs and Socs Administrators: These are the union execs that run clubs and socs, it's their job to add club and socs execs as part of the registration every year.
3) Students: who can search the system and get in contact with the clubs and socs they want.

Use Cases:
1. Add / Edit / Remove Club and Soc Exec
2. Add Club Information
3. Search for a Club
4. Contact a club (this one may change submit interest)

These use cases may evolve over time.

Thursday, August 23, 2007

recent labs + hibernate

Monday's lab for me well was out... epilepsy and all ... well i'll try to get the hibernate part done asap, also this weekend i will finish readings and write the description for the project.

Wednesday, August 8, 2007

extra lab

So I went into the lab today and did some work, i finished of the Ant JUnit part. Also i did the form data. The form part was quite easy however it was something that i had not used. Everything was integrated with Spring. The main issue that was quite new was the integrated with tags. The tagging library allowed the inbuilt Spring framework to be used at all areas of Web IO. The reason this is powerful is that we can then use the internal Spring functions to do things like:
  • Validation
  • DB connections
  • Log in etc.
I think this is much better than using simple standard xHTML tags. We can then form better automation and the system will be scalable.

Other things that I needed to mention that were important are:
  • Tagging is a critical part of Spring and i need to look at this a bit more.
  • JSP relies heavily xml and the web xml files. The strucutre of these needs to be learnt instead of relying too heavily on the files that are already there

Monday, August 6, 2007

lab 2

Lab 2 was not as productive since i ran into major issues with the JUnit part. This was because of a faculty install, and so i was the Guinea Pig for the solution. At the end of the day it did work and the JUnit tests (which i knew how to do) worked.
One thing i did learn though was the way to make ant do them for you (even though this took forever to get working) This can be useful in the long run. I will be going back to the lab on Wednesday to finish of section 3 and 4. This should be more productive as i will begin using things like tag libraries and forms, which i am new to.

Croosing chasms

Crossing Chasms: a pattern language for OO application frameworks.
Brown, K. and Whitenack, B.
Vlissides, J et al (eds), Pattern Languages of program design.

This paper deals with many issues with relation mappings to OO systems. This is a major issue in current real time OO centric systems. The paper concentrates on static mappings, that is how the objects map to tables and vice versa.
many of the issues raised come from basic DB theory and going from first Backus Normal form etc. Allot of the paper deals with the best way to deal with relationships and map these things from a design standpoint. Allot of this is hidden is we use something like Hibernate.
However we will return to this paper after we do some more things on Hibernate. However some key points to note:
  • Look at the way objects map to the DB early so this mapping has some significant effect.
  • Ensure you spend time with the database and map the relationships like you would when you going from 1st order through to 4th order BN.
  • You will need to give every object some unique key, in order to make the relational world happy, that is everything will need some form of primary key, and this will help to amp relationships (from simple 1 : 1 to inheritance mappings).
  • You will need to have some idea about the way the database stores primitive types so you know what format things will map to.
  • When dealing with the issues of relationships you should use direct access (i.e. pointers within the object) rather than relying on the presence of foreign keys which is inherently slow. However ensure that these do exist and are updated to ensure that when an object needs to be instantiated it can be.

Frameworks = components + patterns

Johnson, Ralph E
Communications of the ACM. Vol 40, (10) pp. 39 - 42

In order to understand frameworks you must first try and define them. We can define a framework in a computer sense as a reusable design of parts of a system represented by abstract classes. It provides a customizable interface for developers to use.
Frameworks are like components (such as those components in an OLE library) however they are more complex and also you can customise them allot further. A component can be thought as simply code reuse. A framework is more than that, it is actually design use as well.
Frameworks reuse design aspects like a template or a high level schema. The difference is that a framework has been described in a fixed programming language (Java or C++).
Reusing design has its benefits and its own cots. In the long run you can save time and money with Frameworks, however there is always the steep learning curve associated with developing it.
A pattern is a way to describe a solution to a problem in a certain context. Frameworks implement patterns in a specific way. That is they transform context specific ideas into some tangible code that solves a certain problem. For instance MVC is really a pattern, however the way Spring implements MVC can be though more as a framework.
Frameworks are in the middle between pure code reuse or design reuse. The allow us to use design principles and patterns in a language (and hence domain) specific way.

Tuesday, July 31, 2007

lab 1

Today's lab had many different parts to it these included:
  • Eclipse
  • Tomcat
  • Spring
  • Ant
  • J2EE and JSP
  • Linux
  • Servlet
  • JSTL
The first part of the lab was easy for me as i have experience with Ant and Eclipse on Linux. However below are some thoughts and things that i should note for later.

Ant provides a tool to deploy, compile and clean the Java app. It serves the same purpose as make with added features. The main part of the Ant program that we deal with is the build.xml file and the build.properties file. These file together provide the deploy, build and clean commands. the properties file gives project specific components such as: location of files. One thing that i noticed is the layout that they want us to use. That is the file layout is different to the one that we would see in normal J2EE apps that i have dealt with before. This is the way that Spring likes it and so we will try to follow it.

The general structure is:
\
|-src
--|bus
--|web
|-war
--|-WEB-INF
----|-jsp
----|-classes
----|-lib
build.xml
build.properties

This is what we will try and keep with.

The next part that was also quite quick was Tomcat. The tomcat file is located in the /opt/tomcat/ folder and is copied to /tmp/tomcat/ at each start up. Tomcat is used in order to deploy our Java app. It does this by using servlets.

The next part was new for me as i have no experience with Spring. Spring is a framework that provides a vast amount of functionality. We use it mainly for the MVC components that it offers. Spring uses servlets in order to perform tasks. So there is a Dispatcher servlet, and a mapping servlet (both which are in our web.xml file)
Once we have this we can form the beans which define the instances of the mapping servlet and dispatcher servlet. This goes into our app specific .xml file. In order to make all this work we require a large amount of extra data in the form of all the libraries. These are copied to our WEB-INF/lib directory and are in the form of JARs.
Spring uses as default the Logger4J app, and so this also is included and written to.

The main issue that we have at this stage is that the model and the view are as one. IN a real MVC app we want the Model and View decoupled. To do this we use a class provided by the Spring framework (InternalResourceViewResolver) . This is instantiated by the use of beans. Doing this decouples the View and Model. and combines them only after the particular view has been resolved.

The business logic is added using simple classes e.g. we use products in order to perform our tasks, these all go into the src file and are split in terms of business logic and web (the controller itself). The controller is an important part as what it does is combine the view and the model, and includes any business logic that is required.
In order to have some data we again use beans to populate our data. This is done in the xml file that controls the app servlet. This is important as it is the app specific things that want to populate this app with certain beans.

The final part of the lab was improving our ant instance with more functionality (again this is easy).

Reflections on what i learnt:

Today i completed Part 1 and Part 2 of the labs. The main concepts and skills i learn was:
  • Use of Spring: how spring works and what you need to do to make it help you
  • The organisation of Spring and what is offers. That is the MVC and the many classes files.
  • Logger 4J interface.
  • Beans as applied to Spring, and MVC.
  • Using Spring to build an app.
The next thing i need to do is make my own app and try not use the files they have given rather then modifying files try and write the sevlets myself. Also try and write some beans.

Hello

This is my blog about what i'm doing and leanring in ebus5003. I also have one for my eng project.