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.