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