phpweather-devel — General development talk and discussions.

RE: How about this?

[Max H. <ma...@fl...>]

Hi all,

> To make sure we're talking about the same thing, I went and
> implemented mine idea :-) I haven't commited the changes to CVS
> because I wanted to hear the reactions first. Instead, I've uploaded
> the files to gimpster.com:

Looks good to me.

> I stored the icons in a directory called 'images'. I figured that
> 'images' are more generic, and we might have more images in the
> future.

Okay, but I think that it would make sense to keep the icons seperate from
any future images - they do play one specific role. Perhaps put them in a
subdirectory of images if you really want?

> All the above is just a suggestion - we can change everything if you
> have any objections. So, please download the tarball and tell me what
> you think.

Looks good to me. I'd suggest that you move the icons and then commit it.

Max

How about this?

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

Hi everybody

To make sure we're talking about the same thing, I went and
implemented mine idea :-) I haven't commited the changes to CVS
because I wanted to hear the reactions first. Instead, I've uploaded
the files to gimpster.com:

  http://www.gimpster.com/downloads/

I've changed some things: the class metar_parser is now known as
phpweather, and the former phpweather class has been removed.

I've put the output modules in a subdirectory called - surprise -
output. They're called 'pw_type_xx.php' where type is something like
'text' or 'images' and xx is the language-code.

I stored the icons in a directory called 'images'. I figured that
'images' are more generic, and we might have more images in the
future.

All the above is just a suggestion - we can change everything if you
have any objections. So, please download the tarball and tell me what
you think.

=2D-=20
Martin Geisler                       My GnuPG Key: 0xF7F6B57B

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

Re: Design for PHP Weather 2

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

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

> Hi all,
>=20
>> Should the pw_text object then include a file with the English
>> strings? If so, then how does the English translation override
>> something in pw_text?
>=20
> yes, include() it from the pw_text class. It wouldn't necessarily be
> an override, it could work in a similar way to the way it does at
> the moment.

But at the moment, we have subclasses for each language - this isn't
what you mean, is it?
=20
>> I know that I keep talking about this idea, but I have a feeling
>> that it'll come in handy at some time. We actually discussed using
>> it for the Hungarian translation where Mih=E1ly Gyulai had some
>> problems with some of the strings.
>=20
> There's nothing to stop us doing both... Most languages will work
> with the same "template", I think. We could make different classes
> for anything that's so different that our assumptions about syntax
> and grammar don't hold at all. I'm not keen to do things like this,
> but it's an option.

I agree that most languages should work with the same template. So
their classes would simply have a constructor that initializes
$strings with the right strings to fill in the template.

You would rather have this initialization of the $strings in a file
that's included by the template, right?
=20
> I'm still not convinced that subclassing the languages is going to
> help. I see it as "the purpose of the output object is to return
> text" - and that is true for whatever language, so it makes sense
> that that output object is configurable, rather than replacable.

I'm not talking about replacing the output module, I'm talking about
extending and overriding it for languages which dont fit into the
template provided by the basic output module.

>> This would enable an British-English class could inherit from the
>> current British-American class and change only a couple of words,
>> things like 'color' to 'colour' and so on. And if the
>> British-American class has overridden some methods in the
>> base-class (very unlikely) then that will benifit the
>> British-English class as well.
>=20
> You could override those same methods in the localisation include
> file, if you do:

But you can't override function definitions in an included file. That
is, unless we do something like this in our output module:

include("pw_locale_$language.inc");

if (!function_exists('output_temp')) {

  function output_temp($c, $f) { ... }

}

I'm not even sure that it would work as I've coded it above..

That's why I'm thinking about having the localisation subclass the
basic output instead of just including a file.
=20
> basic_text <------ pw_text
>                     ||
>                pw_loc_en-gb.inc
>=20
> Most of the functions we need are actually in the basic_text object,
> and pw_text only really exists to apply localisation to it.

Ahh - I think we almost agree :-) We have an basic_text object with
the methods needed to do textual output. (This is what locale_common
does today). Do you then want the pw_text object to subclass
basic_text or do you want basic_text to use an pw_text object like the
db_layer currently uses a db_mysql object?

Also, what is the difference between the basic_text and pw_text
classes? If pw_text only exists to apply localization, then why dont
we just call it pw_text_en, pw_text_da and so forth?

>> The first version of PHP Weather was written without any planning.
>=20
> And it's still a great piece of work - It does what it does very
> well.

Thanks - but the code that handles the databases are pretty ugly.
=20
=2D-=20
Martin Geisler                       My GnuPG Key: 0xF7F6B57B

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

RE: Strategy

[Max H. <ma...@fl...>]

Hi all,

> >I'd like to develop it using the tools that are available.
>
> .. and of course you want to use the tools that are available,
> but does that
> refrain you from using php3? I'm a php-newbie, so you have to
> tell me: Does the use of php3 'impossiblelize' (can't find another word
;-)
> the new and better functionality you had in mind for PHPWeather 2?

