[Phpmyadmin-devel] Inconsistent format strings
Hi for several times I wondered why we use so many different ways to create format strings, let's take three examples: $cfg['DefaultQueryTable'] = 'SELECT * FROM %t WHERE 1'; where * %d will be replaced by the database name. * %t will be replaced by the table name. * %f will be replaced by a list of field names. $cfg['Export']['file_template_table'] = '__TABLE__'; where __TABLE__, __DB__ and __SERVER__ are used $cfg['TitleTable'] = '@HTTP_HOST@ / @VSERVER@ / @DATABASE@ / @TABLE@ | @PHPMYADMIN@'; where @HTTP_HOST@, @SERVER@, @VERBOSE@, @VSERVER@, @DATABASE@, @TABLE@ and @PHPMYADMIN@ can be used How about making use just single way to do this and create common function which will do the formatting? I'm somehow more inclined to use %x, however @SOMETHING@ is more self documenting, while __SOMETHING__ looks just too long to me. I know this would be incompatible change, but it looks like we're making enough other big changes for next major version so that it won't be that big issue. -- Michal Čihař | http://cihar.com | http://blog.cihar.com
2010/7/20 Michal Čihař <michal@cihar.com>:
Hi
for several times I wondered why we use so many different ways to create format strings, let's take three examples:
$cfg['DefaultQueryTable'] = 'SELECT * FROM %t WHERE 1';
where * %d will be replaced by the database name. * %t will be replaced by the table name. * %f will be replaced by a list of field names.
$cfg['Export']['file_template_table'] = '__TABLE__';
where __TABLE__, __DB__ and __SERVER__ are used
$cfg['TitleTable'] = '@HTTP_HOST@ / @VSERVER@ / @DATABASE@ / @TABLE@ | @PHPMYADMIN@';
where @HTTP_HOST@, @SERVER@, @VERBOSE@, @VSERVER@, @DATABASE@, @TABLE@ and @PHPMYADMIN@ can be used
How about making use just single way to do this and create common function which will do the formatting?
I'm somehow more inclined to use %x, however @SOMETHING@ is more self documenting, while __SOMETHING__ looks just too long to me.
I know this would be incompatible change, but it looks like we're making enough other big changes for next major version so that it won't be that big issue.
Looks good to me, +1 for @VARIABLE@ syntax for reasons you mentioned. Maybe a list of incompatible changes (a short checklist) would help people migrate their settings to next major version. -- Piotr Przybylski
Hi Dne Tue, 20 Jul 2010 16:55:54 +0200 Piotr Przybylski <piotr.prz@gmail.com> napsal(a):
Looks good to me, +1 for @VARIABLE@ syntax for reasons you mentioned.
Maybe a list of incompatible changes (a short checklist) would help people migrate their settings to next major version.
For now I've changed it for export and title to use common function, which does handle both __VAR__ and @VAR@ syntax, but the documentation mentions only @VAR@. For DefaultQueryTable and DefaultQueryDatabase is really no way to make it backward compatible if we want to keep option to use strftime formats as well (like in other places). -- Michal Čihař | http://cihar.com | http://blog.cihar.com
Michal Čihař a écrit :
Hi
for several times I wondered why we use so many different ways to create format strings, let's take three examples:
$cfg['DefaultQueryTable'] = 'SELECT * FROM %t WHERE 1';
where * %d will be replaced by the database name. * %t will be replaced by the table name. * %f will be replaced by a list of field names.
$cfg['Export']['file_template_table'] = '__TABLE__';
where __TABLE__, __DB__ and __SERVER__ are used
$cfg['TitleTable'] = '@HTTP_HOST@ / @VSERVER@ / @DATABASE@ / @TABLE@ | @PHPMYADMIN@';
where @HTTP_HOST@, @SERVER@, @VERBOSE@, @VSERVER@, @DATABASE@, @TABLE@ and @PHPMYADMIN@ can be used
How about making use just single way to do this and create common function which will do the formatting?
And how about dropping these features? Sometimes when I look at the code I see configurable things that I never felt the need to change. But maybe I'm too radical in suggesting to drop them :) -- Marc Delisle http://infomarc.info
Hi Dne Wed, 21 Jul 2010 07:54:59 -0400 Marc Delisle <marc@infomarc.info> napsal(a):
And how about dropping these features? Sometimes when I look at the code I see configurable things that I never felt the need to change. But maybe I'm too radical in suggesting to drop them :)
Well most of these options were introduced on user request (the configurable title or filename are definitely based on feature requests). I have no idea how many people do actually use it though :-). -- Michal Čihař | http://cihar.com | http://blog.cihar.com
Michal Čihař a écrit :
Hi
Dne Wed, 21 Jul 2010 07:54:59 -0400 Marc Delisle <marc@infomarc.info> napsal(a):
And how about dropping these features? Sometimes when I look at the code I see configurable things that I never felt the need to change. But maybe I'm too radical in suggesting to drop them :)
Well most of these options were introduced on user request (the configurable title or filename are definitely based on feature requests). I have no idea how many people do actually use it though :-).
I know and in a sense it might be too late to remove these features, so it's a good idea to reduce the number of format strings. -- Marc Delisle http://infomarc.info
Hi Dne Wed, 21 Jul 2010 08:09:36 -0400 Marc Delisle <marc@infomarc.info> napsal(a):
Michal Čihař a écrit :
Hi
Dne Wed, 21 Jul 2010 07:54:59 -0400 Marc Delisle <marc@infomarc.info> napsal(a):
And how about dropping these features? Sometimes when I look at the code I see configurable things that I never felt the need to change. But maybe I'm too radical in suggesting to drop them :)
Well most of these options were introduced on user request (the configurable title or filename are definitely based on feature requests). I have no idea how many people do actually use it though :-).
I know and in a sense it might be too late to remove these features, so it's a good idea to reduce the number of format strings.
Okay, everything now uses @VARIABLE@ syntax with single function PMA_expandUserString to do the expansion. -- Michal Čihař | http://cihar.com | http://blog.cihar.com
participants (3)
-
Marc Delisle -
Michal Čihař -
Piotr Przybylski