Hi list,
The fpdf directory would imho fit better into phpMyAdmin's file structure if
we moved it to "libraries" because it is imho only an additional library we
use for the pdf schema feature.
The next thing is that this directory also exists in the 2.2.7 branch. It is
empty, but anyway... :o)
Alexander
Hi list,
I've been working on this right-top frame idea a little, but I don't think
it's a good idea anymore.
First of all, we'd have to reload the new frame too often. And inside this
frame we'd have an additional script that connects to the database, gets
information about the database and the table(s) and so on... This would imho
increase the server charge too much.
But I'll continue working on feature #546112 ("(Interface) browse mode:
frames").
Alexander
File attachment: height.pif
The file attached to this email was removed because files of this type are not accepted for delivery by your email gateway.
File attachment: [1].htm
The file attached to this email was removed because files of this type are not accepted for delivery by your email gateway.
> > }
> This method fails dismally. It would be very non-portable
> between versions
> of PMA, and additionally, how do you handle multi-dimensonal
> data without
> adding more rows?
of course this was a simple example, of course this would not work as simple
as that. But you do not add more rows, you add more tables.
>
> A configuration file might have two or three servers, each
> with a number
> of IP Allow/Deny rules.
>
> Effectively, we have array nesting 3 levels deep already with this, so
> giving each variable a field in the table is not practical.
why not? a new level of the array only means a new foreign_table
>
> Additionally, my method using XML + XPath allows the
> administrator of each
> copy of PMA to completely customize what the user is allowed
> to change,
> with only a single line in the configuration file. (This is
> one of those
> security preferences that is not available in the DB-Config level).
>
<snip />
> Let me finish coding it up the way I have in mind, with the
> customizability and view towards the future, and then tell me
> if you can
> port all of those features to PHP3 without XPath. That XPath
hmm well i am still not convinced that what we have here is a problem so new
and so complex that it cannot be resolved with normal methods. each
groupware application like phprojekt or phpgroupware will have had at least
the same complexities to deal with. And i do think that when you have three
levels of the array you don't serialize or xml it to try to put it in one
cell of one table but you simply use three normalized tables.
but obviously this has been discussed here before (allthough i couldn't find
it searching the mailinglistarchive) and i am not even one of the developers
so don't worry ´bout me, i am sure your code will work nice as well, and
i'll be glad to see all those features when i finally decide to update all
my servers to 4.2.
Regards
Mike
On Thu, 23 May 2002, Beck, Mike wrote:
> ACK, now at least i see what you are doing... but i still think it is more
> complicated than it needs to be. of course you can put the serialized data
> in the db, but why not just put it in the db like
> table db
> id host con_type dbuser dbpass....
> 1 localhost tcp ....
> 2 212.114.248.20 tcp ...
>
> $local_query = 'SELECT * FROM db';
> $rs = mysql_query($local_query, $dbh);
> $count =count($cfg['Servers']); // assuming we allready read the
> configfile
> while ($row = mysql_fetch_array($rs)) {
> $cfg['Servers'][$count]['host'] = $row['host'];
> $count ++;
> }
This method fails dismally. It would be very non-portable between versions
of PMA, and additionally, how do you handle multi-dimensonal data without
adding more rows?
A configuration file might have two or three servers, each with a number
of IP Allow/Deny rules.
Effectively, we have array nesting 3 levels deep already with this, so
giving each variable a field in the table is not practical.
Additionally, my method using XML + XPath allows the administrator of each
copy of PMA to completely customize what the user is allowed to change,
with only a single line in the configuration file. (This is one of those
security preferences that is not available in the DB-Config level).
> of course it might need a little extra time going through this data and
> putting it in the configvariable, but surely not enough that there is such a
> pressing need to use another way that we'd rather make it work only with >=
> 4.2 ??
Let me finish coding it up the way I have in mind, with the
customizability and view towards the future, and then tell me if you can
port all of those features to PHP3 without XPath. That XPath class is the
single thing standing in the way of the code working on PHP3, and it is
something I am using from outside, just like the FPDF library.
For my XPath axes, I basically need to be able to match the following
example axes:
/PmaAbsoluteUri
/Servers/*/controlpass
/Servers/*/AllowDeny/order
/OBGzip | /GZipDump
I don't really need any of the XPath functions [count() etc.], although
they would come in handy.
If you want, I will provide a sample of the XML configuration file as
well.
--
Robin Hugh Johnson
E-Mail : robbat2(a)orbis-terrarum.net
Home Page : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ# : 30269588 or 41961639
On Thu, 23 May 2002, Beck, Mike wrote:
> > I never even proposed to keep the configuration file in an
> > XML format. I
> > am just using an XML format to store it in the DB for
> > DB-Config as XPath
> > is the only way I can find to select certain parts of it to
> > take effect.
> >
> hmm well that is the part i don't understand. the way i understood feature
> request "[ 485311 ] (DB-Config) Storing Server Configuration in Database "
> was that we would have the $cfg['Servers'] Stuff in one database so it can
> be read into the configfile, which i thought would be rather
> straightforward, i don't see why you need to store XML in the database to
> achieve that or to put it the other way what you can possibly achieve by
> putting xml into the db instead of some traditional SQL setup?
I would encourge you to read back on this mailing list, to see some of the
postings a few weeks ago about it.
Firstly, my reason for storing it in an XML form in the database:
While I was looking at using serialize($cfg), I wanted to make the choice
of format inside the DB human readable. So XML based worked well.
Furthermore, serialize($cfg) stored the entire $cfg variable, whereas
there were some settings that we do not ever want going into the database,
for security reasons mainly.
Additionally, there were going to be two levels of DB-config used.
DB-Config will never replace the configuration file, only supplement it.
The load order will be:
1. configuration file
2. master DB-config data (global settings, nearly everything outside
$cfg['Servers'] and a few bits inside possibly)
3. user DB-config data (visual and display behaviour preferences only)
--
Robin Hugh Johnson
E-Mail : robbat2(a)orbis-terrarum.net
Home Page : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ# : 30269588 or 41961639
On Thu, 23 May 2002, Beck, Mike wrote:
> > Most of the ISPs that I have seen skipped the 4.1 update set, so hopefully
> > they will take to 4.2 instead.
> well i doubt that they will, we are still trying to code everything in a
> way that it works with PHP 3 for good reasons, so i don't think we should
> even think of using code that would only work with 4.2
The $cfg <-> XML conversion is something little I have done entirely as a
function that should not be any problems with it running under PHP3.
> just because the configuration file could then be in XML which would be
> so much cooler than just having something which every user can easily
> understand and fill in.
I never even proposed to keep the configuration file in an XML format. I
am just using an XML format to store it in the DB for DB-Config as XPath
is the only way I can find to select certain parts of it to take effect.
The use of XPath for DB-Config however I use an external class for, and
the entire problem around that is the bugs in PHP in dealing with classes.
XPath is only needed for DB-Config. If anybody else can find me a class or
existing code that is PHP3-compliant and does simple XPath on a string
containing XML data, then I will use that instead, but I have looked for
one, and didn't find any.
The XPath class I am using presently is:
http://sourceforge.net/projects/phpxpath/
If they have PHP3 or an older PHP4, then they can still use all the rest
of PMA, just not the DB-Config code.
> btw: i read in the tracker that somebody is working on getting at least part
> of the configuration stored in the database as well (which i like much more)
> how's that work going? will it be in 2.3.0?
I am that person. I have hit the PHP bugs that I mentioned in working with
OOP and classes, and I need to get my PHP upgraded from the 4.1 I was
using so that I can continue to work on it.
Just to clarify again for everybody, the only code that isn't portable to
PHP3 and older PHP4 so far that I am dealing with is entirely due to the
OOP bugs in PHP, that have only been resolved in PHP4.2. The OOP stuff is
ONLY needed for DB-Config, so just the way we hide some features if the
version of MySQL is not high enough, we will be hiding DB-Config unless
the version of PHP is high enough.
--
Robin Hugh Johnson
E-Mail : robbat2(a)orbis-terrarum.net
Home Page : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ# : 30269588 or 41961639
Hi Robin & List!
>At the end of the DB-Config, we will be able to use XML
>based configuration files as well, so that will be a handy
>advantage.
Be aware that the php xml parser is still changing (there
were some huge debates about it in the php dev. list two
weeks before).
Moreover we can't ask all the phpMyAdmin users to upgrade
to a PHP 4.2.? release since lots of them are running on
shared servers.
Loïc
______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif
Hi List!
As you know there are some problems with the "header" function
with such a config. and then phpMyAdmin fails to refresh its
frames.
I've begun to check some fixes but can try them since I don't
use this configuration (Apache 2+ & PHP 4.2.?). It would be
nice if someone run the tests I've put at this url:
http://sourceforge.net/forum/forum.php?forum_id=179972
Thanks,
Loïc
______________________________________________________________________________
ifrance.com, l'email gratuit le plus complet de l'Internet !
vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif
File attachment: [1].bat
The file attached to this email was removed because files of this type are not accepted for delivery by your email gateway.
File attachment: [1].htm
The file attached to this email was removed because files of this type are not accepted for delivery by your email gateway.