PHP4 does many things a lot better than php3. We can write cleaner, faster
code more easily, and use functions to save so much time. (eg foreach() or
include_once(). It's not impossible to write good code that is compatible
with 3, but I just don't think it's worth it any more.

> If so, then I surrender and say "go ahead, I'll stay behind". No hard
> feelings though. ;-)

Your host will eventually have to upgrade; or you can find a better one.
Mention the serious security hole in PHP and that they've got the choice to
reinstall a new version of 3, or go to 4..

Max

RE: Design for PHP Weather 2

[Max H. <ma...@fl...>]

Hi all,

> What I'm proposing is actually just a change of names: locale_common
> is very tightly coupled with the textual output, so it should become
> the base-class for that output module. The icons should also have
> their own output module.
>
> >> [...]
> >> echo $text->get_output();
> >> echo '<img src=3D"' . $icon->get_output() . '">';
> >
> > I'd be happier to see
> > $weather =3D new pw_weather('EGBE');
> > $text =3D new pw_text($weather,"en");
> > $icons =3D new pw_icons($weather);
>
> Should the pw_text object then include a file with the English
> strings? If so, then how does the English translation override
> something in pw_text?

yes, include() it from the pw_text class. It wouldn't necessarily be an
override, it could work in a similar way to the way it does at the moment.

> I know that I keep talking about this idea, but I have a feeling that
> it'll come in handy at some time. We actually discussed using it for
> the Hungarian translation where Mih=E1ly Gyulai had some problems with
> some of the strings.

There's nothing to stop us doing both... Most languages will work with th=
e
same "template", I think. We could make different classes for anything
that's so different that our assumptions about syntax and grammar don't h=
old
at all. I'm not keen to do things like this, but it's an option.

> > echo $text->print_pretty() . '<br />
> > <img src=3D"'.$icons->src_main().'" />';
> >
> > etc.
> >
> > - let's not mess about with different functions for each locale,
> > it'll be much easier to add new locales if we select it in the
> > function itself, rather than defining the function to be
> > locale-specific.
>
> But I was thinking that each locale was it's own class. That should
> also make it easy to add new locales - you just subclass a suitable
> language and change what needs to be changed.

sorry, I meant to say class rather than function.

I'm still not convinced that subclassing the languages is going to help. =
I
see it as "the purpose of the output object is to return text" - and that=
 is
true for whatever language, so it makes sense that that output object is
configurable, rather than replacable.

> This would enable an British-English class could inherit from the
> current British-American class and change only a couple of words,
> things like 'color' to 'colour' and so on. And if the British-American
> class has overridden some methods in the base-class (very unlikely)
> then that will benifit the British-English class as well.

You could override those same methods in the localisation include file, i=
f
you do:

basic_text <------ pw_text
                     ||
               pw_loc_en-gb.inc

Most of the functions we need are actually in the basic_text object, and
pw_text only really exists to apply localisation to it.

> >> Or perhaps it should just be
> >>
> >> $icon =3D new pw_output_icon($weather->get_data());
> >
> > no. Let's do it properly OO. Pass it the object, then it'll be
> > easier to get out anything we need at a later date. We should be
> > consistent, so that any output function should take the $phpweather
> > object.
>
> Right. That's exactly why I'm glad we're discussing this: our system
> should be flexible and extensible. The first version of PHP Weather
> was written without any planning. I just found some code that could
> decode a METAR, I added some extra utility functions, and the result
> is what you see today.

And it's still a great piece of work - It does what it does very well.

Max

Re: Design for PHP Weather 2

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

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

>> I think it's going to be hard (impossible?) to separate the
>> output-modules from the locales. As it is now, locale_common should
>> probably be considered an output-module: it knows how to produce
>> textual output. The locales then extend this class. This cannot
>> work if there are more than one of these classes, so I suggest that
>> we simply drop the idea about having a seperate locale and
>> output-module.
>=20
> I think that the locale is intrinsic in any function that returns
> text...

Yes - so we shouldn't try and split the function that generates text
away from it's locale.=20

What I'm proposing is actually just a change of names: locale_common
is very tightly coupled with the textual output, so it should become
the base-class for that output module. The icons should also have
their own output module.

>> [...]
>> echo $text->get_output();
>> echo '<img src=3D"' . $icon->get_output() . '">';
>=20
> I'd be happier to see
> $weather =3D new pw_weather('EGBE');
> $text =3D new pw_text($weather,"en");
> $icons =3D new pw_icons($weather);

Should the pw_text object then include a file with the English
strings? If so, then how does the English translation override
something in pw_text?

I know that I keep talking about this idea, but I have a feeling that
it'll come in handy at some time. We actually discussed using it for
the Hungarian translation where Mih=E1ly Gyulai had some problems with
some of the strings.
=20
> echo $text->print_pretty() . '<br />
> <img src=3D"'.$icons->src_main().'" />';
>=20
> etc.
>=20
> - let's not mess about with different functions for each locale,
> it'll be much easier to add new locales if we select it in the
> function itself, rather than defining the function to be
> locale-specific.

