phpweather-devel Mailing List for PHP Weather (Page 13)
Brought to you by:
iridium
You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(4) |
Dec
(7) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(2) |
Feb
(52) |
Mar
(79) |
Apr
(9) |
May
(28) |
Jun
(17) |
Jul
(25) |
Aug
(48) |
Sep
(18) |
Oct
(6) |
Nov
|
Dec
(8) |
2003 |
Jan
(26) |
Feb
(10) |
Mar
(2) |
Apr
(21) |
May
(23) |
Jun
(15) |
Jul
(15) |
Aug
(8) |
Sep
(16) |
Oct
(3) |
Nov
(4) |
Dec
|
2004 |
Jan
(35) |
Feb
(35) |
Mar
(9) |
Apr
(6) |
May
(1) |
Jun
(3) |
Jul
(3) |
Aug
(6) |
Sep
|
Oct
|
Nov
|
Dec
|
2005 |
Jan
(4) |
Feb
(6) |
Mar
(6) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
(2) |
Nov
|
Dec
|
2006 |
Jan
|
Feb
(5) |
Mar
(7) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2007 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
From: Chris S. <cs...@ya...> - 2002-09-01 16:18:13
|
Upon completing the initial config, when I click the download config button I'm sent to this url which obviously doesn't exist: ------------ http://localhost/phpweather-2.0.0/config/<br%20/><b>Notice</b>:%20%20Undefined%20variable:%20%20PHP_SELF%20in%20<b>/usr/local/apache/htdocs/weather/config/make_config.php</b>%20on%20line%20<b>404</b><br%20/>? ------------ then when I try to reload the config page, I get these errors: ------------ Notice: Undefined variable: options in /usr/local/apache/htdocs/weather/config/make_config.php on line 287 Warning: First argument to array_keys() should be an array in /usr/local/apache/htdocs/weather/config/make_config.php on line 287 Warning: Invalid argument supplied for foreach() in /usr/local/apache/htdocs/weather/config/make_config.php on line 288 Fatal error: Call to a member function on a non-object in /usr/local/apache/htdocs/weather/config/pw_optiongroup.php on line 117 ------------ and I continue to get that error until I delete the session or it times out. Once the session is gone, the cycle begins from scratch. __________________________________________________ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com |
From: Martin G. <gim...@gi...> - 2002-08-31 10:05:51
|
Ondrej Jombik <ne...@po...> writes: > [...] > > I hope, that now you understand what I was talking about. If > not, no matters. It is only precision issue, not real problem. Icao > will probably never contains any from problematic characters and if > so, everything will probably works well. Thanks for the explaination - I now see the problem. I agree that we shouldn't addslashes() in set_icao() but instead delay it to the generation of queries. I don't think we should worry about stripping slashes from the ICAO in get_location() - if someone has used a ICAO with things like quotes in it, then they deserve to get slashes back :-) But as you say, this will probably never happen. -- Martin Geisler My GnuPG Key: 0xF7F6B57B See http://gimpster.com/ and http://phpweather.net/ for: PHP Weather => Shows the current weather on your webpage and PHP Shell => A telnet-connection (almost :-) in a PHP page. |
From: Ondrej J. <ne...@po...> - 2002-08-30 23:57:20
|
Maxim, 01:28:09 31. august 2002 (sobota) Greetings. > > I will be for this. Ugly stripslashes() hack when using icao as > > substitution for human readable station name could be than removed. > Where is this code you're talking about? I'm afraid that you've got me > confused. The only code that uses stripslashes() is the code in > make_config.php. I'm afraid, that we do not completely understand ourself, so I will try to explain the issue. All I was talking about is related to line 78 in data_retrieval.php file. It looks like the following one: $new_icao = addslashes($new_icao); Icao is stored in internal object structures addslashed. No matter that it will probably never contain quoting or other problematic character. In fact, when compiling query you don't need to call addslashes() on $icao, because it is already addslashed. My suggestion was to store icao as-is in data_retrieval class and call appropriate addslashes() on $icao during query compiling. Another issue is, that in old code lookup_icao() returns either "Location, Country" or simply "$icao" when "Location, Country" was not found for particular $icao in database. In that case, we need to do stripslashes() on $icao, because it stored addslashed in internal data structures. I hope, that now you understand what I was talking about. If not, no matters. It is only precision issue, not real problem. Icao will probably never contains any from problematic characters and if so, everything will probably works well. =Nepto= ____________________________________________________________________________ "Be conservative in what you do, be liberal in what you accept from others." (RFC 793: Transmission control protocol; chapter 2.10. Robustness Principle) |
From: Max H. <ma...@fl...> - 2002-08-30 14:47:33
|
> > > So conclusion: addslasles on strings inserted into DB is > > > *always* good idea. Problem may occur only if string is addslashed > > > twice or more times. > > Yes, exactly. I think the easiest way to handle this is to let the > > methods in the db backends be the only methods to add slashes. All > > other methods should not have to care about this. > > So also icao should be stored as-is without starting addslashes() > call used? I will be for this. Ugly stripslashes() hack when using icao as > substitution for human readable station name could be than removed. But > IMHO this should be done after comming release. It is not majority problem. I'm not sure what's being suggested here - is the suggestion that pw_db_mysql:query should perform the escaping? That's silly. addslashes() should be run at the point that the query SQL is generated... Yay for a release of 2.0.0 though! Max |
From: Martin G. <gim...@gi...> - 2002-08-30 13:28:07
|
Ondrej Jombik <ne...@po...> writes: >> Yes, exactly. I think the easiest way to handle this is to let the >> methods in the db backends be the only methods to add slashes. All >> other methods should not have to care about this. > > So also icao should be stored as-is without starting > addslashes() call used? Do you mean when we store the ICAO and station name when initializing the databases? > I will be for this. Ugly stripslashes() hack when using icao as > substitution for human readable station name could be than removed. Where is this code you're talking about? I'm afraid that you've got me confused. The only code that uses stripslashes() is the code in make_config.php. >> Does this mean that we're ready to release the code? > > From my point of view yes. That was all things I had actual > for phpWeather. Others after release. But maybe someone other has > also something... In that case - they're too late. I've just made the release on SourceForge. I'll go and make an announcement on Freshmeat now. > I will try to find some time for submiting things > (comments/bugs) on SF, just for remembering them. Good idea! -- Martin Geisler My GnuPG Key: 0xF7F6B57B See http://gimpster.com/ and http://phpweather.net/ for: PHP Weather => Shows the current weather on your webpage and PHP Shell => A telnet-connection (almost :-) in a PHP page. |
From: Ondrej J. <ne...@po...> - 2002-08-30 01:19:41
|
> Today I implemented things I was talking about yesterday. As it was > written, I wanted them and I'm usign them on my website (I will pass URL > tomorrow evening). So here it is: http://nepto.sk/specials/weather/ Navigation used there is now also included in phpWeather index.php demo page. =Nepto= ____________________________________________________________________________ Ondrej 'Nepto' Jombik, Visit Atlantis talker now! http://atlantis.sk/ |
From: Ondrej J. <ne...@po...> - 2002-08-30 01:19:18
|
Maxim, 02:14:38 30. august 2002 (piatok) Greetings. > > So conclusion: addslasles on strings inserted into DB is > > *always* good idea. Problem may occur only if string is addslashed > > twice or more times. > Yes, exactly. I think the easiest way to handle this is to let the > methods in the db backends be the only methods to add slashes. All > other methods should not have to care about this. So also icao should be stored as-is without starting addslashes() call used? I will be for this. Ugly stripslashes() hack when using icao as substitution for human readable station name could be than removed. But IMHO this should be done after comming release. It is not majority problem. > > I tried it for MySQL and PostgreSQL and it worked well. I also tried > > this "new" version of phpWeather on my site and again without > > problems (I only change get_country() for get_country_code() call). > Good - that should be the only change necessary. > Does this mean that we're ready to release the code? From my point of view yes. That was all things I had actual for phpWeather. Others after release. But maybe someone other has also something... I will try to find some time for submiting things (comments/bugs) on SF, just for remembering them. =Nepto= ____________________________________________________________________________ "Be conservative in what you do, be liberal in what you accept from others." (RFC 793: Transmission control protocol; chapter 2.10. Robustness Principle) |
From: Martin G. <gim...@gi...> - 2002-08-29 10:51:55
|
Ondrej Jombik <ne...@po...> writes: >> The data in those databases comes from stations.csv and should be >> safe. > > I was not doing anything on data retrieved from database. They > are always safe, IMHO. Yes, my mistake. >> If the data comes from the METARs database, then we have to >> stripslashes() because slashes might have been added when the data >> was inserted. Ups - when we add slashes to a string and insert it in the database, then we wont see the slashes again when we extract it from the database again... So the above makes no sence. > So conclusion: addslasles on strings inserted into DB is > *always* good idea. Problem may occur only if string is addslashed > twice or more times. Yes, exactly. I think the easiest way to handle this is to let the methods in the db backends be the only methods to add slashes. All other methods should not have to care about this. > I checkouted fresh copy of phpWeather, because there was lot > of merging problems. I didn't apply your patches directly (unmodified) so that's why you got merging problems. > I tried it for MySQL and PostgreSQL and it worked well. I also tried > this "new" version of phpWeather on my site and again without > problems (I only change get_country() for get_country_code() call). Good - that should be the only change necessary. Does this mean that we're ready to release the code? -- Martin Geisler My GnuPG Key: 0xF7F6B57B See http://gimpster.com/ and http://phpweather.net/ for: PHP Weather => Shows the current weather on your webpage and PHP Shell => A telnet-connection (almost :-) in a PHP page. |
From: Martin G. <gim...@gi...> - 2002-08-29 10:45:32
|
Ondrej Jombik <ne...@po...> writes: >> > and the db/files files were updated immediately afterward. I'm >> > assuming that you loaded your mysql up before that? >> If so, then the fix is simple: load /config/make_db.php and press the >> 'Create or Recreate Tables' button. It will parse stations.csv and >> recreate the tables using the current configuration. > > It worked, thanks. Anyway, it deletes all my metars in metars > table (than I recover it from backup). Maybe we could consider also > pure stations update functionality in phpWeather configuration > scripts as a thing of further development. Perhaps - but I've always though of the METARs table as a cache, something that could be thrown away. But we could make the create_tables methods more sophisticated, no problem... -- Martin Geisler My GnuPG Key: 0xF7F6B57B See http://gimpster.com/ and http://phpweather.net/ for: PHP Weather => Shows the current weather on your webpage and PHP Shell => A telnet-connection (almost :-) in a PHP page. |
From: Ondrej J. <ne...@po...> - 2002-08-28 23:14:29
|
> > and the db/files files were updated immediately afterward. I'm > > assuming that you loaded your mysql up before that? > If so, then the fix is simple: load /config/make_db.php and press the > 'Create or Recreate Tables' button. It will parse stations.csv and > recreate the tables using the current configuration. It worked, thanks. Anyway, it deletes all my metars in metars table (than I recover it from backup). Maybe we could consider also pure stations update functionality in phpWeather configuration scripts as a thing of further development. =Nepto= ____________________________________________________________________________ Ondrej 'Nepto' Jombik, Perl CGI developer #!/usr/bin/perl -w |
From: Ondrej J. <ne...@po...> - 2002-08-28 23:13:43
|
Maxim, 00:39:03 29. august 2002 (stvrtok) Greetings. > 2) We're returning something from the database. If it comes from the > stations and countries databases, then we don't need to > stripslashes(). The data in those databases comes from > stations.csv and should be safe. I was not doing anything on data retrieved from database. They are always safe, IMHO. > If the data comes from the METARs database, then we have to > stripslashes() because slashes might have been added when the > data was inserted. I misunderstand this, but my ideas are based on the following fact: every string that will be inserted into database should be addslashed before insert, because it could contain quoting character(s). Than will query suceed and string will not contains these slashes which was added by addslashes() call. If string is "safe" and it is not possible that it will contain quoting characters, backslash or nul (\0) character, that it could be addslashed too. It will remains unchanged. So conclusion: addslasles on strings inserted into DB is *always* good idea. Problem may occur only if string is addslashed twice or more times. > >> Apart from that, I'll probably commit them tomorrow (or to be > >> correct: later today, it's getting late... :-) I'm sure that I can > >> patch the null and dba database backends to handle the lookup for > >> country code. > I've just commited the patches along with updated pw_db_null and > pw_db_dba classes. I've tested all four backends, but it would be nice > to have someone double check it on another system. I checkouted fresh copy of phpWeather, because there was lot of merging problems. I tried it for MySQL and PostgreSQL and it worked well. I also tried this "new" version of phpWeather on my site and again without problems (I only change get_country() for get_country_code() call). > > Without get_country() method in pw_db_dba.php it will not works. > > That's fact. > Yes. I've renamed the method to get_country_code() because we now also > have a get_name() and get_country() that returns the name of a station and > the name of the country. Is this OK? Yes, absolutely. I see that amount of queries was integrated into one and cached data are stored in $icao_data now. =Nepto= ____________________________________________________________________________ Ondrej 'Nepto' Jombik, Open Source software developer, http://www.platon.sk/ |
From: Martin G. <gim...@gi...> - 2002-08-28 10:31:42
|
Ondrej Jombik <ne...@po...> writes: Hi Ondrej and others, >> If you plan to continue in this pace, then why don't get yourself a >> CVS account? I can add nepto as a developer if you're interested... > > Yes, that's not bad idea. It should make 2.x development > slight flexible and faster. So I'm interested. Thanks. Great - I've added you to the project. > ... I glace at queries and see that I need to add addsleshes($icao) > into almost every query. I've left most of the addslashes in the code, but I also think that some of them are unnecessary. We have two cases: 1) We're looking something up in the database. If the data can come directly from the user, we need to use addslashes(). 2) We're returning something from the database. If it comes from the stations and countries databases, then we don't need to stripslashes(). The data in those databases comes from stations.csv and should be safe. If the data comes from the METARs database, then we have to stripslashes() because slashes might have been added when the data was inserted. > I must admin that finally it was unneccessary. Sorry for that, > but I think that buinding queries with sprintf() gets more > readability. I like this way. I see - it actually get's more readable when you use sprintf() on a long SQL query. >> Apart from that, I'll probably commit them tomorrow (or to be >> correct: later today, it's getting late... :-) I'm sure that I can >> patch the null and dba database backends to handle the lookup for >> country code. I've just commited the patches along with updated pw_db_null and pw_db_dba classes. I've tested all four backends, but it would be nice to have someone double check it on another system. > Thanks. I was affraid that I will study DBA interface. The DBA databases are just like an array on disk: you can lookup a value by a key and that's it. So when I have to store data about ICAOs I do it by combining the name, country, and country code and then the whole thing using the ICAO as a key. The same applies to the null database - both backends use two constants (PW_FIELD_SEPERATOR and PW_FIELD_REPLACEMENT) to seperate the fields. > Without get_country() method in pw_db_dba.php it will not works. > That's fact. Yes. I've renamed the method to get_country_code() because we now also have a get_name() and get_country() that returns the name of a station and the name of the country. Is this OK? -- Martin Geisler My GnuPG Key: 0xF7F6B57B See http://gimpster.com/ and http://phpweather.net/ for: PHP Weather => Shows the current weather on your webpage and PHP Shell => A telnet-connection (almost :-) in a PHP page. |
From: Ondrej J. <ne...@po...> - 2002-08-28 00:11:26
|
Maxim, 02:09:20 28. august 2002 (streda) Greetings. > If you plan to continue in this pace, then why don't get yourself a > CVS account? I can add nepto as a developer if you're interested... Yes, that's not bad idea. It should make 2.x development slight flexible and faster. So I'm interested. Thanks. > > This e-mail contains three problems described, with solution > > written. Patches are also included. > I've looked at the patches and I like them - especially the KISS > principle :-) But why have you rewritten all the SQL statements to use > sprintf() to embed the variables instead of using either "foo $var > bar" or 'foo ' . $var . ' bar'? I have answer for this. When I sterted with implementation of described things, I didn't know that $icao is already escaped (addslashed). So I glace at queries and see that I need to add addsleshes($icao) into almost every query. But than I said, why not to rewrite all of them to be more readable? I must admin that finally it was unneccessary. Sorry for that, but I think that buinding queries with sprintf() gets more readability. I like this way. > Apart from that, I'll probably commit them tomorrow (or to be correct: > later today, it's getting late... :-) I'm sure that I can patch the > null and dba database backends to handle the lookup for country code. Thanks. I was affraid that I will study DBA interface. Without get_country() method in pw_db_dba.php it will not works. That's fact. Regards, =Nepto= ____________________________________________________________________________ Ondrej 'Nepto' Jombik, Visit Atlantis talker now! http://atlantis.sk/ |
From: Martin G. <gim...@gi...> - 2002-08-27 23:33:42
|
Ondrej Jombik <ne...@po...> writes: > Maxim, 19:19:39 > 27. august 2002 (utorok) > Greetings again! > > Today I implemented things I was talking about yesterday. As > it was written, I wanted them and I'm usign them on my website (I > will pass URL tomorrow evening). But I also suppose that you will be > interested in them too. I'm very interested - and I want to thank you for the time you put into PHP Weather. The patches and suggestions are coming faster than I can get time to read them :-) If you plan to continue in this pace, then why don't get yourself a CVS account? I can add nepto as a developer if you're interested... > This e-mail contains three problems described, with solution > written. Patches are also included. I've looked at the patches and I like them - especially the KISS principle :-) But why have you rewritten all the SQL statements to use sprintf() to embed the variables instead of using either "foo $var bar" or 'foo ' . $var . ' bar'? Apart from that, I'll probably commit them tomorrow (or to be correct: later today, it's getting late... :-) I'm sure that I can patch the null and dba database backends to handle the lookup for country code. -- Martin Geisler My GnuPG Key: 0xF7F6B57B See http://gimpster.com/ and http://phpweather.net/ for: PHP Weather => Shows the current weather on your webpage and PHP Shell => A telnet-connection (almost :-) in a PHP page. |
From: Martin G. <gim...@gi...> - 2002-08-27 22:11:10
|
"Steen Rabol" <sr...@ma...> writes: > Hi > > What's the status on the forecast (TAF) decoding ? It's simple: PHP Weather cannot decode TAF reports. We would love to do this some time, but it wont happen any time soon... -- Martin Geisler My GnuPG Key: 0xF7F6B57B See http://gimpster.com/ and http://phpweather.net/ for: PHP Weather => Shows the current weather on your webpage and PHP Shell => A telnet-connection (almost :-) in a PHP page. |
From: Ondrej J. <ne...@po...> - 2002-08-27 19:20:38
|
Maxim, 20:37:32 27. august 2002 (utorok) Greetings! > All shoud work well for MySQL. There is a need for implementation of > the same thing in other DB modules as it is in MySQL one. Once again, they > are these three: As I said, I implemented that stuff for PostgreSQL. I supposed that it will take few hours to study PostgreSQL SQL language specials, but in fact it took only few minutes. Patch in attachement. > 1. Proper query escaping. Quesries seems to be properly escaped. But at least insert will fail if $cc or $location will contain apostroph character. But, well isit possible? > 2. Slashes stripping when returning icao instead name of station. Done. > 3. Method get_country($icao), which returns country code for > partcular icao. Done. Copy/paste from MySQL module did the work (but I was forced to use ' instead of ", strange isn't it? :-) > I will implement it today night for PostgreSQL, but what about DBA? Maybe I will also learn DBA till tomorrow I will send patch also for this, but now I really don't know how does it works because my glance at sources tell that it is not like classical RDBM SQL systems. Another issue for PostgreSQL is that when using function "Create or Recreate Tables" it will fail if I give it empty database. It is due fact, that in PostgreSQL it is impossible to DROP TABLE that does not exists. I solve this problem with these two commands: phpweather=> create table metars ( foo int ); CREATE phpweather=> create table stations ( foo int ); CREATE phpweather=> But it needs more complex solution anyway. =Nepto= ____________________________________________________________________________ Ondrej 'Nepto' Jombik, Open Source software developer, http://www.platon.sk/ |
From: Ondrej J. <ne...@po...> - 2002-08-27 19:20:27
|
> It should work without *NO* problems (for MySQL currently). Erm, I mean: it should work with no problems or it should work without any problems. =Nepto= ____________________________________________________________________________ Ondrej 'Nepto' Jombik, http://www.nepto.sk/ ne...@at... |
From: Ondrej J. <ne...@po...> - 2002-08-27 17:37:28
|
Maxim, 19:19:39 27. august 2002 (utorok) Greetings again! Today I implemented things I was talking about yesterday. As it was written, I wanted them and I'm usign them on my website (I will pass URL tomorrow evening). But I also suppose that you will be interested in them too. This e-mail contains three problems described, with solution written. Patches are also included. SQL failures ------------ PROBLEM: I discovered several SQL query failures when someone nasty pass strange parameters into CGI variables (ie. quoting chars). SOLUTION: Patch SQL queries and do appropriate slashes escaping. Also patch main program to strip slashes from variables recieved from CGI interface. Annoying thing is, that icao is stored add-slashed in data_retrieval object; keep this in mind and strip slashes when returning icao instead of station name! PATCH: File db/pw_db_mysql.php was patched. It contains: - proper query escaping (they look nicer now however) - striping slashes when returning icao instead name of station Decreased pw_utilities.php usage -------------------------------- PROBLEM: Functions in pw_utilities.php are less usuable due to containing hidden "old" variables. We will not need them anymore also on test page. SOLUTION: Remove these hidden "old" variables from pw_utilities.php. PATCH: File pw_utilities.php was patched. It was posted yesterday to phpWeather development mailinglist. Navigation system (demo page) problems -------------------------------------- PROBLEM: Navigation system on demopage is too complicated. It contains redunant data. Not only redunant "old" variables, also redunand cc/icao ones; note that icao contains itself country code. SOLUTION: Completely rewrite navigation system use only three types of page (1 - pure country selection, 2 - location selection, 3 - weather print; detailed information for this was posted yesterday). Use new DB method get_country() to get country for particular icao. This "new style" also allows visitor to direct link weather page for location (airport). He should from scratch write http://example.com/weather.php?icao=lztt if he or she knows particular icao. No other passed CGI variables are needed. PATCHES: 1. data_retrieval.php was patched (get_country() method implemented) 2. db/pw_db_mysql.php was patched (get_country($icao) method was implemented) 3. index.php was rewritten (it's easier to understand, contains less code, and maybe also faster; I'm sending whole file, not patch) All shoud work well for MySQL. There is a need for implementation of the same thing in other DB modules as it is in MySQL one. Once again, they are these three: 1. Proper query escaping. 2. Slashes stripping when returning icao instead name of station. 3. Method get_country($icao), which returns country code for partcular icao. I will implement it today night for PostgreSQL, but what about DBA? Maybe you don't understand or not undestand absolutely what I'm speaking about, or simply don't trust me. Than please ask anything about it, I will try to advocate my changes. :-) I want also ask you for testing it. It should work without *NO* problems (for MySQL currently). Thanks, =Nepto= ____________________________________________________________________________ Ondrej 'Nepto' Jombik, http://www.nepto.sk/ ne...@at... |
From: Steen R. <sr...@ma...> - 2002-08-27 13:57:20
|
Hi What's the status on the forecast (TAF) decoding ? Best Steen |
From: Martin G. <gim...@gi...> - 2002-08-27 12:22:17
|
Ondrej Jombik <ne...@po...> writes: > Algorith is basically simple: check if $cc is set, if it is, > show also stations select. Also check if $icao is iset, if it is, > set particular $cc and print particauler weather for $icao. If you can make the index.php page work the same without those $old_* variables, then please do. I agree that they're kind of annoying... > All we need is one DB method, that will return country ($cc) for > station ($icao). > > I will be able to implement this for mysql (I *will* do it, > because I *want* this navigation system), but I do not know what > about others RDBM systems. I think it would be a good idea to have a get_country($icao) method. And it's definitely possible as it's just a matter of storing the country code together with the name of the station: you look up the ICAO (lookup_icao($icao) already does this) and you get the name of the station and the country code. -- Martin Geisler My GnuPG Key: 0xF7F6B57B See http://gimpster.com/ and http://phpweather.net/ for: PHP Weather => Shows the current weather on your webpage and PHP Shell => A telnet-connection (almost :-) in a PHP page. |
From: Martin G. <gim...@gi...> - 2002-08-26 23:07:02
|
"Max Hammond" <ma...@fl...> writes: > and the db/files files were updated immediately afterward. I'm > assuming that you loaded your mysql up before that? If so, then the fix is simple: load /config/make_db.php and press the 'Create or Recreate Tables' button. It will parse stations.csv and recreate the tables using the current configuration. >> I'm sorry that I came with these issues just before comming >> release, but I did not know about that. Don't worry - noone knew about the upcoming release until I decided to work on it today :-) My interest was sparked by a PhpWeather plugin written for PhpWiki - see my page here: http://gimpster.com/phpwiki/ The initial code talked about the CVS version, and I decided that it would be better if it said 'Download the latest version' instead of 'Download one of the working-but-unreleased CVS versions of PHP Weather'... (I'm exaggerating - it doesn't exactly say the that...) -- Martin Geisler My GnuPG Key: 0xF7F6B57B See http://gimpster.com/ and http://phpweather.net/ for: PHP Weather => Shows the current weather on your webpage and PHP Shell => A telnet-connection (almost :-) in a PHP page. |
From: Max H. <ma...@fl...> - 2002-08-26 21:57:52
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, > 1. There is a little translation bug in index.php file. See patch > below: patched. Thanks. [2-4] I haven't had a chance to look through what you've done, but it looks sensible. Index.php was designed to be a "demo page", to show people how it's done, rather than to be an out-of-the-box solution. That doesn't mean that we can't make it a good example, though :) > 5. I want also ask if there will some weather picture for "no data > available". Temperature and wind, both, have this special case > solved. good idea. Please submit this as a feature request on sourceforge. > 6. In my MySQL database I have two stations for my country (SK) > in stations > table. But in file db/files/SK.php there are 7 airports. Have > someone got idea how has been this desynchornization created and > how to solve it? I will > appreciate it a lot. cvs log of stations.csv: - ---------------------------- revision 1.8 date: 2002/05/28 13:11:58; author: gimpster; state: Exp; lines: +2416 -181 Tom Corser <to...@to...> sent me a dump of his list of stations. There was 2201 new ICAOs in his file, so we now know of 5131 stations in 210 countries! Tom has told me that some of the ICAOs seams to have stopped working, so the above figures are somewhat optimistic. - ---------------------------- and the db/files files were updated immediately afterward. I'm assuming that you loaded your mysql up before that? > I'm sorry that I came with these issues just before comming > release, but I did not know about that. no worries. Max - -- Quidquid latine dictum sit, altum viditur. -----BEGIN PGP SIGNATURE----- Version: PGP 7.0.4 iQA/AwUBPWqlJSaLdinGu4NfEQLkWACgzfNyGLFTRwRhOYqCiEtlu3oiGlMAoOzA rCQlSE7uFInsTu4wQaDkUx3P =RlBb -----END PGP SIGNATURE----- |
From: Ondrej J. <ne...@po...> - 2002-08-26 21:33:22
|
Maxim, 22:53:21 26. august 2002 (pondelok) Greetings! Yesterday I started to integrate phpWeather into my website and I have few notes, comments and questions. 1. There is a little translation bug in index.php file. See patch below: --- index.php.ori Fri May 31 00:26:12 2002 +++ index.php Mon Aug 26 22:55:16 2002 @@ -86,7 +86,7 @@ '" height="40" width="40" border="1" alt="Current wind in ' . $weather->get_location() . '" /> ' . '<img src="' . $icons->get_temp_image() . - '" height="50" width="20" border="1" alt="Current weather in ' . + '" height="50" width="20" border="1" alt="Current temperature in ' . $weather->get_location() . '" />' . "\n</blockquote>\n" . "<p>The raw METAR is <code>" . 2. I want to suggest removal of hidden "old" input fields from functions in pw_utilities.php file. I wanted generaly not to use annoying "old" variables stuff, but I want use these support functions as well. I think that someone who wants use these old variables, can always include them in his/her form. After this change IMHO these functions became more usuable. Patch follows: --- pw_utilities.php.ori Thu Mar 28 16:49:09 2002 +++ pw_utilities.php Mon Aug 26 11:20:14 2002 @@ -15,7 +15,6 @@ } } $output .= "\n</select>\n"; - $output .= '<input type="hidden" name="old_cc" value="' . $old_cc . '" />'; return $output; } @@ -35,8 +34,6 @@ } } $output .= "\n</select>\n"; - $output .= '<input type="hidden" name="old_icao" value="' . - $old_icao . '" />'; return $output; } @@ -55,10 +52,8 @@ } } $output .= "\n</select>\n"; - $output .= '<input type="hidden" name="old_language" value="' . - $old_language . '" />'; return $output; } -?> \ No newline at end of file +?> 3. I want also suggest better navigation system in index.php. I implemented it only with variables $cc and $icao. There is no need for "old" variables ($old_cc, $old_icao). In wednesday I will be hopefully able to show you it on live page. I haven't got uploaded it now. 4. This issue is connected with previous one. Navigation system should be even easier, if we will implement some DB method that will returns country for defined icao. Than three types of page should be shown: a. default one with no variables (shows default country in combo box and no stations) (example: /index.php) b. stations combo box with first station selected + country selected in country combo box (example: /index.php?cc=SK) c. country selected, station selected, appropriate weather printed (example: /index.php?icao=LZTT) Algorith is basically simple: check if $cc is set, if it is, show also stations select. Also check if $icao is iset, if it is, set particular $cc and print particauler weather for $icao. All we need is one DB method, that will return country ($cc) for station ($icao). I will be able to implement this for mysql (I *will* do it, because I *want* this navigation system), but I do not know what about others RDBM systems. 5. I want also ask if there will some weather picture for "no data available". Temperature and wind, both, have this special case solved. 6. In my MySQL database I have two stations for my country (SK) in stations table. But in file db/files/SK.php there are 7 airports. Have someone got idea how has been this desynchornization created and how to solve it? I will appreciate it a lot. I'm sorry that I came with these issues just before comming release, but I did not know about that. Thanks, =Nepto= ____________________________________________________________________________ Ondrej 'Nepto' Jombik, perl -le '$_=1;(1x$_)!~/^(11+)\1+$/&&print while$_++' |
From: Martin G. <gim...@gi...> - 2002-08-26 18:44:48
|
Gyulai Miha'ly <gy...@fb...> writes: > Martin Geisler =EDrta, 2002-08-26, 19:09-kor kelt level=E9ben, ami 39 sor= b=F3l =E1llt: >=20 >> $output =3D sprintf($strings['foobarbaz'], $var_a, $var_b, $var_c); >>=20 >> The advantage of the last method is, that the translator can make >> $var_c come before $var_a in the final string. >=20 > Maybe that would be good. I've found out that this is the normal way of doing things using gettext. =20 >> please update from CVS and see if you can spot any problems. Mail >> back tomorrow with your comments. By the way: Ondrej Jombik has some changes that we'll incorporate before the release, so the release will probably not happen tomorrow after all. =20=20 > I did the CVS update and tested it. I wonder how the "HTML iso-code" > could be modified by the selected language? The index.php file should already do this properly by sending the right header: header('Content-Type: text/html; charset=3D' . $text->get_charset()); This makes the output contain all sorts of accents. =20 > The iso-8859-1 is not suitable for Hungarian, we use iso-8859-2. Is > it possible to do? The selected City appears without accents... You mean in the drop-down list? That's right - there's no accents in that, but that's mostly because the city names doesn't have any accents in stations.csv. I'm not sure if we want characters in stations.csv that doesn't belong to ISO-8859-1. The thing is: what should the browser do, when it's displaying text in Danish (using ISO-8859-1) but sees a Hungarian city with characters from ISO-8859-2? I've played a little with this before, but here goes again: could we just use Unicode (UTF-8?) for all files instead of this mess with different encodings for different files? I don't have any experience with this, but from what I've heard, then Unicode is supposed to solve these problems. --=20 Martin Geisler My GnuPG Key: 0xF7F6B57B See http://gimpster.com/ and http://phpweather.net/ for: PHP Weather =3D> Shows the current weather on your webpage and PHP Shell =3D> A telnet-connection (almost :-) in a PHP page. |
From: Gyulai Miha'ly <gy...@fb...> - 2002-08-26 18:24:30
|
Martin Geisler =EDrta, 2002-08-26, 19:09-kor kelt level=E9ben, ami 39= sorb=F3l =E1llt: > $output =3D sprintf($strings['foobarbaz'], $var_a, $var_b, $var_c= ); >=20 > The advantage of the last method is, that the translator can make > $var_c come before $var_a in the final string. Maybe that would be good. > please update from CVS and see if you can spot any problems. Mail > back tomorrow with your comments. =20 I did the CVS update and tested it. I wonder how the "HTML iso-code" could be modified by the selected language? The iso-8859-1 is not suitable for Hungarian, we use iso-8859-2. Is it possible to do? The selected City appears without accents... --=20 Mih=E1ly Gyulai http://gyulai.freeyellow.com/ |