Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #37542 > unrolled thread

Weather App reworked

Back to article view | Back to comp.lang.javascript

Contents

  Weather App reworked luserdroog <luser.droog@gmail.com> - 2019-10-13 03:31 -0700
    Re: Weather App reworked Julio Di Egidio <julio@diegidio.name> - 2019-10-13 05:49 -0700
      Re: Weather App reworked luserdroog <luser.droog@gmail.com> - 2019-10-14 10:53 -0700
        Re: Weather App reworked Julio Di Egidio <julio@diegidio.name> - 2019-10-14 21:22 -0700
    Re: Weather App reworked John G Harris <niam@jghnorth.org.uk.invalid> - 2019-10-13 14:46 +0100
      Re: Weather App reworked Julio Di Egidio <julio@diegidio.name> - 2019-10-13 07:02 -0700
        Re: Weather App reworked Julio Di Egidio <julio@diegidio.name> - 2019-10-13 07:08 -0700
          Re: Weather App reworked Julio Di Egidio <julio@diegidio.name> - 2019-10-13 07:16 -0700
            Re: Weather App reworked "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2019-10-13 10:10 -0700
              Re: Weather App reworked Julio Di Egidio <julio@diegidio.name> - 2019-10-13 10:34 -0700
            Re: Weather App reworked John G Harris <niam@jghnorth.org.uk.invalid> - 2019-10-13 19:55 +0100
              Re: Weather App reworked Julio Di Egidio <julio@diegidio.name> - 2019-10-14 05:56 -0700
                Re: Weather App reworked John G Harris <niam@jghnorth.org.uk.invalid> - 2019-10-15 18:21 +0100
                  Re: Weather App reworked Julio Di Egidio <julio@diegidio.name> - 2019-10-15 12:32 -0700
                    Re: Weather App reworked John G Harris <niam@jghnorth.org.uk.invalid> - 2019-10-16 16:06 +0100
    Re: Weather App reworked "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2019-10-13 14:02 -0700
      Re: Weather App reworked dr.j.r.stockton@gmail.com - 2019-10-14 13:28 -0700
        Re: Weather App reworked "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2019-10-14 14:58 -0700
      Re: Weather App reworked luserdroog <luser.droog@gmail.com> - 2019-10-15 09:00 -0700

#37542 — Weather App reworked

I reworked the Weather App to try to make better use of Object Orientation.
It seems to really help to group related things together. My use of the
controller seems a little weird, though. I got all the control functions
grouped nicely, but they're not in a class. I didn't see any easy way to
do that given the way it all works. I'm not sure if I need more than one
control so that may be moot.

The MVC classes have been supplemented with a SessionModel that backs the
value up in session storage, a DependentModel that observes other Models
and modifies its own value before notifying any views, and a few helpful
functions in the View class.

The app itself starts by making a few customized Models. Then all the
model instances are defined. Then all the views on those models. Then
the controller is extracted from the primary view and used to hold
the UI functions. 

There still remain a few unencapsulated functions but they are all pure
utility functions it doesn't seem too bad to leave them vanilla.

https://luser-dr00g.github.io/weather4/
https://github.com/luser-dr00g/luser-dr00g.github.io/tree/master/weather4

Comments welcome.

-- 
The droog

[toc] | [next] | [standalone]

#37543

On Sunday, 13 October 2019 12:31:46 UTC+2, luserdroog  wrote:

> I reworked the Weather App to try to make better use of Object Orientation.

You can stick that equivalent of an half botched Python up your ass: just stop
spamming this group.

*Plonk*

Julio

[toc] | [prev] | [next] | [standalone]

#37560

On Sunday, October 13, 2019 at 7:49:26 AM UTC-5, Julio Di Egidio wrote:
> On Sunday, 13 October 2019 12:31:46 UTC+2, luserdroog  wrote:
> 
> > I reworked the Weather App to try to make better use of Object Orientation.
> 
> You can stick that equivalent of an half botched Python up your ass: just stop
> spamming this group.
> 
> *Plonk*
> 
> Julio

That's a very unpleasant thing to say. I am trying to be a positive contributor
here, even while asking for guidance. I trust the "plonk" indicates that you
will not be reading my posts and hence be no further annoyance in threads that
I start.

[toc] | [prev] | [next] | [standalone]