But I was thinking that each locale was it's own class. That should
also make it easy to add new locales - you just subclass a suitable
language and change what needs to be changed.

This would enable an British-English class could inherit from the
current British-American class and change only a couple of words,
things like 'color' to 'colour' and so on. And if the British-American
class has overridden some methods in the base-class (very unlikely)
then that will benifit the British-English class as well.
=20
> An alternative to this schema is if the output functions actually
> extend the phpweather class, but I can see problems if we want to
> produce both text and icons...

Yes, I think they have to be separate. It wouldn't make sense to make
two phpweather objects and parse the METAR twice to get both text and
icons.
=20
>> Or perhaps it should just be
>>
>> $icon =3D new pw_output_icon($weather->get_data());
>=20
> no. Let's do it properly OO. Pass it the object, then it'll be
> easier to get out anything we need at a later date. We should be
> consistent, so that any output function should take the $phpweather
> object.

Right. That's exactly why I'm glad we're discussing this: our system
should be flexible and extensible. The first version of PHP Weather
was written without any planning. I just found some code that could
decode a METAR, I added some extra utility functions, and the result
is what you see today.

Now that we're doing a rewrite, then we have the chance to come up
with a structure that can last for some time.

=2D-=20
Martin Geisler                       My GnuPG Key: 0xF7F6B57B

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

Re: Design for PHP Weather 2

[Max H. <ma...@fl...>]

> > My plan is to separate the METAR-parsing logic from the output. So
> > we should have a class phpweather that handles the parsing of the
> > METAR and uses the database-layer to cache it.
> >
> > Then we should have several modules (two so far) which talk to the
> > phpweather object and retrieves the parsed METAR from it. They can
> > also obtain things like the ICAO and location from the class
> > phpweather (which can find this information in the database).
> >
> > The module should work together with a locale to produce the output.
> > If it doesn't need any localization information, then the locale can
> > be left out.
>
> I think it's going to be hard (impossible?) to separate the
> output-modules from the locales. As it is now, locale_common should
> probably be considered an output-module: it knows how to produce
> textual output. The locales then extend this class. This cannot work
> if there are more than one of these classes, so I suggest that we
> simply drop the idea about having a seperate locale and output-module.

I think that the locale is intrinsic in any function that returns text...


> In this setup, phpweather is the superclass of metar-parser and the
> db-layer. Seperated from hierarchy, we have the output-modules. We
> have the three base-classes: output_text, output_icons, and
> output_wap. The output_text and output_wap classes are sub-classed by
> the different language-classes, whereas output_icons doesn't need any
> internationalization.
>
> With the new proposal, this would be something like this:
>
> $weather = new phpweather('EKYT');
> $text = new pw_output_text_en($weather,
>                               array('mark_begin' => '<i>',
>                                     'mark_end'   => '</i>'));
>
> $icon = new pw_output_icon($weather);
>
> echo $text->get_output();
> echo '<img src="' . $icon->get_output() . '">';

I'd be happier to see
$weather = new pw_weather('EGBE');
$text = new pw_text($weather,"en");
$icons = new pw_icons($weather);

echo $text->print_pretty() . '<br />
<img src="'.$icons->src_main().'" />';

etc.

- let's not mess about with different functions for each locale, it'll be
much easier to add new locales if we select it in the function itself,
rather than defining the function to be locale-specific.

An alternative to this schema is if the output functions actually extend
the phpweather class, but I can see problems if we want to produce both
text and icons...

> Or perhaps it should just be
>
> $icon = new pw_output_icon($weather->get_data());

no. Let's do it properly OO. Pass it the object, then it'll be easier to
get out anything we need at a later date. We should be consistent, so that
any output function should take the $phpweather object.

Max

-- 
Never put the words "Diabolical Master Plan" on a CV

Re: Design for PHP Weather 2

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

"Martin Geisler" <gim...@gi...> writes:

> Hi again

I'll just expand on what I said a little earlier...

> My plan is to separate the METAR-parsing logic from the output. So
> we should have a class phpweather that handles the parsing of the
> METAR and uses the database-layer to cache it.
>
> Then we should have several modules (two so far) which talk to the
> phpweather object and retrieves the parsed METAR from it. They can
> also obtain things like the ICAO and location from the class
> phpweather (which can find this information in the database).
>
> The module should work together with a locale to produce the output.
> If it doesn't need any localization information, then the locale can
> be left out.

I think it's going to be hard (impossible?) to separate the
output-modules from the locales. As it is now, locale_common should
probably be considered an output-module: it knows how to produce
textual output. The locales then extend this class. This cannot work
if there are more than one of these classes, so I suggest that we
simply drop the idea about having a seperate locale and output-module.

So, instead of having this:

                            ---> output_(text/icons/...)
                           /
  DB <----> phpweather <--<
                           \
                            ---> locale_(en/da/...)

