Week 8: Social Features Project

This week went by in doing more work with Calendars, such as sorting out the issue on the User Authorization for Google data apis.
Earlier in the week, I implemented the workflow of Calendars feature with fuctionality such as:

• creation/edit of events by users for chosen Calendars.
• the addition of org_admins userid's to the Access Control Lists of their org's Google Calendar
  
• sending notifications to Calendar owners with event request message and consequent approval by org_admin was also implemented.
• uplading of approved events into the respective Google Calendar
  

The latest is at my GAE. All users with user roles and user pages will be able to see the "Add Event", "Events" and "List Event" options. "Add Event" will result in a notification being sent to the respective owner of the Calendar for approval, hence one may not be able to see the event pop up directly on the respective Google Calendar.

After some discussions with my mentor, it was decided that it would be an acceptable trade-off to use the CalVis API to display Calendars. As there was no very definetive decision reached in the dev-list discussion, at the same time, there was also not a strong opposition to CalVis, my mentor and I decided to go with the CalVis. The UI of CalVis can be manipulated with CSS to a decent extent and hence, it can be designed to look better. Although it may never look as good as Google's :-(, it is a trade-off we get for having the cool Google Maps plus Youtube widget pop-up on Calvis. I am currently working on the CSS designs for the Calendars as well as the User Pages(i was supposed to have done this a while back!).

For the next week:

• prepare cool designs for the Calendars UI and User pages
• find out how and write cron jobs for keeping Melange-side and Google Calendar-side events in sync
• spend some time to refactor code to ensure it sticks to Melange styles and conventions
  

GSoC 2010 Data Seeder - Client-side HTML rendering

I have been much more busy than usual lately and it's very clear that this has affected my time spent developing for Melange. I'm pretty much behind schedule right now and I'll have to try a lot harder in the future to make up for the lost time.

I have been facing some problems choosing a right JavaScript templating engine for rendering HTML. The solution that I was going to adopt was actually a jQuery plugin, but had some problems rendering some templates causing an infinite loop in the browser. Failing to find a proper solution for quite some time, I have decided to switch to pure. I was preferring tempest at first because it was using the Django templating format, but now I see the benefits that the pure separation between templates, directive and data offers (a directive is a structure that binds data to the templates).

The switch to pure is now complete and you can check it out at http://sttwister-melange.appspot.com/seeder/home

There's support for seeding models and defining providers for all properties. There's limited support for references at this time, only being able to bind a model to another random model.

See you next time!

Document Editor: Week 7

Last week I finished implementing "revert to revision" action. Now, if you list revisions for the entity, you'll notice check boxes and a button "revert to revision". This button is activated when only one revision is checked. If you check some revision and press this button, back-end will delete all the subsequent revisions and will make checked revision current.

I also started working on the diff engine for revisions, but it is still work-in-progress.

In fact, I have to implement two buttons for revisions list: "revert to revision" and "show diff". I didn't manage to configure two different buttons for jqgrid, but Mario helped me a lot. I was able to understand the meaning of the "bounds" list and everything is perfect now. Thanks Mario!

GSoC 2010 Melange Testing Project: Week 7 of the Coding Period

Last week, I found that Python coverage does not track the properties definition of Melange models which makes the coverage of models still quite low. So, I first tried to exclude models from coverage report. This is done by stubbing out nose.plugins.cover.Coverage.wantModuleCoverage with a method which offers the option to skip packages for testing coverage report through pymox stubout. Later, however, I remembered that coverage should be able to track class variables and module variables. I reckoned that the problem may be that these Melange models have been loaded before the coverage starts tracking. So, I further used pymox stubout to stub out nose.plugins.cover.Coverage.begin so that it loads Melange after the testing coverage starts. It works! All the class variables and module variables of Melange models, logic and views can be tracked by coverage and the code coverage now is over 50%.

Then I further worked on various views, e.g. sponsor, program, student, organization, etc and aim to increase the overall code coverage to over 60% next week.