There was a problem in cleanDescription that made returnLinkblogHtml not work properly.
In the jsonify template we were including http files when the app is served via https.
This way of calling it should work, but doesn't --
What we do --
-
if a request is made for / and no template was specified, we do the same thing we do as if returnjson had been called
-
this is what i always expect it to do, when using it as a utility, so let's make it work that way.
More new calls:
/returnlinkblogjson
Example of call --
http://feeder.scripting.com/returnlinkblogjson?feedurl=http://data.feedland.org/feeds/davewiner.xml
This is the format that Radio3 saves a user's linkblog to. At first I thought I'd need this format, but later decided to create a different endpoint that put all the rendering code in feeder, so I didn't need to replicate it in the apps.
/returnlinkbloghtml
Example of call --
http://feeder.scripting.com/returnlinkbloghtml?feedurl=http://data.feedland.org/feeds/davewiner.xml
This renders an RSS feed, probably generated by FeedLand, as a linkblog.
It's how the Links panel on Scripting News is rendered, and also how we do the linkblog panel for Drummer blogs.
The Feeder app has become a pretty useful tool, it's a good place to put code for rendering feeds that's needed for browser-based apps. ;-)
New call -- /returnlinkblogday
Example of call --
http://feeder.scripting.com/returnlinkblog?feedurl=http://data.feedland.org/feeds/davewiner.xml
We return the HTML text you'd display if you wanted to display the links for the current day, as we do in the nightly email.
I needed a place to test this code before including it in the server app.
Increasingly that's a role the Feeder app is taking on. A nice development testbed for feed renderings built on the reallysimple package.
Note if you want a full linkblog-style rendering, use the endpoint I added on the 20th, returnlinkbloghtml.
Return text/plain with charset=utf-8.
Add /returnmarkdown endpoint.
Included the mailbox template, also documented it.
A new template, jsonify.
Two new values returned in serverConfig --
feedUrl -- the url of the feed we're asking you to render
ctSecs -- how many seconds it took to read the feed
Mopping up, fixing little things. Today's project is to write docs for the Hello World template.
the helloworld template
it's in the templates folder
here's how you access it
http://feeder.scripting.com/?template=helloworld&feedurl=http%3A%2F%2Fscripting.com%2Frss.xml
have a look at the template source.
i made it as simple as possible, but I did use jQuery. It wasn't worth the time imho to figure out how to not use jQuery. ;-)
The next step is to do a bit of docs. Need a fresh start for that.
And then I want to get some people reviewing this stuff. I don't want all the suggestions to come two months from now.
We still have a lot of ground to cover, this is just the beginning.
feeder now supports templates, so it's easy to add a new way to view a feed.
here's an example. I implemented the mailbox viewer as a template, it was previously a built-in command.
http://feeder.scripting.com/?template=mailbox&url=https://fallows.substack.com/feed
there's a viewers subfolder, to add a template named hello, you'd add a file hello.html to the folder.
before serving the text, we do some macro substitutions, with the title of the feed, the name and version number of the feeder app, and most important, a JSON structure with the contents of the feed as produced by the reallysimple package.
next step -- write a hello world template and document it. this will be clearer when that's provided.
still feeder is just a testbed. these templates will become applications in their own right.
Include the charset in the content-type header when returning JSON and XML.
We now keep a stats.json file, with info on number of reads, errors, and reads per feed.
I need this functionality for the reallysimple project.
This predates the package, it's basically where it was developed.
So I rewrote it to use the package.