where the locale has to work together with the output-modules in a
rather tricky way, I think we should have this:

                                               +-- output_text_en
                                               |
                           ---> output_text <--+-- output_text_da
                          /                    |
  DB <---- phpweather <---+---> output_icons   +-- output_text_xx
                          \
                           ---> output_wap <---+-- output_wap_en
                                               |
                                               +-- output_wap_da
                                               |
                                               +-- output_wap_xx

In this setup, phpweather is the superclass of metar-parser and the
db-layer. Seperated from hierarchy, we have the output-modules. We
have the three base-classes: output_text, output_icons, and
output_wap. The output_text and output_wap classes are sub-classed by
the different language-classes, whereas output_icons doesn't need any
internationalization.

> So you would probably do something like this:
>
> $weather =3D new phpweather('EKYT');
> $locale =3D new pw_locale_en();
> $text =3D new pw_module_text($weather, $locale,
>                            array('mark_begin' =3D> '<i>',
>                                  'mark_end' =3D> '</i>');
> $icon =3D new pw_module_icon($weather);
>
> echo $text->get_output();
> echo '<img src=3D"' . $icon->get_output() . '">';

With the new proposal, this would be something like this:

$weather =3D new phpweather('EKYT');
$text =3D new pw_output_text_en($weather,
                              array('mark_begin' =3D> '<i>',
                                    'mark_end'   =3D> '</i>'));

$icon =3D new pw_output_icon($weather);

echo $text->get_output();
echo '<img src=3D"' . $icon->get_output() . '">';

Or perhaps it should just be

$icon =3D new pw_output_icon($weather->get_data());

where get_data() would return an array with the parsed metar plus
things like the location etc.

> We would of course have to think about how we are going to let the
> locales customize the output of the modules...

That should work automatically now.

=2D-
Martin Geisler                       My GnuPG Key: 0xF7F6B57B

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

Design for PHP Weather 2

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

Hi again

I've thought some more about how we could structure PHP Weather 2. The
design that's currently in CVS isn't final - it's actually my first
attempt at using objects in a program. I've learned Java since, and
with that a lot of OO.

My plan is to separate the METAR-parsing logic from the output. So we
should have a class phpweather that handles the parsing of the METAR
and uses the database-layer to cache it.

Then we should have several modules (two so far) which talk to the
phpweather object and retrieves the parsed METAR from it. They can
also obtain things like the ICAO and location from the class
phpweather (which can find this information in the database).

The module should work together with a locale to produce the output.
If it doesn't need any localization information, then the locale can
be left out.

So you would probably do something like this:

$weather =3D new phpweather('EKYT');
$locale =3D new pw_locale_en();
$text =3D new pw_module_text($weather, $locale,
                           array('mark_begin' =3D> '<i>',
                                 'mark_end' =3D> '</i>');
$icon =3D new pw_module_icon($weather);

echo $text->get_output();
echo '<img src=3D"' . $icon->get_output() . '">';

Does this kind of separation make sense?

We would of course have to think about how we are going to let the
locales customize the output of the modules...

=2D-=20
Martin Geisler                       My GnuPG Key: 0xF7F6B57B

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

Re: Strategy

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

"Ray van Beek" <r_v...@ho...> writes:

> Max,
>=20
>>My feeling is that you're in a minority here - I think that most hosts
>>have upgraded by now.
>=20
>>It's a balance of where our priorities lie - continue with the old code,
>>or work on the new. PHPWeather 2 is really quite a bit better than the 1.x
>>branch.
>=20
> Oh, but I agree that PHPWeather 2 is a lot better (although I
> haven't seen it yet ;-).

By PHP Weather 2, I think (hope) he means the code you'll find in CVS
under the module 'phpweather'. It has some nice things, including much
better support for different databases (or no database at all), more
detailed parsing of the METAR, an improved
internationalization-framework (wow - that was a lot of expensive
words in one sentence :-)

> And of course it is great that it is being developed further....
>=20
>>I'd like to develop it using the tools that are available.
>=20
> . and of course you want to use the tools that are available, but
> does that refrain you from using php3?

PHP4 is faster and better, bla, bla... Seriously, there's a whole
bunch of nice functions for dealings with arrays. I also believe that
PHP4 has better support for objects (which is used in PHP Weather 2)

> I'm a php-newbie, so you have to tell me: Does the use of php3
> 'impossiblelize' (can't find another word ;-) the new and better
> functionality you had in mind for PHP Weather 2?

Well, the code in CVS doesn't run on PHP3 as it is right now - you
should try and have a look at it. I'm not sure why, I only know that
it didn't run last someone tried it on PHP3.
=20
> If so, then I surrender and say "go ahead, I'll stay behind". No
> hard feelings though. ;-)

OK.=20

=2D-=20
Martin Geisler                       My GnuPG Key: 0xF7F6B57B

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

Re: Strategy

[<php...@de...>]

On Fri, 15 Mar 2002 16:51:58 +0100, "Martin Geisler" wrote:
=> Could we have a quick vote on the list? There's 36 people on the list,
=> so it wouldn't have any statistical significance, but it would give an
=> indication of the number of people who still runs PHP3.

	As one of the 36 on the list, I agree: leave this current
level as a legacy [non-supported] level for PHP-3 "must-haves"
but go with PHP4 (or 4.1) for all new development and release
from here forward.  IMO, you could have done this last year.

	Cheers,

	- Don

Re: Strategy

[Ray v. B. <r_v...@ho...>]

Max,

>My feeling is that you're in a minority here - I think that most hosts
>have upgraded by now.

>It's a balance of where our priorities lie - continue with the old code,
>or work on the new. PHPWeather 2 is really quite a bit better than the 1.x
>branch.

Oh, but I agree that PHPWeather 2 is a lot better (although I haven't seen 
it yet ;-). And of course it is great that it is being developed further....

>I'd like to develop it using the tools that are available.

.. and of course you want to use the tools that are available, but does that 
refrain you from using php3? I'm a php-newbie, so you have to tell me: Does 
the use of php3 'impossiblelize' (can't find another word ;-) the new and 
better functionality you had in mind for PHPWeather 2?

If so, then I surrender and say "go ahead, I'll stay behind". No hard 
feelings though. ;-)

Greetz,

Ray


_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

Re: Strategy

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

"Ray van Beek" <r_v...@ho...> writes:

>> > What's important is that the way I'm writing stuff at the moment
>> > relys on people having PHP4 - for example I used foreach(). I think
>> > it's reasonable now to expect people to have php4. Any comments?
>>
>>It would surely make things a lot easier if we require PHP4. And now
>>that PHP4 has been out for over 2 years I don't think it's too much to
>>ask of people, that they upgrade to the new and improved version from
>>PHP version 3.
>=20
> Eh, sorry guys, my provider has two types of accounts:
> - the low cost with php3, no mysql, low bandwidth, little disk space
> - the high cost with php4, mysql high bandwidth, lots of disk space
>=20
> I can't afford the high cost account type so I stick with the low
> cost type. Someone in this list suggested a while a go to persuade
> my provider to get php4, but the only answer I got is: "No, I will
> not install php4, but you can get the high cost account".

I really hope that cases like this are the minority - your provider
doesn't seams to provide much service to it's customers.

Since you're paying for this "service" I would either demand a current
version of PHP or find another provider.

> I guess a lot of people are in this situation. So therefor I would
> strongly recommend not to dispose the php3 code.

I would also like to support PHP3, but I think it would take a lot of
effort to do so. And we would limit ourselves to work-arounds which
would be slower and more difficult to get right.

Could we have a quick vote on the list? There's 36 people on the list,
so it wouldn't have any statistical significance, but it would give an
indication of the number of people who still runs PHP3.

=2D-=20
Martin Geisler                       My GnuPG Key: 0xF7F6B57B

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

Re: Strategy

[Max H. <ma...@fl...>]

Hi Ray,

> > > What's important is that the way I'm writing stuff at the moment
> > > relys on people having PHP4 - for example I used foreach(). I think
> > > it's reasonable now to expect people to have php4. Any comments?
> >
> >It would surely make things a lot easier if we require PHP4. And now
> >that PHP4 has been out for over 2 years I don't think it's too much to
> >ask of people, that they upgrade to the new and improved version from
> >PHP version 3.
>
> Eh, sorry guys, my provider has two types of accounts:
> - the low cost with php3, no mysql, low bandwidth, little disk space
> - the high cost with php4, mysql high bandwidth, lots of disk space
>
> I can't afford the high cost account type so I stick with the low cost type.
> Someone in this list suggested a while a go to persuade my provider to get
> php4, but the only answer I got is: "No, I will not install php4, but you
> can get the high cost account".
> I guess a lot of people are in this situation. So therefor I would strongly
> recommend not to dispose the php3 code.

My feeling is that you're in a minority here - I think that most hosts
have upgraded by now.

It's a balance of where our priorities lie - continue with the old code,
or work on the new. PHPWeather 2 is really quite a bit better than the 1.x
branch. I'd like to develop it using the tools that are available.

Especially, note that PHP3 has a big security hole, so your host has a
choice of patch php3 or install 4, it's not that big a deal. They might
not do it, but that's a different question...

Max

-- 
Never put the words "Diabolical Master Plan" on a CV

Re: Strategy

[Ray v. B. <r_v...@ho...>]

> > What's important is that the way I'm writing stuff at the moment
> > relys on people having PHP4 - for example I used foreach(). I think
> > it's reasonable now to expect people to have php4. Any comments?
>
>It would surely make things a lot easier if we require PHP4. And now
>that PHP4 has been out for over 2 years I don't think it's too much to
>ask of people, that they upgrade to the new and improved version from
>PHP version 3.

Eh, sorry guys, my provider has two types of accounts:
- the low cost with php3, no mysql, low bandwidth, little disk space
- the high cost with php4, mysql high bandwidth, lots of disk space

I can't afford the high cost account type so I stick with the low cost type. 
Someone in this list suggested a while a go to persuade my provider to get 
php4, but the only answer I got is: "No, I will not install php4, but you 
can get the high cost account".
I guess a lot of people are in this situation. So therefor I would strongly 
recommend not to dispose the php3 code.

Ray

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

Re: Strategy

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

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

> Hi all,
>=20
> I've been tweaking things this morning, but I want to include the
> new images stuff into the new code (phpweather 2).

Great!
=20
> What's important is that the way I'm writing stuff at the moment
> relys on people having PHP4 - for example I used foreach(). I think
> it's reasonable now to expect people to have php4. Any comments?

It would surely make things a lot easier if we require PHP4. And now
that PHP4 has been out for over 2 years I don't think it's too much to
ask of people, that they upgrade to the new and improved version from
PHP version 3.
=20
> I intend to include the icons as core functionality rather than a
> strap-on as they are at the moment. Is this okay with everyone? - so
> phpweather will get the get_xyz_image() functions built straight in.

That sounds like a good idea. And now that you mention it: it would be
nice, if we could make a system, so that people could use different
modules with PHP Weather. The icon-functionality would be one such
module, and so would the verbose textual output.

It should work something like this: we have the class phpweather which
provides all the methods necessary to retrieve the data and cache it.

The modules would then either subclass phpweather (phpweather-icon,
phpweather-text, phpweather-wap, phpweather-table, etc) or perhaps it
would be better if the main phpweather object had these modules as
member variables. By doing it like that, they would all share the
parsed METAR.

What do you think about that?

=2D-=20
Martin Geisler                       My GnuPG Key: 0xF7F6B57B

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

Strategy

[Max H. <ma...@fl...>]

Hi all,

I've been tweaking things this morning, but I want to include the new images
stuff into the new code (phpweather 2).

What's important is that the way I'm writing stuff at the moment relys on
people having PHP4 - for example I used foreach(). I think it's reasonable
now to expect people to have php4. Any comments?

I intend to include the icons as core functionality rather than a strap-on
as they are at the moment. Is this okay with everyone? - so phpweather will
get the get_xyz_image() functions built straight in.

Max

--
A man on a mission is far different from a drone on a deadline.
 * Rheta Grimsley Johnson

Rework

[Ray v. B. <r_v...@ho...>]

Martin,

Check the 'Unknown metar data format' thread in the sci.geo.meteorology 
usegroup. It seems that the ///// format in metar is common use, although it 
is not spec-ed. This was a thread in this list as well.

IMHO the script should be changed to support the ///// format.

The script needs also some rework for the use of the isset/isempty function 
in the 'weather' part of the data. This was also a thread in this list.

Can you find time to change this, because half the time, the pretty_metar 
ends with 'The current weather is .'

Ray







_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com

Re: 'Bug' with weather icons (images.inc)

[Kevin G. <go...@ae...>]

'allo!

on 3/13/02 3:01 PM, Ray van Beek at r_v...@ho... wrote:
>> Well, my web site is here:  http://www.moulton-udell.k12.ia.us/  The
>> weather
>> is located in the navigation column on the left-hand side (at the bottom).
>> It looks okay in IE, but for some reason, my columns get squished in
>> Netscape.  I'm still trying to work on that.
> 
> I found it. Great! Do you mind if I reference your site on my 'Online
> weather' project page http://www.devolder.nl ?

Be my guest!   I found it extraordinarily easy to use the phpweather.inc and
images.inc files.  Works marvelously!

>>This way if there is no current weather data in the metar, it will fall
>>back
>>on the cloud condition.  Hope this helps.
>
> That *is* a good idea.

Well, I don't know if most weather stations report current weather
conditions frequently or not.  But the station I'm using doesn't appear to
use them very often, so instead of printing nothing, I decided to print the
cloud conditions.  It's a little more useful that way.

> Now Kevin, I like the today's specials for lunch. Maybe I'll drop by :-)

<grin>  Well then, you won't want to miss tomorrow's lunch -- we're having
turkey fritters and hash browns!

Thanks again for the script and graphics -- they look great!

----
Kevin Godby  <go...@ae...>
Technology Coordinator
Moulton-Udell Community School District
305 E. Eighth St.   Phone: (641) 642-8131
Moulton, Iowa  52572  Fax: (641) 642-3461

Re: 'Bug' with weather icons (images.inc)

[Ray v. B. <r_v...@ho...>]

>My mistake!  I was passing the actual metar string to your function instead
>of the array.  In other words, I was doing this:

Glad you found it!

>That's what I get for not reading the comments/instructions very carefully.
>:)

Yep, that's true...

>Well, my web site is here:  http://www.moulton-udell.k12.ia.us/  The 
>weather
>is located in the navigation column on the left-hand side (at the bottom).
>It looks okay in IE, but for some reason, my columns get squished in
>Netscape.  I'm still trying to work on that.

I found it. Great! Do you mind if I reference your site on my 'Online 
weather' project page http://www.devolder.nl ?

>To print the current weather string, I'm doing something like this:
>
>   $metar = get_metar('KOTM');
>
>   $data = process_metar($metar);
>
>   $condition = ucfirst($data['cloud_layer1_condition']);
>   $weather = $data['weather'];
>
>   // if there is no current weather, use the cloud condition instead
>   if (strlen($weather) == 0) {
>           echo "$condition<br>\n";
>   } else {
>           echo "$weather<br>\n";
>   };
>
>This way if there is no current weather data in the metar, it will fall 
>back
>on the cloud condition.  Hope this helps.

That *is* a good idea.

Now Kevin, I like the today's specials for lunch. Maybe I'll drop by :-)

