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.