May 2002 - Developers - lists.phpmyadmin.net

[Phpmyadmin-devel] Re: fpdf directory
by Loïc 25 May '02

25 May '02

Hi List! I think we just need to use the "-P" option ("prune empty directories") in the cvs co command line or something like that. 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

1 0

Re: [Phpmyadmin-devel] fpdf directory
by Loïc 25 May '02

25 May '02

Hi List! I've just moved the fpdf library as Alexander suggested since I fully agree his opinion ;) >The next thing is that this directory also exists in the 2.2.7 branch Once a directory exist in the CVS tree we can't remove it :( 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

2 1

[Phpmyadmin-devel] Re: Navigation frame for splitted tbl_properties / db_details
by Loïc 25 May '02

25 May '02

>I've been working on this right-top frame idea a little, but I >don't think it's a good idea anymore. OK, I agree you opinion Alexander. But we still have to do some work in order to have to "top menu" displayed whatever is the script used. 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

1 0

[Phpmyadmin-devel] fpdf directory
by Alexander M. Turek 24 May '02

24 May '02

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

1 0

[Phpmyadmin-devel] Navigation frame for splitted tbl_properties / db_details
by Rabus 24 May '02

24 May '02

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

1 0

[Phpmyadmin-devel] End Copyright
by info 23 May '02

23 May '02

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.

1 0

AW: AW: AW: AW: [Phpmyadmin-devel] Re: Apache 2.0.* and PHP 4.2.?
by Beck, Mike 22 May '02

22 May '02

> > } > 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

1 0

Re: AW: AW: AW: [Phpmyadmin-devel] Re: Apache 2.0.* and PHP 4.2.?
by Robin Johnson 22 May '02

22 May '02

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

1 0

Re: AW: AW: [Phpmyadmin-devel] Re: Apache 2.0.* and PHP 4.2.?
by Robin Johnson 22 May '02

22 May '02

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

1 0

Re: AW: [Phpmyadmin-devel] Re: Apache 2.0.* and PHP 4.2.?
by Robin Johnson 22 May '02

22 May '02

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

1 0