#37563

On Monday, 14 October 2019 19:53:14 UTC+2, luserdroog  wrote:

> That's a very unpleasant thing to say.

And that's just the beginning, you piece of polluting crap.

Julio

[toc] | [prev] | [next] | [standalone]

#37544

On Sun, 13 Oct 2019 03:31:40 -0700 (PDT), luserdroog
<luser.droog@gmail.com> wrote:

>I reworked the Weather App to try to make better use of Object Orientation.
>It seems to really help to group related things together. My use of the
>controller seems a little weird, though. I got all the control functions
>grouped nicely, but they're not in a class. I didn't see any easy way to
>do that given the way it all works. I'm not sure if I need more than one
>control so that may be moot.
  <snip>

>There still remain a few unencapsulated functions but they are all pure
>utility functions it doesn't seem too bad to leave them vanilla.

If you want to bunch functions together just make them properties of
an isolated object, in the same way that mathematical functions are
placed inside the Math (pseudo) object.

Doing this means you can re-use the functions in another project
without suffering from name clashes. (As in cowboy.draw and
picture.draw)

This may apply to your control functions as well.

  John

PS Remember that Julio doesn't approve of OO

[toc] | [prev] | [next] | [standalone]

#37545

On Sunday, 13 October 2019 15:46:26 UTC+2, John G Harris  wrote:

> PS Remember that Julio doesn't approve of OO

Wrong, liar, as I've had to explain this before: learn to use the right tool
for the right job, and OO in JS indeed is an abomination.

Julio

[toc] | [prev] | [next] | [standalone]

#37546

On Sunday, 13 October 2019 16:02:39 UTC+2, Julio Di Egidio  wrote:
> On Sunday, 13 October 2019 15:46:26 UTC+2, John G Harris  wrote:
> 
> > PS Remember that Julio doesn't approve of OO
> 
> Wrong, liar, as I've had to explain this before: learn to use the right tool
> for the right job, and OO in JS indeed is an abomination.

And it's true that there are serious limitations with objection orientation,
from the actual realm of applicability which is way more restricted and the
very opposite of an OO uber alles, to the misinformation and misguidance that
goes with, starting from the car analogy and how it does NOT apply to the
real world, all mainly in the direction of tools-based development and the
speculations of the vendors and the magic solution sellers, and the defamation
and lies about the very state of the art that necessarily had to go with it.
But that's already lesson #2, while we are still stuck with the preliminaries.

HTH, the casual reader.

Julio

[toc] | [prev] | [next] | [standalone]

#37547

On Sunday, 13 October 2019 16:09:01 UTC+2, Julio Di Egidio  wrote:
> On Sunday, 13 October 2019 16:02:39 UTC+2, Julio Di Egidio  wrote:
> > On Sunday, 13 October 2019 15:46:26 UTC+2, John G Harris  wrote:
> > 
> > > PS Remember that Julio doesn't approve of OO
> > 
> > Wrong, liar, as I've had to explain this before: learn to use the right tool
> > for the right job, and OO in JS indeed is an abomination.
> 
> And it's true that there are serious limitations with objection orientation,
> from the actual realm of applicability which is way more restricted and the
> very opposite of an OO uber alles, to the misinformation and misguidance that
> goes with, starting from the car analogy and how it does NOT apply to the
> real world, all mainly in the direction of tools-based development and the
> speculations of the vendors and the magic solution sellers, and the defamation
> and lies about the very state of the art that necessarily had to go with it.
> But that's already lesson #2, while we are still stuck with the preliminaries.
> 
> HTH, the casual reader.

And now back to the point, because OO can suck my socks, the point actually
was learn JS and functional programming and what that can actually achieve,
or better just go play with Python, that half-botched Basic not even that
good for the non-programmer and the new de facto benchmark for cluelessness.

Have fun,

Julio

[toc] | [prev] | [next] | [standalone]

#37550

On Sunday, October 13, 2019 at 9:16:26 AM UTC-5, Julio Di Egidio wrote:
> And now back to the point, because OO can suck my socks, the point actually
> was learn JS and functional programming and what that can actually achieve,
> or better just go play with Python, that half-botched Basic not even that
> good for the non-programmer and the new de facto benchmark for cluelessness.

Again with your drama? Still waiting on you to actually say something of substance:

<https://groups.google.com/d/msg/comp.lang.javascript/9FxKCWG7NLQ/iXVPdwuaCgAJ>

[toc] | [prev] | [next] | [standalone]

#37551

On Sunday, 13 October 2019 19:10:17 UTC+2, Michael Haufe (TNO)  wrote:
> On Sunday, October 13, 2019 at 9:16:26 AM UTC-5, Julio Di Egidio wrote:
> > And now back to the point, because OO can suck my socks, the point actually
> > was learn JS and functional programming and what that can actually achieve,
> > or better just go play with Python, that half-botched Basic not even that
> > good for the non-programmer and the new de facto benchmark for cluelessness.
> 
> Again with your drama? Still waiting on you to actually say something of substance:
> 
> <https://groups.google.com/d/msg/comp.lang.javascript/9FxKCWG7NLQ/iXVPdwuaCgAJ>

Still back to OO?  Indeed, we have been there already, an that you cannot
even read is certainly not my fault.

Sure, keep going...

*Plonk*

Julio

[toc] | [prev] | [next] | [standalone]

#37552

On Sun, 13 Oct 2019 07:16:20 -0700 (PDT), Julio Di Egidio
<julio@diegidio.name> wrote:

  <snip>
>And now back to the point, because OO can suck my socks, the point actually
>was learn JS and functional programming and what that can actually achieve,
>or better just go play with Python, that half-botched Basic not even that
>good for the non-programmer and the new de facto benchmark for cluelessness.

And yet you agreed that OO is ok for making complex numbers, dates,
lists, trees, etc behave like built-in data types.

  John

[toc] | [prev] | [next] | [standalone]

#37559

On Sunday, 13 October 2019 20:55:25 UTC+2, John G Harris  wrote:
> On Sun, 13 Oct 2019 07:16:20 -0700 (PDT), Julio Di Egidio
> <julio@diegidio.name> wrote:
> 
>   <snip>
> >And now back to the point, because OO can suck my socks, the point actually
> >was learn JS and functional programming and what that can actually achieve,
> >or better just go play with Python, that half-botched Basic not even that
> >good for the non-programmer and the new de facto benchmark for cluelessness.
> 
> And yet you agreed that OO is ok for making complex numbers, dates,
> lists, trees, etc behave like built-in data types.

I am quite sure I cannot have said "built-in", liar.  But yes, essentially
just data types.

Anyway, mainly to mention another very common utter mistake: conflating
static typing with object orientation.

Way to go...

Julio

[toc] | [prev] | [next] | [standalone]

#37566

On Mon, 14 Oct 2019 05:56:54 -0700 (PDT), Julio Di Egidio
<julio@diegidio.name> wrote:

>On Sunday, 13 October 2019 20:55:25 UTC+2, John G Harris  wrote:
  <snip>

>> And yet you agreed that OO is ok for making complex numbers, dates,
>> lists, trees, etc behave like built-in data types.
>
>I am quite sure I cannot have said "built-in", liar.  

And I am quite sure I wasn't quoting your exact words, which is why I
didn't use any quote symbols. "liar" is therefore just meaningless
abuse.


>But yes, essentially
>just data types.
>
>Anyway, mainly to mention another very common utter mistake: conflating
>static typing with object orientation.

You're saying some classes in a program are not data types? Wow!

Or are you saying your concern with OO is nothing to do with
programming language semantics?

>Way to go...

Yes indeed.

  John

[toc] | [prev] | [next] | [standalone]

#37567

On Tuesday, 15 October 2019 19:21:59 UTC+2, John G Harris  wrote:
> On Mon, 14 Oct 2019 05:56:54 -0700 (PDT), Julio Di Egidio
> <julio@diegidio.name> wrote:
> >On Sunday, 13 October 2019 20:55:25 UTC+2, John G Harris  wrote:
>   <snip>
> 
> >> And yet you agreed that OO is ok for making complex numbers, dates,
> >> lists, trees, etc behave like built-in data types.
> >
> >I am quite sure I cannot have said "built-in", liar.  
> 
> And I am quite sure I wasn't quoting your exact words, which is why I
> didn't use any quote symbols. "liar" is therefore just meaningless
> abuse.
...
> You're saying some classes in a program are not data types? Wow!