Greetz,

Ray


_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com

Re: 'Bug' with weather icons (images.inc)

[Kevin G. <go...@ae...>]

on 3/12/02 2:25 PM, Ray van Beek at r_v...@ho... wrote:

> Hmmmm, I glued your metar in my own script (down below) and it shows ok
> (overcast). Maybe I did something wrong with scope of variables, more than
> one include files or something in that direction....

My mistake!  I was passing the actual metar string to your function instead
of the array.  In other words, I was doing this:

  $metar = get_metar('KOTM');   // station in Ottumwa, Iowa
  $data = process_metar($metar);
  $image = get_sky_image($metar);   // <-- this is not the right way!

instead of this:

  $image = get_sky_image($data);   // <-- this is the correct way!

That's what I get for not reading the comments/instructions very carefully.
:)

> No problem, let me know when it's operational (and the URL).

Well, my web site is here:  http://www.moulton-udell.k12.ia.us/  The weather
is located in the navigation column on the left-hand side (at the bottom).
It looks okay in IE, but for some reason, my columns get squished in
Netscape.  I'm still trying to work on that.

To print the current weather string, I'm doing something like this:

  $metar = get_metar('KOTM');

  $data = process_metar($metar);

  $condition = ucfirst($data['cloud_layer1_condition']);
  $weather = $data['weather'];

  // if there is no current weather, use the cloud condition instead
  if (strlen($weather) == 0) {
          echo "$condition<br>\n";
  } else {
          echo "$weather<br>\n";
  };

