Re: Iconize weather info and something else

[Martin G. <gim...@gi...>]

"Max Hammond" <ma...@fl...> writes:

>> And it would be preferable if the script could try and guess when
>> to turn if off.
> 
> get_browser() depends on browscap.ini being properly defined and
> kept up to date, and won't help with people who've disabled js.
> Since browscap does not get installed by default with PHP, I think
> we're asking for trouble by using it.

You're right - I've actually never used get_browser(), it just seamed
like a nice builtin way of detecting the browsers capabilities - until
you pointed out that it isn't a default feature.

> Sure, give people an option, but I don't think we should be using
> get_browser() at all.

Agreed. Perhaps the easiest way of doing things would be to simply
write 'Please wait... (If you have disabled JavaScript or nothing
happens, click here)' where the last part is a link to the page with
the JavaScript-thing turned off.

> This is something for application designers to worry about, whereas
> phpweather is a library rather than an application.

Very true. I've had the exact same thought about PHP Weather: it
should be regarded as a library which people can use to build all
kinds of functionality on.

I did realise this when I made the first code, and that means that the
library-functionality is mixed with the application-level code. The
code in CVS is much more separated - the class metar_parser doesn't do
anything except parsing METARs.

But the class is still rather tightly coupled with other classes -
it's probably a mistake that it is a descendant of data_retrieval, as
metar_parser isn't an improved data-retriever - it's whole other
thing. PHP Weather is my first attempt at using objects, and I wanted
the hierarchy to end with class phpweather, so that people could do
something like this:

  $weather = new phpweather(array('icao' => 'EKYT'));
  $weather->print_pretty();

It still looks nice IMHO, but it can also be done without making
phpweather a descendant of metar_parser. 

The ideal situation would be, that the core of PHP Weather is
metar_parser. One should then be able to connect the metar_parser with
different output-modules, such as: localized textual output, numeric
output, WAP output, image output and so on.

> It would make more sense IMO to start building this kind of
> functionality into the CVS tree. I think that a lot of what's in CVS
> is nearly ready for release, so we should be concentrating on making
> a release out of it, rather than tweaking the old stuff. The
> functions in CVS (eg browsing to the airport of choice) are more at
> the application level than the current releases.

I agree - I've just been afraid to do the switch, as it seams that
people are very fond of the old version. It's probably a
chicken-and-egg problem: people doesn't switch to the new version
before it's almost complete, and I don't release the new version
before people start using it... :-)

So, let's work on getting a release of the new code, so that people
can stop using the old ugly code.

-- 
Martin Geisler                       My GnuPG Key: 0xF7F6B57B

See my homepage at http://www.gimpster.com/ for:
PHP Weather => Shows the current weather on your webpage.
PHP Shell   => A telnet-connection (almost :-) in a PHP page.