You systematically just putting bullshit in my mouth is the mark of a
retarded cunt, i.e. not even an interesting one at that.

Just go fuck yourself.

*Plonk*

Julio

[toc] | [prev] | [next] | [standalone]

#37568

On Tue, 15 Oct 2019 12:32:09 -0700 (PDT), Julio Di Egidio
<julio@diegidio.name> wrote:

>On Tuesday, 15 October 2019 19:21:59 UTC+2, John G Harris  wrote:
  <snip>

>...
>> You're saying some classes in a program are not data types? Wow!
>
>You systematically just putting bullshit in my mouth is the mark of a
>retarded cunt, i.e. not even an interesting one at that.

Says he carefully hiding the statement by him that I translated into
English.

And equally carefully avoiding any attempt to clarify what he is
trying to say.

  John

[toc] | [prev] | [next] | [standalone]

#37555

On Sunday, October 13, 2019 at 5:31:46 AM UTC-5, luserdroog wrote:
> I reworked the Weather App to try to make better use of Object Orientation.
> It seems to really help to group related things together. My use of the
> controller seems a little weird, though. I got all the control functions
> grouped nicely, but they're not in a class. I didn't see any easy way to
> do that given the way it all works. I'm not sure if I need more than one
> control so that may be moot.
> 
> The MVC classes have been supplemented with a SessionModel that backs the
> value up in session storage, a DependentModel that observes other Models
> and modifies its own value before notifying any views, and a few helpful
> functions in the View class.
> 
> The app itself starts by making a few customized Models. Then all the
> model instances are defined. Then all the views on those models. Then
> the controller is extracted from the primary view and used to hold
> the UI functions. 
> 
> There still remain a few unencapsulated functions but they are all pure
> utility functions it doesn't seem too bad to leave them vanilla.
> 
> https://luser-dr00g.github.io/weather4/
> https://github.com/luser-dr00g/luser-dr00g.github.io/tree/master/weather4
> 
> Comments welcome.
> 

1. XHR vs Fetch

XmlHttpRequest is becoming legacy. Consider using Fetch instead:

<https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch>


2. Conventions

The convention for variable and method names is camelCase:

show_current_weather -> showCurrentWeather

3. Subclassing

You're still not using classes properly:

```javascript
var control = report.getController();
Object.assign( control, {
  search: function(){ location.value = this.getView().find('.i_search').value },
  unit_imperial: function(){ unit.value = 'imperial' },
  unit_metric:   function(){ unit.value = 'metric'   },
  unit_standard: function(){ unit.value = 'standard' },
  current:   function(){ report_type.value = 'current'   },
  forecast2: function(){ report_type.value = 'forecast2' },
  forecast3: function(){ report_type.value = 'forecast3' },
  forecast4: function(){ report_type.value = 'forecast4' },
  forecast5: function(){ report_type.value = 'forecast5' },
  show_server_data:function(){ showing_server_data.value = true  },
  hide_server_data:function(){ showing_server_data.value = false },
});
```

Create a new subclass instead. I assume this is the intent:

```javascript
class WeatherController extends Controller {
  search(){ ... }
  unitImperial(){ ... }
  unit_metric(){ ... }
  unit_standard(){ ... }
  current(){ ... }
  forecast2(){ ... }
  forecast3(){ ... }
  forecast4(){ ... }
  forecast5(){ ... }
  showServerData(){ ... }
  hideServerData(){ ...}
}

var foo = new WeatherController()
```

4. use the DOM instead of innerHTML

You're doing things like the following:

```javascript
format_forecast_data( data, days ){
  return `<h1>${days} days forecast for \
<nobr>${data.city.name},</nobr> ${data.city.country}</h1>
<div class=report_data>${this.format_forecast_results(data,days)}</div>`;
}
```

Instead, have the element in the page, then update it directly.

You have the find(...) method now, so use it:

```javascript
...
this.find('.report_data').textContent = ...;
```

5. Switches are not Object Oriented.

You have the following:

```javascript
switch( report_type.value ){
  case 'current':   this.show_current_weather( value ); break;
  case 'forecast2': this.show_forecast( value, 2 );     break;
  case 'forecast3': this.show_forecast( value, 3 );     break;
  case 'forecast4': this.show_forecast( value, 4 );     break;
  case 'forecast5': this.show_forecast( value, 5 );     break;
}
```

