If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

gAjax RSS Feeds Displayer v2.1 - Atom feeds arent shown

I was use old version of gAjax RSS Feeds Displayer (that used Google's Ajax Feed API to host) and then Atom and RSS feeds worked fine. I updated the script to v2.1 (using Yahoo YQL to host) but it cant fetching ATOM feeds. I tried a few ATOM feed URLs, but diplaying only blank area, also retrieving icon doesnt seems. The script only displaying RSS feeds, but not ATOM feeds like old versions. How can i fetch and display ATOM feeds with this script?

OK, I had a heck of a time finding an atom feed to test this on. Seems a lot of them are going out of business. But if you have valid ones (test that by going direct to them in the browser to see if they show up), this may work, or it may need further tweaking. It worked on the two ATOM feeds I tested it on. Their structures were pretty different. I also studied the W3C standards for ATOM to clarify any ambiguities. First use this updated version of the script:

The usage is the same whether you want to use ATOM or RSS or a combination of both or either, with one IMPORTANT CHANGE. If you have one or more ATOM feeds in a feed grouping (even if it's the only feed in that instance), you must add the feed type to it's instance.addFeed function, like so

If you have any problems let me know. It would be helpful to have a link to your page though so I can see what's happening and can test the feeds that you're using.

NOTE: Some ATOM feeds and some items in a given ATOM feed may use xhtml for the the description with no fallback to plain text or html. For those that do it that way I've included an experimental xhtml object parser routine (the YUI interface turns everything into objects) that's clearly marked in the script. The results it gives are not ideal, but I think they're better than no descriptions at all for those items/feeds - that is if the description field is even desired for that feed. If you would rather have no descriptions for those items, simply comment out the routine or remove it. If on the other hand you would rather have it for some feeds and not others, simply do not include descriptions at all on the ATOM feeds you don't want using it. More fine tuning is possible I suppose. Let me know of any requirements you might have there, I will also update the code if anything of value in this or any other regard strikes me.

Last edited by jscheuer1; 01-20-2017 at 05:27 AM.
Reason: code improvement to attachment

Made some updates, I think you might want to switch to this new version anyway as in addition to adding ATOM and improving how that is handled over the version attached earlier in this thread, it also has some general improvements. The code is a little longer, but most likely makes up for that in efficiency/modularity. From the comments section:

Code:

// Unofficial update Jan 23rd, '17(jscheuer1): Add and improve capability to process ATOM feeds, routines to complete main (title)) links
// from feeds if they're relative, more options and tweak result of limitlength()*, add linktarget to all links in a feed/feed group,
// distribute uneven filterfeed() 'number to show' more evenly, preserve for possible subsequent inits all regex's used on fields and
// feed added via addregexp(), (previously only regex's used on the entire feed were preserved), add feedwritten function. add test to
// see if target div already exists allowing the initial function to be recalled on the same element, tidy up code a bit
// -------------------------------------------------------------------
/* limitlength() still works mostly as originally designed. New options - even if the entry is already short enough, all tags
can still be stripped from the field if a third parameter is set to true, ex:
instance.limitlength(175, 'descriptionfield', true)
Instead of providing a number limit, one can opt for the keyword 'strip'. If one does so, the
result is that tags are stripped from the field but no limit is imposed, ex:
instance.limitlength('strip', 'descriptionfield')
Also, slightly changed is that the test to see if the limit is applied is now the on screen length of the unstripped text,
rather than the unstripped length, which it did before and if done that way could sometimes result in shorter entries
than desired, or unecessary stripping, HTML tags* add no length to text on the screen, but do add a lot to the string
length. By removeing them and replacing non-breaking spaces with spaces, we can get a truer screen length of the text.
* other than images, no way to measure them until they load. They can be set display none or sized in style,
or strippred separately with regex feature.
*/

That last bit on exactly what was done to limitlength() can be removed once the demo page instructions reflect the changes. Here's the script:

Let me know if you see any problems, should be easy to deal with. Oh, and I forgot to mention, though I hope you remember that in the addFeed function, if it's an ATOM feed, the third parameter 'atom' must still be set (as in the original attached script in this thread), ex:

That of course necessitated changing it everywhere else it was used in gfeedfetcher.js. But if it's used elsewhere in other functions in other scripts, as I see it is, it needs to be changed there as well. I did this because publishedDate is already a possible property of a feed, and I didn't want to overwrite it. I also did this with title (feeds[i].title is now feeds[i].dditemtitle), that won't effect how feeds with text titles are read, because you were reading title directly from the feed title without changing it. I created dditemtitle to store the text representation of titles in those ATOM feeds (as they are optionally allowed to and often do) that store their titles as objects in the YUI returned data without overwriting those. It also holds the text title from the other feeds, but as I say, those can still be accessed directly from title as well, as they currently are in the two other scripts. I can go over those two other scripts and make the changes if you like. And double check no other potential glitches from changed nomenclature exist. Most others, if any, would only arise when reading an ATOM feed that's doing something in a way that RSS feeds don't.

I can actually change those other two scripts to make them compatible with either version of gfeedfetcher.js - so they still work with the old version and also with the new.

Last edited by jscheuer1; 01-31-2017 at 04:22 PM.
Reason: add last line