[ppa-dev] feat. req. #1362581: solutions and thoughts on ppa code structure

[ioguix <io...@fr...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

As you know I am currently working on the feature request #1362581 about
jumping to table properties after insert.

There is many way to achieve this feature, each with pros & cons. I will
try to explain them quickly before concmluding on my thought.

1/ redirecting to tblproperties (patch implemented):
  just use header('Location: tblproperties.php?...'); to redirect on the
wanted page.
  pros:
    - really simple to implement ;
    - not intrusive.
  cons:
    - redirecting cost another request from the user to the server. It
could become anoying if connexion has a big latency and/or ridiculous
bitrate.

2/ moving InserRow() function from tables.php to tblproperties.php
(patch implemented):
  This way, as function is called from tblproperties.php, we just have
to call the doDefault function to print the properties page.
  pros:
    - really simple to implement ;
    - almost no code rewriting, just moving.
  cons:
    - There's a little disapointing thing here. Where should be tables
related functions ? if moving insertRow, we should move selectRow and
emptyTable as well. But moving emptyTable will lead to a similar problem
: where should we go when emptying multiple tables ? Going to tables
list mean using tables.php...
    - some refactoring. We should pay attention that other pages are
pointing on tblproperties.php.

3/ including tblproperties in tables.php to call its properties page
function (patch implemented):
  It needs to rename doDefault, doTree and doDrop function.
  pros:
    - simple to implement ;
  cons:
    - really intrusive ;
    - doTree is a standard function used in many files to creates tree's
branches in the browser ;
    - need to add a condition using the global $_no_output in
tblproperties to test if we should execute the classical switch block on
$action.

4/ merging tables.php and tblproperties.php in tables.php :
  ...and drop tblproperties.php file
  pros :
    - every table's related function in one file, simple, easy.
  cons :
    - a very big file !
    - some refactoring. We should pay attention that other pages are
pointing on tables.php and not tblproperties.php.

5/ using a 3rd file with shared functions between tblproperties.php and
tables.php
  pros: clean.
  cons: code splitted between 3 files...

So far, my favorite method is 2/. but actually, i don't feel confortable
with any of these solutions.

Conclusions :
This feature brings out a code structure problem in ppa. The current
code architecture force to repeat some parts of the code (compare
doSelectRows from views.php and tables.php as instance) and using tricky
code to achieve some features like this one.

I don't think this is the best time to speak about that. I know each of
us havn't so many time and the moment is not really ideal as we should
release in few weeks or months. I don't want to start a revolution in
the code, but there's definitly something to do here in future to ensure
a clean, stable and extendable code.

Opinions ? Brainstorming ?

Cheers,
- --
Guillaume `ioguix` de Rorthais
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGNfb+xWGfaAgowiIRAgVFAJ9j6aKTNOhH00MEVSCzAoxDrA291wCfe4PE
Ql7UzCm6H58Kx4Y0ntLGLe8=
=A1zD
-----END PGP SIGNATURE-----