This is a hint that you have a missing class or are not using inheritance. You need to refactor this so that it becomes a single method call on an object. Something which may help with understanding why would be a blog post of mine on a related issue:

<https://thenewobjective.com/the-great-maze-of-jquery/>

6. Don't pass a function to super

```javascript
  constructor( model ){
    super( model,
      function( value ){
        ...
      });
  }
```

This is a hint that you should override/extend your class.

```javascript
class View {
  ...
  constructor( model, update ){
    if( model ) this.setModel( model )
    if( update ) this.onUpdate = update;
  }
  update( data ){
    if( typeof( this.onUpdate ) == 'function' ) this.onUpdate( data );
    this._subViews.forEach( s=> s.update( data ) );
  }
   ...
}
```

Something you can do here is define an onUpdate method that does nothing by default. This would eliminate the need for an `if` statement in the update method and the need to pass it to the constructor:


```javascript
class View {
  ...
  constructor( model ){
    if( model ) this.setModel( model )
  }
  update( data ){
    this.onUpdate( data );
    this._subViews.forEach( s=> s.update( data ) );
  }
  onUpdate(value) { ... }
   ...
}

class WeatherView extends View {
  ...
  onUpdate(value) { 
    switch( report_type.value ){
      case 'current':   this.show_current_weather( value ); break;
      ...
    }
 }
  ...
}

```

Notice that the WeatherView will no longer need an explicit constructor defined

Now do the same thing for all of the Views.

```javascript
var unit_controls = new View( unit,
  function( value ){
    console.log( value );
    this.show( this.find('.unit_imperial') );
    this.show( this.find('.unit_metric') );
    this.show( this.find('.unit_standard') );
    this.hide( this.find('.unit_' + value) );
  }
);

// becomes:

class UnitControls extends View {
   ...
   onUpdate(value){...}
   ...
}
```

7. View in context of an element

If you associate each view with a specific element, many of your methods
can be simplified greatly:

```javascript
class View {
  _htmlElement
  ...
  find(sel){
    return this._htmlElement.querySelector(sel)
  }
  show(){
    this._htmlElement.style.display = 'block'
  }
  hide(){
    this._htmlElement.style.display = 'none'
  }
  ...
}
```

and so on.

8. Utility functions are just undefined objects

You have a lot of these. Take a look at what they operate on and you can
see what they should be methods of.  For example the date functions can be defined as methods of your own Date subclass:

```javascript
class Chrono extends Date {
  dayOfWeek(){
    let w = ['Sunday','Monday','Tuesday','Wednesday','Thursday','Friday','Saturday'];
    return w[ this.getDay() ];
  }
  ...
}
```

There is more, but I'm out of time for this round. HTH

[toc] | [prev] | [next] | [standalone]

#37561

On Sunday, 13 October 2019 22:02:38 UTC+1, Michael Haufe (TNO)  wrote:


>     let w = ['Sunday','Monday','Tuesday','Wednesday','Thursday','Friday','Saturday'];
>     return w[ this.getDay() ];


If one appends another 'Sunday', then the array can also be used with the convention of ISO 8601, in which the days of the week are Mon=1 to Sun=7.  Only a minority of countries start the week on Sunday nowadays

-- 
  (c) John Stockton, near London, UK.  Using Google Groups.           |
 Mail: J.R.""""""""@physics.org - or as Reply-To, if any.             |

[toc] | [prev] | [next] | [standalone]

#37562

On Monday, October 14, 2019 at 3:28:07 PM UTC-5, dr.j.r...@gmail.com wrote:
> On Sunday, 13 October 2019 22:02:38 UTC+1, Michael Haufe (TNO)  wrote:
> 
> 
> >     let w = ['Sunday','Monday','Tuesday','Wednesday','Thursday','Friday','Saturday'];
> >     return w[ this.getDay() ];
> 
> 
> If one appends another 'Sunday', then the array can also be used with the convention of ISO 8601, in which the days of the week are Mon=1 to Sun=7.  Only a minority of countries start the week on Sunday nowadays

I didn't want to change to much of the provided code in in swoop.

Even better than your suggestion is to use the modern API for this:

