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.
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.
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ř 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 :)
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ř 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.
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.
-
Marc Delisle -
Michal Čihař -
Piotr Przybylski