GSoC 2014 week 13

As the GSoC 2014 has officially comes to it's end, I'm really happy that I could finish all my planned tasks successfully.

As a final change, I did some modifications in the exporting functionality, including few UI changes as follows:

Initially all the exporting types had same set of exporting options, although for some types, those options are not relevant. Now as shown above, upon selecting the export type, only the relevant exporting options will be shown. 

Apart from this modification, as I described in my last week's post, the whole schema exporting was re-factored in such a way that, it's now a plugin. So that in future, users can easily add new exporting types.  

GSoC 2014 week 12

After spending almost 12 weeks, I've not come to the final stage of the GSoC 2014. As a quick re-cap, my project was about merging "relational schema editor" funcationalities into the "designer", and make it functionally rich while introducing the OOP concepts into the code base and improve.

In this project I had 5 main tasks:

• Provide single GUI editor for "relational schema editor" and  "designer".
• Direct export of schema from "designer"
• Introducing a client side storage for the designer, to make users enable to use the designer, even without doing the necessary configurations. And also export those designs in currently available formats.
• Reduce code duplication in schema handling.
• OOPing the designer code.  

As at now, I've successfully covered all these tasks and also did the following modifications:

• Moved HTML codes of the pmd_designer to another file and only kept logic handling.
• Designer exporting was re-factored as plugins.

The last two modifications will help further enhancement of the code and also the modularity and scalability.

To provide more information about making exporting functions as plugins, I've used the same approach which had used in "exporting data". "schema" folder was moved into the plugins folder and "SchemaPlugin.php" class controls the exporting through provided all four types. Export_Relation_Schema.class.php acts as the parent class of the export and all other schema classes are inherited from his class, by which OOP concepts are preserved, while removing code duplications.

GSoC 2014 week 11

As the program coming to its final stages, as planned before, I'm gradually reaching to the completion of my project.

During the past weeks, I've been working on the combined tasks: 

• Reducing huge duplication of code in schema handling
• OOPing the designer code

While doing these two aspects, as part of re-factoring, I separated out all the HTML codes from the pmd_general.php to a new library file pmd_general.lib.php. So all the logics which were handled by the pmd_general.php will remain there and the HTML codes will be retrieved from the pmd_general.lib.php file through function calls.

Also as a part of removing the code duplications in schema exporting, I'm trying to re-factor the existing 4 schema exporting types into 4 different plugins, as done in data export funcationalities in "export.php" file. So that when ever a new schema exporting method is needed, it can be easily plugged into the existing system.  

GSoC 2014 week 10

Under re-formatting and OOPing the code, I did some changes to the pmd_general.php file. Now the functions and HTML codes are separated. HTML codes have moved to another file, and all the logic are in the pmd_general.php file.

Also I'm currently developing designer as a separate component, and will post more details about it in another blog post.

GSoC 2014 week 8 and 9

Over the last two weeks I have done several things (I couldn't put my last week's post because I had to attend to a family matter, so I could work much on the project as planned).

First I completed the 3rd task, which was to enable the user to use designer, even though the designer related tables are not created. For this task, I used browser storage mechanism, this is Indexed DB. So now the user doesn't have to configure the php myadmin to use the designer, instead using a Indexed DB supported browser, user can use the designer similar to all other functions. Even the pdf exporting has been enable for those scenarios.

From the planned tasks,  "reducing huge duplication of code in schema handling" and  "OOP"ing the code are remaining. But as long as these two are going hand-in-hand, I started to do thse two tasks at the same time.

GSoC 2014 week 7

During the previous week, I was working on the task: "enhancing the usability of the designer", by which implementing a client side database to carry out the "designer" funcationalities.

After analyzing all available client side data store mechanisms, I decided to go ahead with Indexed database, as it's much faster than WebSQL and It is the recommended data storage mechanism by W3C.

According to the new work-flow, the "Designer" tab will be always shown. Earlier it was shown only if the "table_coords" and "pdf_pages" tables are available.

Now the system works as follows:
First it checks whether the relevant tables exist in the database.
If not, It will create client side data store and start working with that.

    

GSoC 2014 week 6

