TaskMaster - Day 10

The new user can be added to the project or task and data already entered is preserved. This is done by removing the form's default save action and implementing actions for each and every submit button. The submit button will dump the data into the params map and all that is required is to store/forward it along then retrieve it back afterwards.

The new user is to be notified by an email containing a link back to the project/task. The messagingService is responsible for this but has not yet been created.

More information here :)

TaskMaster - Day 9

When in the task or project creation page, a new user may be created given just an email address and name. Unfortunately, redirecting to the user creation page wipes out any data entered in the task/project pages. So far there has been no way of saving the data.

More information here :)

TaskMaster - Day 8

Finally added the user members to the project. Used a custom tag here that displays a list of checkboxes.

Also cleared the validation and a few other stuff.

More information here :)

TaskMaster - Day 7

Managed to clear a minor issue but hit a wall with the adding of members to a project, there does not seem to be any good examples covering the view interface for a 1:m relationship. Much frustration.

So right now there are three major issues, the messaging service, instant creation of a user for task or project inclusion and addition of members to projects.

More information here :)

TaskMaster - Day 6

Spruced up the views, changing or removing elements and code.

Aside from the MessagingService, which can't take off without a mail server, there are a few story issues. One is the adding of members to a project, figuring out how to do it. Another is to auto-create a non-existing user so that he may be added to a project or assigned a task, later on the user needs to complete his registration.

Still to tackle the validation problem.

It lives! :)

TaskMaster - Day 5

Added in some sample data. Made a few changes to the login and registration pages as well as creating a navigation bar. Validation of the registration data does not seem to follow the constraints listed in the domain model. The project creation page needs to be tweaked, to allow members to be added in.

The views in Grails are where all the presentation elements are present, with the controllers chipping in the model and the business logic. Whereas in Wicket, the presentation elements are coded and inserted through the placeholder ids which had been seeded in the HTML. Grails entails more time in HTMLland than is the case with Wicket.

Creating the war file for the project is a simple one-liner: grails war. This beats having to fuss around your own ant script and making sure all dependencies are being added. Now to find out how to change the version number on the war file, being stuck at 0.1.

Reading up on the messaging service, this seems a simple way of doing it.

The other blog is dead :)

TaskMaster - Day 4

Two services were created, AuthenticationService and MessagingService. The former service is used for logging in users (especially later on when the authentication methods increase, e.g LDAP, OpenID) and the latter service is to email users for whatever purposes.

A BaseController was created to add in an interceptor and the authorization to all controllers via inheritance:

def beforeInterceptor = [action:this.&auth, except:['login', 'logout', 'register']]

def auth() { 
    if(!session.user) {
        redirect(controller:'user',action:'login') 
            return false 
    } 
}

Cobbled together a working rough login and registration page. The controllers and views will be the focus from now on.

The other blog is on hiatus for the moment :)

TaskMaster - Day 3

Refined testing, splitting the various CRUD activities into different test methods. Said activity took up the whole day, squashing failures as they turn up.

Regarding the dates previously, switched to using the dateCreated and lastUpdated variables as GORM handles the timestamping with those variables automatically. There is another date variable that now works fine, making the past problem a head-scratching puzzle.

Next up is the service tier. On that note, found a nice Grails CRUD example at http://infoq.com/minibooks/grails. The PDF at that site shows how to create a Racetrack CRUD.

More information here :)

TaskMaster - Day 2

Today was testing day. Having previously done no testing on Grails, there was some reading involved. Much frustration was involved in trying to get the test to run. There was light at the end of the tunnel when this, under the section 'Testing Domain Classes' was found. Basically the need to flush while saving, to make sure it all flows to the database.

The light that was the flush was quickly snuffed out by the bold, hated 'FAILURE' from the test run. Much despair ensued. After some gritting of teeth and grinding of stone, the reason for the failed test surfaced. Apparently dates are not welcomed and with their exclusion, 'SUCCESS' was assured.

Now to properly build the test classes...

More information (or not) here :)

TaskMaster - Day 1

TaskMaster is an issue-tracking system, in the image of Bugzilla, to be developed using Grails. This is mostly a development project for training.

Eclipse is used as the development IDE. Integration with Groovy and Grails needed to be set up.

The first day was spent sketching out the domain model, with three primary classes; User, Task and Project. Users are assigned Tasks to do and Projects are user groups for a particular purpose.

A few problems came up regarding testing and checking into SVN.

More information here :)

J2ME Development on OSX

This follows the tutorial on java.net, which shows how to compile and package J2ME apps manually via the command-line.

First, a wireless toolkit (J2ME SDK) is needed. The mpowerplayer toolkit supports OSX and it comes with a preverifier. The MicroEmulator toolkit has a better emulator than mpowerplayer though.

Once a source file is provided, it is compiled by:
javac -bootclasspath /path/cldc-1.1.jar:/path/midp-2.0.jar /package/path/Source.java

The bootclasspath option uses the specified library files for the compilation, instead of the normal Java environment.

The next step is to preverify the class:
mpowerplayer-folder/osx/preverify/preverify -classpath /path/cldc-1.1.jar:/path/midp-2.0.jar package.name.Source

The preverifier default is to create a folder called output with the same package structure in the current directory. The preverified file is placed there.

In the output folder, create a Manifest.mf with the following:

MIDlet-Name: Source
MIDlet-Version: 1.0.0
MIDlet-Vendor: NameMe


Also in the output folder, create a jar file:

jar cvfm Source.jar Manifest.mf ./com


The penultimate step is to create a jad file descriptor, Source.jad, with the following:

MIDlet-1: Source, , package.name.Source
MIDlet-Name: Source
MIDlet-Version: 1.0.0
MIDlet-Vendor: NameMe
MIDlet-Jar-URL: Source.jar
MIDlet-Jar-Size:
MicroEdition-Profile: MIDP-2.0
MicroEdition-Configuration: CLDC-1.1


The last step is to fill in MIDlet-Jar-Size with the actual number of bytes the jar file takes up. This completes compiling and packaging.

Testing the packaged app in an emulator:
java -jar microemulator-folder/microemulator.jar Source.jad

Allowing the default behaviour of downloading the jad file, which then installs the jar file, set the MIDlet-Jar-URL to:
http://domain/url/Source.jar

Sites of Interest:

J2ME Development on OS X

J2ME Development on OS X, revisited