DPMIA - Drupal Partner Missing In Action

Last week my Drupal partner left to Maryland for an interview and won't be coming back until tomorrow so it was a little difficult for us to work and communicate regarding the UseCaseActivity effectively because of the time difference between Hawaii and Maryland. What we planned before hand was to see where we are now and then somehow have each other on different tasks so there is no possible way for us to overwrite each other's work.

Continuing where we left off from my previous blog post, we began setting up the table for the 3 verification types (text field, upload image, confirmation code) for the admin to add. Each verification type will have different fields where the admin is required to fill out.
Here is the fields required to fill out for each verification type:

Text Field
- Question
- Answer

Upload Image
- Upload Image Instruction

Confirmation Code
- Number of codes to generate


The purpose of the verification type is what the user will have to submit for that activity. Another 3 tables into the database are created in order to have the pending table to input valid data for each verification type that will store every submissions the user submitted.

Here is a screenshot of what the admin sees in the pending table:

On the first column displays a list of usernames and their submissions. Admins verify if the users' answer submitted are similar to the suggested response. If it matches the admin will award the user by click on the award button. The user will earn the amount of kukui nuts for that activity. Some suggested response shows a "None" field the reason for this is because the answer lies to more the number of confirmation codes. We still have to work out how it will try to match the user's confirmation code with our. By next week Thursday we will have everything tweaked and running for admins and users.

Scheme-ing Through Our Schema

Last week's blog I posted a diagram schema of our database for our activity manager module. It was a good start for us on figuring out how my partner, Daniel Colton, and I will be arranging and obtaining the inputted information. The reason for this is because in the UseCaseActivity the admin will decide what verification type will the user has to submit as their answer. Those 3 verification types are text field (answering a question), upload image (uploading an image for proof of activity), confirmation code (entering a unique code from the activity). The problem for this is how to make a general table for all 3 verification types.
We used the schema to improve our activity manager form layout by adding more input fields depending on what the admin chose as verification type.

Here is a screenshot of what our old verification type field looked like:

Now here is a screenshot of how it looks now:

The main difference between the two is the old version uses radio buttons while the new version uses checkbox. The reason for the change is in the UseCaseActivity, admins will want to create more than one verification type. What we added on the new version is after checking on a box it will generate the appropriate fields for additional information.

Here are screenshots of what will reveal for each verification type:

Text Field:

Upload Image:

Confirmation Code:

Multiple Verification Type:

The goal for this week is to start getting the user's input. Once an admin creates an activity, users can view that activity's information once it is published. Users can earn Kukui Nuts by submitting the correct input for that activity. Once the user submits their answer it will be verified by the admin if it meets the requirements.

PHP + Drupal + coding standard = DruPHPal Coding Standard

After the presentation for my group's progress on our work using Drupal our professor wanted us to polish and clean up our module's code. Each group have been coding with different languages so each must follow their own language's coding standard. One group will be following the Java Coding Standard while another will follow PHP. However, our case is a little complicated than that. Drupal is written in PHP so I thought we are following the PHP coding standard. What makes it complicated is that Drupal has its own coding standard that we must follow too. So what is the solution to this? At first an idea to combing both was something we could do. Since our module is based in another module that might be the best way to have our code written with the condition to Drupal Coding Standard. One of the few things we had to recheck in our code is the indentation and the limit of characters for each line.

As for our progress with the UseCaseActivity we began thinking of how we will create our database to store the necessary information and retrieve that information for viewing and verification. During the initial sketch of our schema it was going well until we reached the part of adding the verification type. There are 3 verification types ( text field, upload image, confirmation code) that needs to be stored and finding an efficient way to retrieve those data.

Here is an image of our schema so far:

I am a little rusty with my SQL so I may need to do a little review before I finish my final schema for this project.

Re-module-ing our module

My partner and I attempted to get many requirements up to date with the small amount of time we had dealing with the creation of the activity manager mockup given by our professor which can be viewed here. Our modules interface is pretty basic but it gets the job done.

After getting the test module to work in our system we immediately began by designing the layout for our activity manager module using the test module as our template. The syntax for Drupal is a little difficult to comprehend when I just started to learn PHP and getting familiar with the SQL queries needed to create three basic components to our activity form, the data field, description of the data field, and the submit button. The minimum requirement of creating an activity is filling out the data fields and click on the submit button to confirm it's done. Once it is submitted it will store the information by the data field name into the database. Even though everything is kept into the database we had to figure out how to retrieve that information and print it out in an organized fashion. There was a way to have the results print out however it displayed the data in a continuous line. We then realized we hit a wall with our current module.

We started searching for example modules that can be used as a node. That way it can be viewed the way Drupal does it. The current module we have is integrated into the example module instead and that is how we resolved our display issue.

Here is a screenshot of our working activity manager module:



The first screen shot shows the basic fields fr the admin to fill out.



Second screen shot is the continuation of the fields to creating an activity.

While creating the data fields I have written a validation function to check if the input data are appropriate for each field. Example would be typing a set of characters into the "Activity Duration" field when it will only accept integer input.

The next step we did is to create a sign up manager module. This module allows users to sign up for the activity and it will be recorded into the database. Basically we used the activity manage module as our original template to create the sign up manager module. With all the activities created, it will store those data into the sign up module database and display each title with a sign up button into the "Activity" sub menu. Users are able to see what is available and just by clicking on the sign up button will add them to the activity list.

Here is a screen shot of what the user will see when the list of activities are displayed.





Like I said in the beginning that it does not look pretty at all. We still need to figure out how we will structure the layout for the list of activities. As of now what the user can do is sign up for an activity and it will print out below "Test Message Log" if you have successfully been added