First, I was really glad to received the email saying that I got through the mid-term evaluation. I need to thank my mentor Madhura Jayarathne for the guidance provided and all others, supported through the mailing list, to achieve this milestone.

During the mid evaluation period, I did some more improvements in the exporting functionality based on the review comments. Also in the show/hide tables in the designer view.

The major task for this few weeks is to enhance the usability of the designer. That is, to use the designer, users need to do some configurations explicitly, which, most of the time, will not be done by the users, hence these funcationalities will never be used.

So the main goal of this task is to provide a mechanism in such a way that, users will not need to configure anything, but still should be able to use the designer. For that "Client side databases" will be used.

After analyzing currently available technologies:

• Web storage
• Web Sql database
• Indexed database

are the most commonly used. Web storage uses a "key-value" pair method to store objects in the browser. Although it's a simple mechanism, It's performance decreases as the data become large and complex. Web Sql database is a normal "SQL" - relational database, and has good performance even for the large data sets. But because of low agility and being deprecated, users are moving away from that.

On the other hand Indexed database is made up by combining all the strengths of both web-storage and Web Sql databases. So its more powerful than any of the above two. Also its browser compatibility is increasing.

GSoC 2014 week 5

As the project has now come to the mid-term evaluation, I've almost completed my first two tasks, as I planned initially. Still I'm getting some feed-backs for the changes I did, but in overall, I've successfully covered all tasks.

Now with the new designer page, a user can:

• create new pages 
• edit a page
• delete a page
• save changes to a new page or an existing page
• export pages in various formats.

With these changes done, we can remove the existing "Edit or export relational schema" functionality from the phpmyadmin.

GSoC 2014 week 4

During the last week, I did more changes to my first task to make it more user-friendly and functionality-rich.

Following is how the new tool bar of the designer looks like:

"Edit pages" button was removed and added two new buttons, "Open Page" and "Delete Page", which will have the "Edit Page" and "Delete Page" functionalities respectively. Besides these two buttons, one more "New Page" button was introduced, So that the user will not get confused, while trying to create a new pdf page.

For the current task, which is to integrate the exporting functionality of the schema editor into the designer, a new "Export Page" button was introduced.

Similar to the exporting functionality of the schema editor, this new export pages functionality will use the same classes.

GSoC 2014 week 3

The last week was the final week for completing the first task of my project. As I've been describing in my previous posts, "save as" and "edit" options are introduced. Apart from that, functionality of the"save" button has been changed so that the changes will be saved into the "table_coords" table.

in coding perspective, the new functionalities are handled through the "pmd_general.php" file. Following is a screenshot of the code portion which handles all the new added features.

The functionality which handles the saving is changed to save data into the  "table_coords" table. Same functionality is used for the "save changes to existing page" option.

So now, in the designer, "designer_coords" table will not be used, in fact "pdf_pages" and "table_coords". So unlike the previous behavior, the designer will load page wise designs.

Possible TODOs: add option to delete tables from the pdf pages.

So the user has more flexibility over the pdf pages.

I'll put the details of the next task in a seperate blog post soon.

GSoC 2014 week 2

As shown in my last week flow diagram, I've almost completed the first task. The "save as" and "edit pages" functionalities are being introduced, by means of dialog boxes. Following are the screen shots of them:

Save as:

Edit pages:

Changes done in the code:

separate php files will handle the "save as" and "edit pages" functions (save_as_pages.php and edit_pages.php). According to the flow diagram, another file(pmd_page_loader.php) will handle the page loading function.

Now the designer will be loaded with data from "pma__table_coords" instead of "pma__designer_coords". So the system can load different pages upon user selection.

TODO:
do modifications to the "save" function when there are new/edit pages
modify the pmd_general.php file in such a way that, html will be moved to another files and retrieved by function calls.

GSoC 2014 week 1

As mentioned in my last week's post, I've been implementing the mentioned three tasks.

Following is the flow diagram of the new functionalities added to the designer:

As shown in the diagram, I'm trying to generalize functions as much as possible so that, I can re-use them very easily.

Following is how the new interface looks:

"Import/Export coordinates for PDF schema" button is removed, because it will be implemented as a part of the integration.

Adding slight modifications to the previously planned design, the new "save as" and "edit pages" functionalities will not direct user to a new page, instead, dialog boxes will be pop-up.

Following is the "Edit pages" dialog box, which I implemented.

TO DOs for the next week:

• "Save as" functionality is to be implemented.
• page loading functionality is to be implemented.

* I did not commit these changes because still some core functionalities to be implemented and tested.

First week of GSoC 2014 : TODO

Today, the 19th of May 2014, is the official "start coding day" for GSoc 2014. So after spending almost a moth for community bonding, and in spending that time period for analyzing the code, I'm in a good position to start coding.

To start with, according to my plan, I will be working on the task 1:

Prevailing "Designer" and "Edit relational schema" pages share overlapping functionalities. So the intention of the phase 1 is to create one page by combining the features of these two pages. So that there will be no two similar GUI's in the future, instead only the "Designer". With the new designer, a user would additionally be able to:

1. Change the table layout in the designer and save to database's default layout.
2. Load a saved set of coordinates from a page, edit and save them.
3. Perform a "Save as" on edited coordinates to create a new page.

1). When a new user opens the designer, the default table layout will be shown. But if there are existing saved table layouts, then the first layout will be loaded.

2). A new functionality will be introduced into the designer - "edit page", where a user can edit, delete existing pages.

3). Another new functionality will be added - "save as", where the coordinates can be saved to an existing page or a new page.

Following is the new interface for designer:

Following is the page directed by "save as" button:

Following is the page directed by "edit page" button:

Although I've made these mock-ups and started developments, always welcome feed backs.

What my project is about...

Idea:

Being one of the most renowned open source software for MySQL administrator, phpMyAdmin is a widely used tool. It has matured with many new features and improvements for many years, with the contribution of the open source community. But there is always a tendency for issues such as, similar kind of features being implemented, code duplication and eventually degradation of the code quality. The intention of this project is to address these issues under several aspects and improve its quality.

Benefits to the users:

Outcomes of this project will benefit not only the end users but also the contributors.

End users:

Considering the tasks of this project, one GUI for designing and integrated exporting functionalities will make the end user’s life lot easier. 

Contributors:

Removing code duplicates and adhering to OOP concepts will help contributors by enhancing the extendibility, maintainability and eventually readability of the code.

The whole project is categorized under 5 major tasks:

Task 1: Provide single GUI editor for schema

There are two schema editors present in the current system; the ‘Designer’ and the ‘Relational Schema Editor’. However, they have some overlapping functionalities. So the idea of this task is to bring those two editors together and have a more improved version alone.  

Task 2: Direct export of schema from editor

The idea is to add the schema exporting functionality to the new ‘Designer’ page, which will be created from the first task.

Task 3: Usability of designer

The intention here is to allow user to use the ‘Designer’ without configuring the phpMyAdmin specific tables.

Task 4: Reduce huge duplication of code in schema handling

This task involves two main sections:

• Reduce/remove code duplications in schema handling classes:
• Proper implementation of OOP concepts:

Task 5: OOPing Designer code

PHP files that are responsible for handling the ‘Designer’ (pma_ prefixed files) contain mostly functional code. I will work on porting these codes to an Object Oriented class hierarchy that would allow us to use the benefits of OOP.

My project will be mentored by Madhura Jayarathne and my github fork is https://github.com/kb-yashodha/phpmyadmin

Celebrating the Summer with PHPMyadmin

It was one of the most exciting moments in my life, to see that I've got an email - a much anticipated one - from google, with the title: "Welcome to Google Summer of Code 2014". So in the GSOC 14, I'll be working on a project with one of the leading open source software for MySQL administrator - "PHPMyadmin", and the project title is "Refactoring: Design/Schema integration". I want to thank PHPMyadmin for selecting my proposal for this project and Google for giving this great opportunity to participate in such a prominent event.

During the upcoming weeks I will use this blog as a means of conveying the progress of the project to everyone. This will include a full description about the project, what are the expected outcomes, what are my plans/goals and my achievements,