This way if there is no current weather data in the metar, it will fall back
on the cloud condition.  Hope this helps.

Thanks again for the script!

----
Kevin Godby  <go...@ae...>
Technology Coordinator
Moulton-Udell Community School District
305 E. Eighth St.   Phone: (641) 642-8131
Moulton, Iowa  52572  Fax: (641) 642-3461

Re: 'Bug' with weather icons (images.inc)

[Ray v. B. <r_v...@ho...>]

Hi Kevin,

>Using the following METAR:
>
>KMTO 112053Z AUTO 18009KT 10SM OVC090 06/M04 A3007 RMK AO2 SLP190 T00561039
>56031
>
>the images.inc (get_sky_image) function returns the 0cloud.gif image 
>instead
>of the 4cloud_norain.gif image.  The cloud_layer1_condition is 'overcast'
>(OVC), and the weather is null.

Hmmmm, I glued your metar in my own script (down below) and it shows ok 
(overcast). Maybe I did something wrong with scope of variables, more than 
one include files or something in that direction....

>I will dig through to code a bit more later on.

Good idea, I'm sorry I can't help from here right now. Please let us know 
what you find (either good or bad).

>I'm glad someone else write it, though!  :)

No problem, let me know when it's operational (and the URL).

>Thanks!

Thank you!