```JavaScript
new Date().toLocaleDateString('en-US', {weekday: 'long'})
// "Monday"

new Date().toLocaleDateString('de-DE', {weekday: 'long'})
// "Montag"
```

Ref: <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/toLocaleDateString>

[toc] | [prev] | [next] | [standalone]

#37565

On Sunday, October 13, 2019 at 4:02:38 PM UTC-5, Michael Haufe (TNO) wrote:
> On Sunday, October 13, 2019 at 5:31:46 AM UTC-5, luserdroog wrote:

> > https://luser-dr00g.github.io/weather4/
> > https://github.com/luser-dr00g/luser-dr00g.github.io/tree/master/weather4
> > 
> > Comments welcome.
> > 

Mostly for my own reference, I'm snipping parts that I've dealt with and
reposting this useful list.

> 1. XHR vs Fetch
> 
> XmlHttpRequest is becoming legacy. Consider using Fetch instead:
> 
> <https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch>
> 

I'm putting off this part since it appears orthogonal to the rest.
 
> 2. Conventions

I have applied this to all the functions and methods in the javascript,
but stopped short with my 'unit_imperial' etc. control methods since
they need to match the class names of my DOM elements. Changing these
means I lose my easy technique of concatenating 'unit_' with the value
to get the class name.

> 3. Subclassing
[done]
> 
> 4. use the DOM instead of innerHTML
> 
> You're doing things like the following:
> 
> ```javascript
> format_forecast_data( data, days ){
>   return `<h1>${days} days forecast for \
> <nobr>${data.city.name},</nobr> ${data.city.country}</h1>
> <div class=report_data>${this.format_forecast_results(data,days)}</div>`;
> }
> ```
> 
> Instead, have the element in the page, then update it directly.
> 
> You have the find(...) method now, so use it:
> 
> ```javascript
> ...
> this.find('.report_data').textContent = ...;
> ```
> 
> 5. Switches are not Object Oriented.
> 
> You have the following:
> 
> ```javascript
> switch( report_type.value ){
>   case 'current':   this.show_current_weather( value ); break;
>   case 'forecast2': this.show_forecast( value, 2 );     break;
>   case 'forecast3': this.show_forecast( value, 3 );     break;
>   case 'forecast4': this.show_forecast( value, 4 );     break;
>   case 'forecast5': this.show_forecast( value, 5 );     break;
> }
> ```
> 
> This is a hint that you have a missing class or are not using inheritance. You need to refactor this so that it becomes a single method call on an object. Something which may help with understanding why would be a blog post of mine on a related issue:
> 
> <https://thenewobjective.com/the-great-maze-of-jquery/>
> 
> 6. Don't pass a function to super
[done]

> 7. View in context of an element
> 
> If you associate each view with a specific element, many of your methods
> can be simplified greatly:
> 
> ```javascript
> class View {
>   _htmlElement
>   ...
>   find(sel){
>     return this._htmlElement.querySelector(sel)
>   }
>   show(){
>     this._htmlElement.style.display = 'block'
>   }
>   hide(){
>     this._htmlElement.style.display = 'none'
>   }
>   ...
> }
> ```
> 
> and so on.
> 
> 8. Utility functions are just undefined objects
> 
> You have a lot of these. Take a look at what they operate on and you can
> see what they should be methods of.  For example the date functions can be defined as methods of your own Date subclass:
> 

I've applied this to the Date related functions. Need to do some thinking
about compassPoints().

> 
> There is more, but I'm out of time for this round. HTH

Thank you very much. I'm finding this effort incredibly helpful.
I'm experiencing resistance or difficulty with these remaining pieces
concerning the DOM. OTOH, I've had some ideas about how to improve
the UX and present more information, possibly with fewer http requests.

If I put all the elements in the html, then I can't have the polymorphic
behavior where the current weather fits in one div but the various
forecasts stuff several divs into the same container. So that means
I will either need extra models and views to show/hide each part, OR
change the UX so the two views are both active at the same time.

So instead maybe I can: make exactly 2 http requests, fetching the
current weather and the 5 day forecast. Do all unit conversions locally
and don't make new requests when changing. Present a "detail pane"
which shows current weather, as well as a "chart pane" showing a table
of <time><temp><brief><icon> for the specified number of days. Then I can
have the detail pane show the details for a timeslice when the mouse
hovers over it.

So, still thinking over this bit.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web