API Weather App Example and Suggestions

Today I played around with External API feature in 6.4b3. Works very nice. I was able to build a small weather forecast page with OpenWeather API.

Of course all icons are the new FontAwesome icons. And even the wind direction does have the correct degree :slight_smile:

Here are some questions/suggestions I noted along the way:

  • In the info field, is there an information where I can tell, if the response is from cache or not? Maybe filetime?
  • often I wanted to string format a value. Do we have a way to do this?
    i.e.: {{dc:looper:field key="temperature" format="%01.2f"}}
  • often there are UNIX timestamps in the response. Do we have a way to format them?
    i.e.: {{dc:looper:field key="timestamp" timestampformat="H:m"}}
    I know this works on some time fields like Publish Time. Maybe this can be expanded to looper fields?

Currently I wrote two small shortcodes to string format and convert timestamps. But of course it would be nice, if there is a built in way :slight_smile:

All in all just some convenience suggestions.
Good job, I had no problems while playing with the API :+1:

4 Likes

Very cool and great looking example. You beat me to utilizing that API. Thanks for the kind words as well. Can’t wait to see what you and everybody else builds.

  • No you can’t, but great idea. I will add that into the info object. Leaning on is_cache, but you’ll see it popup in the next release.
  • You can’t format numbers unfortunately. I can write in the request for this. I would love to solve pretty much all remaining Dynamic Content limitations through a template engine like Twig. https://twig.symfony.com/doc/3.x/filters/number_format.html
  • https://theme.co/docs/dynamic-content#formatting This part of the doc was a long time coming, but you can format dates through type="date" format="H:m". The RSS Feed “pubDate” also uses this. Let me know if you have questions.
2 Likes

Ah cool, missed that one with the date format. Thank you.
And I like the twig approach.

There is one thing I asked myself regarding arrays while looping the open weather data . Lets assume this small JSON response:

{
  "timezone": "Europe/Berlin",
  "timezone_offset": 7200,
  "current": {
    "dt": 1698152142,
    "temp": 14.24
    "wind_speed": 1.54,
    "wind_deg": 210,
    "weather": [
      {
        "id": 803,
        "main": "Clouds",
        "description": "Überwiegend bewölkt",
        "icon": "04d"
      }
    ]
  }
}

I create a Dynamic Content looper provider with {{dc:looper:field key="response"}}
Then I can access the data for current.wind_speed like {{dc:looper:field key="current.wind_speed"}}

But then there is that array current.weather in this example. It contains only one item.
My questions is: is an additional sub looper provider the only way to access that data in that array?

Nice would be something like {{dc:looper:field key="current.weather[0].icon"}} directly from the first looper provider.

In my experience with APIs you quite often get arrays with only one item (don’t ask me why). And an additional looper seems bit too much and makes things more complex, if I only ever want to access the first item.

Furthermore: if I create an additional looper for the array, I’m not able to access data from the parent looper (Looper 1), right?

Let’s say I want to display the current.temp data beside the current.weather.icon data.

So for current.weather I create a second sub looper (Looper 2), since it is an array.
While I’m in that second looper provider I can display the icon data with {{dc:looper:field key="icon"}}.

Now I want to display the current.temp field beside the icon data, but there is no way to access it, while I’m in the second looper provider, right?

Then I thought, it would be nice, if I can just save the current.temp value while I’m in Looper 1 in a variable, so I can re-use it while I’m in Looper 2.

Just some thoughts and questions I encountered during the tests with the OpenWeather API.

1 Like

You should be able to access the first array index without using the brackets{{dc:looper:field key="current.weather.0.icon"}}. Using 0 didn’t work for keys prior to this release, if you tried in the past it would have not have worked.

In your case I think the above would solve the need to access parent data, but yes you can’t really access looper parent data. That’s a good to have feature and will be a great addition to the looper renaissance. We’ll see that in a point release or in the next minor release for Pro 6.4. I’m leaning on depth='1' accesses the first parent in the stack and so on. Have a great day!

2 Likes

Ah, I was close with {{dc:looper:field key="current.weather[0].icon"}} :slight_smile:
Very nice additions! Thank you.

1 Like

Be still my beating heart! This is awesome. Time to have a play…

This is awesome! any chance of sharing the template for this to see how you’ve built it?

Thank you guys.

Sure, here is a link to a .tco file:
https://files.pyropixel.de/weather-app-example.tco

5 Likes

Ah! That makes playing around much easier. Thanks so much :slight_smile:

1 Like

Thank you!

1 Like

Thank you so much, looking forward to having a play with this

1 Like

@raye Nur zur Info, aber deine files.pyro… ist öffentlich einsehbar, sprich das ganze Verzeichnis wird angezeigt.

1 Like

Ah danke fĂĽr den Hinweis @ERES. Nix sensibles drin, aber ist natĂĽrlich besser, es abzuschalten.

1 Like

Just in case the example is not working (anymore): in the .tco is also my OpenWeather API key stored. That is why I had to delete that key. So you need to create an OpenWeather account on your own and create your own API key and exchange it in the parameter settings of the Looper Provider. But OpenWeather API is free if you stay under 1000 calls per month. So make sure to use the cache settings properly :grin:

BTW: in the Themeco docs you will find a hint on how to properly store your API key. The way I did is not the recommended way. At the time of playing around with it I did not thought about sharing this example. My bad.

@charlie When the API key has been deleted, I got a 401 (not authenticated) as a response, which is correct. But it seems Cornerstone hangs in an endless loading loop, although timeout is set to 7 seconds. Then I changed the URI to a non existent one and it hangs too.
That is strange since when I began playing with the API I have not discovered such endless loading :man_shrugging:

EDIT
@charlie I found out, when there are additional dynamic Looper Provider + Consumers that rely on the response from extern API, but the response is an error response, then Cornerstone hangs. You can just install my .tco weather example and it should hang, since my OpenWeather API key is not valid anymore.
But if you delete the two Divs with the Looper Providers (see image) then Cornerstone loads again.

3 Likes

Hi @charlie, just a +1 for being able to do number formatting at some point… I have had a play with @raye’s template and I’m seriously impressed with what is possible… but being able to correctly format data that we don’t control the source would be very useful

3 Likes