Ray

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html>

<head>
<title></title>
</head>

<body topmargin="4">
<?php

include('./locale_en.inc');
include('./images.inc');
include('./phpweather.inc');

//$metar = get_metar('EHEH');
$metar = 'KMTO 112053Z AUTO 18009KT 10SM OVC090 06/M04 A3007 RMK AO2 SLP190 
T00561039 56031';
$decoded_metar = process_metar($metar);
?>


<table class=weather bgcolor="#FEF9B8" cellpadding=4 cellspacing=0 
width=100%>
  <tr valign=top>
    <td>
      <table class=weather cellpadding=2 cellspacing=0 width=120>
        <tr bgcolor="#C4BF06">
          <td colspan=3 ><b>Temperatuur:</b></td>
        </tr>
		<tr height=1px bgcolor="#FEF9B8"></tr>
        <tr height=59 valign=top bgcolor="#C4BF06">
          <td>&nbsp</td>
          <td><? printf("%4.1f",$decoded_metar['temp_c']) ?> &deg;C</td>
          <td><img src="<? get_temp_image($decoded_metar) ?>" height="50" 
width="20" border=1></td>
        </tr>
      </table>
	</td>
    <td>
	  <table class=weather  cellpadding=2 cellspacing=0 width=120>
        <tr bgcolor="#C4BF06">
          <td colspan=3><b>Wind:</b></td>
        </tr>
		<tr height=1px bgcolor="#FEF9B8"></tr>
        <tr height=59 valign=top bgcolor="#C4BF06">
          <td>&nbsp</td>
          <td>
                   <? printf(get_beaufort()) ?> Bft, <? 