The goal for the upcoming week is to continue our work on this and hopefully move on to the next requirements from the user case activity mockup.

Modify the phase variance...of the module

The quote, "Modify the phase variance" may sound familiar to Star Trek or StarCraft fans. This was a command that originated from Star Trek in which helped solved their machine issue. In StarCraft, by typing this into the chat field it activates the cheat to build any buildings/structure without the need of researching/building initial buildings/structure. Unfortunately, this was not the case in Drupal.

This past week, my partner and I was assigned to follow the instructions given from our professor. Since we had no knowledge in creating our own module in Drupal, we began to find modules that may benefit us and modify it ourselves to behave almost similar like the steps given to the instructions. I said similar because we assumed our professor wanted us to design it the way a Drupal module developer would since there are limited control in using web content management system (CMS). So basically our way was not exactly the way he wanted it.

The day of our meeting, our professor clarified the instructions by saying he wants the module to behave like the instruction given. Now the plan from now till next week Tuesday is to have a working module that does exactly the instructions say and by doing this we might have to create a module from scratch and hopefully get help from other module developers for advice.

What we have done so far is read documents and watch tutorials on how to create a module in Drupal and also getting to know the syntax for PHP and mySQL. The most difficult part is combining all those to have a working module.
The goals for the next 3 days are:

• be familiar with PHP
• be familiar with mySQL
• integrate both PHP and mySQL together to understand how it works
  
• Play with the sample/test module and have it working in our Drupal
• Modify the sample/test module and understand the syntax

The first thing we tried is getting the test module working in Drupal. A basic module requires an extension file of .info and .module. With these two files we can have it revealed along with the list of modules in Drupal. What I find interesting and yet weird is that in when creating the .module file you usually start with "< ?php" and end with "?>" but in the Drupal Coding Standard, having the ending tag is not allowed.

Here's what we got as the result for having it working.


This module first creates a database with the following columns [id, timestamp, message].

id - for every message made the id increments by 1
timestamp - this saves the time and date when the message was saved
message - the actual message saved

In the text area is where you type your message. After you click on "SAVE THE MESSAGE" it will save and store the message into the database. Then it will view the information right below the button. All the information are viewed in descending order.

What I learn from all of this is before doing anything make sure you ask questions about the instructions to your instructor and have it clarified about the goal or else you will waste your time doing something entirely different.

Getting to know Drupal

If you read my previous blog post then you will know that I will no longer be using dotCMS as the current web content management system (CMS) for the UH Dorm Energy Competition website, instead I will be working with my partner, Daniel Colton, using Drupal.

In the beginning we had trouble collaborating our own development in version control. What made it a little more difficult is we're both using different Operating System which may affect the whole development process. So using subversion to upload our directory to our Google Project is down for the moment. As an alternative we decided to do it remotely by setting up a remote server. Now it is more accessible for us to work with since we're both using the same directory. The only downside to this is the loading time when changes are made then saving it to the server.

The goal for this past week was to create an activity interaction between the user and admin. The admin must create an activity event for the users to sign up for it. More information of the mockups can be found here.

The first thing we did is search for modules that may be of use to us. What we have found so far is the "webform" and "signup" module. The "webform" module enables us to develop an create an application for the admin to fill out information for the activity. Some necessary information would be the title of the activity, date, location, etc.

Here is a screenshot of the activity form using the webform module

The "signup" module is an extension for the "event" module. It allows users to view and sign up events from the calendar event made by the admin. With this module, we can add limit to how many users can sign up, view the list of users who have signed up, and email them with more detailed information about the event.

Here is a screenshot using the signup module

This is nice and all but does not provide the necessary use from the mockups. We have to figure out a way to edit the modules so it can behave the same way the in the mockups.

What I learn from all of this is that there is always an alternate way in doing things even if the latter may not be the easiest way but as long as it works. So in our case, subversion seemed impossible for us to work with and we ended up using a remote server. As for modules, there may be a simpler way to have the behavior implemented from the mockups to our website.

CMS Finalist

It has been about two months since my group have been working on four different web content management system (CMS): dotCMS, Joomla!, SilverStripe, and Drupal. Our Professor has now chosen two of the four CMS will be chosen for us to work on for the UH Dorm Energy Competition.

And the two CMS going to the finalist are...*drum roll*

Drupal and Joomla!

I'm not too surprised about the results since both Drupal and Joomla! were able to successfully execute the necessary features for the UH Dorm Energy Competition. Both Drupal and Joomla! offers more modules/plugins/extension than dotCMS which made features like CAS login, forums, and slideshows (features for the UH Dorm Energy Competition) easily implemented. Joomla! has a lot of modules that are free or can be purchased to use that opens a lot more potential than itself. With Joomla's plugin installation graphic user interface (GUI) there was no need for opening the command prompt to manually install it.

However, what makes dotCMS different from the other two CMS is its organized structure in customizing templates, html pages, and files. It has its own starter page for beginners to get familiar how dotCMS works. I don't know much about JavaScript but if you do, this is the CMS for you. JavaScript can be done just by typing it into the template. Another great use from dotCMS is its "containers" and "macros". I was able to reuse lines of codes by creating "containers". With these containers I am able to invoke it into my templates and it uses less lines of code than copy and pasting the same code over and over. Simple macros like date, logins, etc. are added just by typing the correct syntax into the template. dotCMS has its own way of doing things that may have qualified for our project but I was not able to find its full potential at this point. dotCMS was and is still a great CMS and I would have loved to continue working with dotCMs beyond the needed features for our project.

Starting this week, Daniel and I will be using Drupal for the UH Dorm Energy Competition.