Monday, August 18, 2014

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.  


Monday, August 11, 2014

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.


Monday, August 4, 2014

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.