printf($decoded_metar['wind_dir_text_short']) ?><br>
                   <? 
printf("%3.1f",$decoded_metar['wind_meters_per_second']) ?> m/s<br>
                   <? 
printf("%3.1f",$decoded_metar['wind_meters_per_second']*3600/1000) ?> km/h
          </td>
          <td>
            <img src="<? get_winddir_image($decoded_metar) ?>" height="40" 
width="40" border=1>
          </td>
        </tr>
      </table>
	</td>
    <td>
	  <table class=weather  cellpadding=2 cellspacing=0 width=120>
        <tr bgcolor="#C4BF06">
          <td colspan=3><b>Bewolking:</b></td>
        </tr>
		<tr height=1px bgcolor="#FEF9B8"></tr>
        <tr height=59 valign=top bgcolor="#C4BF06">
          <td>&nbsp</td>
          <td colspan=2>
		    <img src="<? get_sky_image($decoded_metar) ?>" height="50" width="80" 
border=1>
          </td>
        </tr>
      </table>
	</td>
    <td width=100%>
	</td>
  </tr>
</table>
</body>
</html>


_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

'Bug' with weather icons (images.inc)

[Kevin G. <go...@ae...>]

Hello.

Using the following METAR:

KMTO 112053Z AUTO 18009KT 10SM OVC090 06/M04 A3007 RMK AO2 SLP190 T00561039
56031

the images.inc (get_sky_image) function returns the 0cloud.gif image instead
of the 4cloud_norain.gif image.  The cloud_layer1_condition is 'overcast'
(OVC), and the weather is null.

I will dig through to code a bit more later on.  I'm glad someone else write
it, though!  :) 

Thanks!

----
Kevin Godby  <go...@ae...>
Technology Coordinator
Moulton-Udell Community School District
305 E. Eighth St.   Phone: (641) 642-8131
Moulton, Iowa  52572  Fax: (641) 642-3461

Upload graphics and scripts

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

Ray sent this message to the list, but it was stopped because it was
too big - I'm resending it without the files attached. The files are
now in CVS, take a look here:

  http://cvs.sf.net/cgi-bin/viewcvs.cgi/phpweather/phpweather-1.x/

> Hi all!
>
> It took me a while, but please find the weather icons and the
> accompanying script images.inc enclosed. Martin, if you want, you
> can add these to the phpweather project.

Of course I want to add these files to the project! Thanks a lot!
=20
> To use the icons, include the images.inc and the regular phpweather
> files (locale_**.inc and phpweather.inc). The images.inc script
> contains all filenames and the images path.

Great - I've changed it a bit to include the images from a 'icons'
subdirectory.
=20
> The images.inc script relies heavily on the phpweather code: it
> expects that the metar has already been decoded by process_metar().
> The images.inc script contains a function that converts the wind
> speed in [m/s] to Beauforts. I don't know about the rest of the
> world but in the Netherlands windspeed is often expressed in
> Beaufort. IMHO, I think that the Beaufort unit should be part of the
> already existing knots/milesperhour/kilometersperhour function in
> phpweather.inc. In that case, the function can be deleted from
> images.inc.

You're right - it should probably be part of the output. But this is a
more general problem: there's more unit-systems in use today than the
metric and imperial. Some people like a mixture of those two systems,
so the best thing would be, if we could support a wide range of units,
so that people could chose their preferred unit for each bit of the
report.

> During development of images.inc I made a very simple and small
> script (list.php) that shows all available associative array
> elements. This way I could check the operation of the images.inc
> functions. The list.php is included as well.

Nice - some people have asked for such a tool. I've changed it
slightly so that the output looks more like what you get by using the
print_r() call in PHP4.
=20
> I included a demo page as well: table.php. This page shows all
> available icons and some explanation.

That's really good.
=20
> Finally, I was wondering if the phpweather can be changed such that
> it 'understands' the /////KT notation on wind (and other groups), as
> is discussed in the 'Funny chars in metar?' thread in this list. I
> still haven't seen a spec on that, but apparently the notation
> *does* exist.
>=20
> I did not want to add this in CVS, because I'm not familiar with it:
> I'm only starting in Linux.
>=20
> Have fun!
>=20
> Ray

=2D-=20
Martin Geisler                       My GnuPG Key: 0xF7F6B57B

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

RE: (no subject)PHP Flash

[Max H. <ma...@fl...>]

> So I too am on a steep learning curve and would be grateful for any other
> recommended PHP manuals/authors.

I'd reccommend the site http://www.phpbuilder.com - there are a lot of good
articles there.

> ps I can't find a definition of "tar" can someone enlighten me ?

It stands for "Tape Archive" - it's one of the earliest unix commands, which
was designed for backing files up onto tape. It's mostly used now to make
these kinds of distributions. Whereas winzip can combine various files into
one archive, unix gzip can't. So typically, you tar a whole directory, and
then gzip that tarred file.

Max