by Phil 'iwonder' Guerra
- (Mission, KS) - Here's a bit of something I ran across while looking into a question about DNN and whether or not it supports podcasts. First, out of the box, DNN will support podcast with only the XML/XSL module, and you'll need a custom xsl to do it.
Secondly, the presentation and results vary by browser. I created a custom xsl that enables presentation of the information in a newsfeed that point (links) to the actual podcast, which is usually an mp3 or video file of some sort. It's pretty straightforward transformation of the enclosure element, which contains a URL, type, and size. All 3 attributes are important as there are some issues with downloading that content for some browsers, at least that's the case when IE7 is used. Firefox did not have a problem, but I ran into issues when I used IE7. Why?
Well, it took some googling, but here's a link to the secret, IE7 has a 'limit' on the size it will allow to be downloaded. No file larger than 15MB on servers that do not support HTTP range requests. Since, I'm using a test environment built on Windows XP, and using IIS v5.0, I'm not sure if that's the real problem or not. I'll toss the custom XSL I created to test and show how I'm doing this for a particular site, DNN Creative DotNetNuke Podcasts and give me feedback. (I don't have a public DNN website, it's a matter of controlling my expenses, which is why I blog freely.)
Anyway, using FireFox, tells me that DNN will support presentation of news feeds that include podcasts, and that's the good news.
Here's an example XSL to use with the DNN XML/XSL module to present the DNNCreative Podcast newsfeed. Just a couple notes:
1) I'm not advocating adding the ability to include enclosures wholesale on a website. There are a number of security issues with doing so. I provide this example as quick 'how-to' not as a reccommended practice. Above all know your newssource and test on a non-production site to aovid issues.
2) This example was specifically built to transform the DNN Creative DotNetNuke Podcast feed. As such, you would have to modify it for any other use. Also, feeds change formats from time to time, so it may not always work. However, if you are seriously considering doing this type of thing, you'll need to be more than a novice with XML and XSL to get the most of this type of transformation.
3) To use this code, cut and paste it into a text file using a simple text editor. Save it as PodcastEnabled.xsl, and then upload it to you site during the setup conversation of a DNN XML/XSL module. I know the formatting of this code is less than desireable, but that's a function of my blogger app, so sorry. If you have a lot of problems with the xsl example, leave a comment and I'll go over it.
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:wfw="http://wellformedweb.org/CommentAPI/"
xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/"
xmlns:media="http://search.yahoo.com/mrss/"
xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd"
xmlns:feedburner="http://rssnamespace.org/feedburner/ext/1.0" >
<xsl:output method="xml" omit-xml-declaration="yes" indent="yes"/>
<!-- phil 'iwonder' guerra - PodcastEnabled.xsl - custom xsl for DnnCreative Podcasts -->
<xsl:template match="/">
<div>
<xsl:apply-templates select="rss/channel"/>
</div>
</xsl:template>
<xsl:template match="rss/channel">
<xsl:apply-templates select="item"/>
</xsl:template>
<xsl:template match="item">
<xsl:variable name="item_link" select="link"/>
<xsl:variable name="podlink" select="enclosure/@url"/>
<xsl:variable name="podmedia" select="enclosure/@type"/>
<xsl:variable name="altmedia" select="feedburner:origLink"/>
<xsl:variable name="item_title" select="description"/>
<div class="rssItemDescription">
<xsl:value-of select="description" disable-output-escaping="yes"/>
</div>
<div class="rssItemSub">
<xsl:if test="enclosure/@url">
<a href="{$podlink}">Listen Now</a> (<xsl:value-of select="$podmedia"/> - Size <xsl:value-of select="enclosure/@length"/>)<br></br>
</xsl:if>
<xsl:if test="not(enclosure/@url)">
<a href="{$altmedia}">See the Video</a>
</xsl:if>
(<xsl:value-of select="pubDate"/>) <hr/>
</div>
</xsl:template>
</xsl:stylesheet>
Tuesday, December 30, 2008
Wednesday, December 24, 2008
Useful Site Links for RSS Info
by Phil 'iwonder' Guerra
--- (Mission, KS) - I've been asked about how one goes about learning about RSS in general, and how to learn more about DNN's usage of it. I'll post some links to sites, posts, and articles, I've found useful for folks from novice to advanced. Again, links change so frequently, just drop me a comment, or email if one goes sour.
DNN Creative - DNN and RSS content - Lee Sykes developed this site years back. He has a lot of information on RSS and DNN. Some content is free, while other is available via subscription. At last check the RSS information was still free, with some of it culled from DNN forums and smartly organized by Lee. Good info all around for RSS, a nice tutorial for newbies. Although, many of the examples are using the older RSS module, the basic info about RSS is still relevant.
RSS and Atom Specifications
If you are going to work with RSS, you'll want to examine the following sites, which speak to the actual specifications for RSS. DNN, currently uses RSS internally, and the new module is supposed to seamlessly support various RSS specifiations, but as I've mentioned before there are quite a few 'gotchas'. Whenever I'm in doubt about a particular news source's implementation, I refer to these sites for reference.
Now, truthfully, there is wide disagreement over which spec and version to adopt. In the end, the choice as a developer is up to you. The only thing that really matters is that you take the time to follow the specs. Nothing is worse than a feed that says it's a certain RSS or Atom feed implementation, and then does not follow the defined specs.
RSS v2.0 Specifications - Official RSS Advisory Board - The keeper of the specification changed, but the information is the same. Here on this site is a wealth of information about RSS v2.0, including samples, and explainations of the specification. If you are a developer writing a news generator for RSS v2.0, you really have no excuse for not learning all you can, which includes all of the information about what is and what is not valid usage. If you are using RSS newfeeds, you really need to understand the specification to get the most use out of any newsfeed that utilizes RSS v2.0. Other versions of RSS are archived and linked from this site, as well.
Atom v1.0 - This document specifies Atom, an XML-based Web content and metadata syndication format. It's not the user friendly format site, but the RFC document. Again, this spec should be something you know to get the most out of any Atom feed.
Atom Enabled v0.3 and v1.0 - This is a nice site with loads of information. Not as dry as the RFC, but I refer to it becuase it, also, describes the protocol for the publishing world.
Custom Namespaces
Namespace references are utilized within newsfeeds to extend the RSS version specifications. As RSS has evolved, the specs originally conceived with RSS could not envision the many usages that syndication adopters needed. The ability to extend the specifications was a way to offer the ability to allow for the future. Take a look at the source of your newsfeed, and I'd bet you'll find a custom namespace thrown in to use some custom xml tag contained in it. Just like the RSS specs, by definition a custom namespace needs a reference for developers to understand what is and isn't allowed. Most news readers will check the specs and fail to present any unknown tags or invalid usage. It isn't always clear cut, but understanding these custom tags begins with knowing about their implementation.
Dublin Core (DC) - The document in this link summarizes the updated definitions for the Dublin Core metadata elements as originally defined in [RFC2413]. These new definitions will be officially known as Version 1.1. The tags defined are used quite frequently in the more popular newsfeeds.
Newsfeed Validation
Many times you wonder about a news feed source. Especially, using DNN's latest version, which gives almost no worthwhile information if a feed fails. Just getting a 'download error' message does you no good. So, how can you tell what's going on? Well, as Ian Anderson from Jethro Tull proclaimed 'Nothing Is Easy'. If you continue to run into issues. One step I highly recommend is to validate your newsfeed source. You'll get an idea of the kind of errors that are likely to be thrown by a 'good' newsfeed reader.
W3C Feed Validation Service, for Atom and RSS - There are more than a couple of sites that allow validation on-line, and this is the one I use most often. The site pointed to in the above link is useful for Atom and RSS.
--- (Mission, KS) - I've been asked about how one goes about learning about RSS in general, and how to learn more about DNN's usage of it. I'll post some links to sites, posts, and articles, I've found useful for folks from novice to advanced. Again, links change so frequently, just drop me a comment, or email if one goes sour.
DNN Creative - DNN and RSS content - Lee Sykes developed this site years back. He has a lot of information on RSS and DNN. Some content is free, while other is available via subscription. At last check the RSS information was still free, with some of it culled from DNN forums and smartly organized by Lee. Good info all around for RSS, a nice tutorial for newbies. Although, many of the examples are using the older RSS module, the basic info about RSS is still relevant.
RSS and Atom Specifications
If you are going to work with RSS, you'll want to examine the following sites, which speak to the actual specifications for RSS. DNN, currently uses RSS internally, and the new module is supposed to seamlessly support various RSS specifiations, but as I've mentioned before there are quite a few 'gotchas'. Whenever I'm in doubt about a particular news source's implementation, I refer to these sites for reference.
Now, truthfully, there is wide disagreement over which spec and version to adopt. In the end, the choice as a developer is up to you. The only thing that really matters is that you take the time to follow the specs. Nothing is worse than a feed that says it's a certain RSS or Atom feed implementation, and then does not follow the defined specs.
RSS v2.0 Specifications - Official RSS Advisory Board - The keeper of the specification changed, but the information is the same. Here on this site is a wealth of information about RSS v2.0, including samples, and explainations of the specification. If you are a developer writing a news generator for RSS v2.0, you really have no excuse for not learning all you can, which includes all of the information about what is and what is not valid usage. If you are using RSS newfeeds, you really need to understand the specification to get the most use out of any newsfeed that utilizes RSS v2.0. Other versions of RSS are archived and linked from this site, as well.
Atom v1.0 - This document specifies Atom, an XML-based Web content and metadata syndication format. It's not the user friendly format site, but the RFC document. Again, this spec should be something you know to get the most out of any Atom feed.
Atom Enabled v0.3 and v1.0 - This is a nice site with loads of information. Not as dry as the RFC, but I refer to it becuase it, also, describes the protocol for the publishing world.
Custom Namespaces
Namespace references are utilized within newsfeeds to extend the RSS version specifications. As RSS has evolved, the specs originally conceived with RSS could not envision the many usages that syndication adopters needed. The ability to extend the specifications was a way to offer the ability to allow for the future. Take a look at the source of your newsfeed, and I'd bet you'll find a custom namespace thrown in to use some custom xml tag contained in it. Just like the RSS specs, by definition a custom namespace needs a reference for developers to understand what is and isn't allowed. Most news readers will check the specs and fail to present any unknown tags or invalid usage. It isn't always clear cut, but understanding these custom tags begins with knowing about their implementation.
Dublin Core (DC) - The document in this link summarizes the updated definitions for the Dublin Core metadata elements as originally defined in [RFC2413]. These new definitions will be officially known as Version 1.1. The tags defined are used quite frequently in the more popular newsfeeds.
Newsfeed Validation
Many times you wonder about a news feed source. Especially, using DNN's latest version, which gives almost no worthwhile information if a feed fails. Just getting a 'download error' message does you no good. So, how can you tell what's going on? Well, as Ian Anderson from Jethro Tull proclaimed 'Nothing Is Easy'. If you continue to run into issues. One step I highly recommend is to validate your newsfeed source. You'll get an idea of the kind of errors that are likely to be thrown by a 'good' newsfeed reader.
W3C Feed Validation Service, for Atom and RSS - There are more than a couple of sites that allow validation on-line, and this is the one I use most often. The site pointed to in the above link is useful for Atom and RSS.
Useful Developer Tools
by Phil 'iwonder' Guerra
--- (Mission, KS) - In this blog entry, I'll list some of the tools I use in working with XML and DNN. Due to the fast changing world of the internet, not all links my work, but at the time of this posting, all were functioning. I don't get paid for this kind of endorsement, so don't hound me, if you don't find the tool useful, or if you run into problems with using it. I can't offer any tutorials on them - because as my friend, Morris 'Uncle' Milton would say, 'Like man it's free!'.
1) PFE32 - Basic Text Editor - I use it because it's much handier than any other ascii text editor, including NotePad.
2) Xselerator - XML/XSL Debugging Tool - This is one great tool for developing and debugging XML and XSL. It used to be a free 30 day trial, but now is an open source project. Even if this tool cost money, I would recommend getting it. I use it most everyday. It's available at Sourceforge, so get it as soon as you can.
That's all for now. I'll post more as I think about it.
--- (Mission, KS) - In this blog entry, I'll list some of the tools I use in working with XML and DNN. Due to the fast changing world of the internet, not all links my work, but at the time of this posting, all were functioning. I don't get paid for this kind of endorsement, so don't hound me, if you don't find the tool useful, or if you run into problems with using it. I can't offer any tutorials on them - because as my friend, Morris 'Uncle' Milton would say, 'Like man it's free!'.
1) PFE32 - Basic Text Editor - I use it because it's much handier than any other ascii text editor, including NotePad.
2) Xselerator - XML/XSL Debugging Tool - This is one great tool for developing and debugging XML and XSL. It used to be a free 30 day trial, but now is an open source project. Even if this tool cost money, I would recommend getting it. I use it most everyday. It's available at Sourceforge, so get it as soon as you can.
That's all for now. I'll post more as I think about it.
How to Find the RSS Version of Your Feed
by Phil 'iwonder' Guerra
(Mission, KS) --- Ok, lets talk about some basics. In the best of all worlds, when you setup a newsfeed using the DNN News Feeds (RSS) module, there should be a display of basic RSS feed info to help you understand the type of feed you have, in case you have to troubleshoot it. Now, for the real world. The module only gives you an error message when setting up the feed after you've set it up, and the feed is accessed. If a feed has trouble, you usually, just get an error message - ya, know the one 'Download Error'. Of course, this gives you nothing to go on. What's up? What can you do to investigate and fix the problem? Well, in my real world, I take these approach.
Let's start from square one...
1) Always, use a browser first to check a newsfeed for accessibility, and to determine what version of RSS is being used. You'll save yourself a lot of time, if you take this fist step before setting it up in DNN. I know you shouldn't have to do this type of thing, but believe me, this is the real world side of RSS syndication, not just DNN news syndication presentation.
If you can't get the feed to display in your browser, it has no chance of displaying in DNN, because the module code basically does a download of the feed in a similar manner, though there are some differences behind the scenes.
2) Next, examine the feed news source by using your browser's 'View Source' feature'. The way to do it, depends on the browser being used, though. Using MS IE, just right click while on the content of the page, and your default text editor will display the info. Using FireFox, right click and choose 'View Page Source'. In both these scenarios, the display of the source will largely be unformatted and difficult to decipher. I select all of the text and copy it. Then, I paste it into either my prefferred text editor, PFE32, or in Xselerator (both indespensible tools). With xslerator, I can use the 'tidy' button to display the feed in better fashion.
3) I examine the source looking at the xml tag that defines the RSS version, and has information about any custom namespaces that may be used in to define tags beyond the default RSS version tags. This part is extremely importand when troubleshooting DNN RSS news module setups. The information of interest looks something like this example:
<?xml-stylesheet href="http://www.blogger.com/styles/atom.css" type="text/css"?><feed xmlns='http://www.w3.org/2005/Atom' xmlns:openSearch='http://a9.com/-/spec/opensearchrss/1.0/'>
In the example, we see that the feed is an RSS Atom v1.0 feed and uses a custom namespace defined in the Atom namespace.
Another example, this one is from USAToday, and it says it's an RSS v2.0. Note there are 2 custom namespaces used in the feed. One signals it is an RSS v2.0 Feedburner type of feed, and the other calls Microsoft's custom namespace cf. Both, types of namespaces will have tags that are not used in the DNN News Feeds (RSS) module. Although, both are available for use and are syntactically correct.
<?xml version="1.0" encoding="UTF-8"?><rss
xmlns:feedburner="http://rssnamespace.org/feedburner/ext/1.0" xmlns:cf="http://www.microsoft.com/schemas/rss/core/2005" version="2.0">
Lastly, though not finally, as there many varieties of news feeds, is the OPML feed. This type of feed is really just a directory style listing of links assembled using the OPML spec, which is a fancy type of XML, as are all newsfeeds. Note, this spec hasn't changed much since it was introduced.
<?xml version="1.0" encoding="UTF-8" ?>
<opml version="1.1">
The above are the 3 most likely types of newsfeeds you'll encounter, although each has a variety of flavors depending on the news source provider. All of these basic types of news feeds are supposed to be supported with the new DNN news module, but there are a lot of gotchas along the way. I'll blog about those in another entry.
4) Again, while using Xselerator, I pull in the default xsl file from DNN, and use the 'green arrow' to translate the feed using the xsl. Now, if all is well, then the feed will display, provided I've set up the necessary paramters for the example with the DNN params used in the RSS module. If the feed does not work, it isn't going to display in DNN, but you're not done. The sad fact is - it may still fail after setting it up in DNN giving you a download error, due to a variety of problems. Notwithstanding, incorrect formatting, missing attributes, or the RSS version is not supported.
5) Validate your news feed source. A newfeed validation service allows you to get a better idea of what kind of errors are being encountered. Most feeds you encounter are going to be either RSS flavored or Atom flavored, and the validation service I find most useful is the W3C Feed Validation Service, for Atom and RSS. This is a very important step, as DNN is going to be more strict about newsfeeds following specifications, even though their internal implementation that generates newsfeed doesn't alway comply either. Strange huh!.
Keep in mind that browsers are a lot more forgiving when they present newsfeeds, and that really has to do more with the differences in a browser application and a web framework like DNN. The browsers are more capable of sanitizing and converting newsfeeds into an acceptable presentation. Why? Well, it's a difficult task to judge a newsfeed's implementation.
The biggest problem with DNN's latest module is attempting to allow aggregation of newsfeeds that use different formats. The idea was interesting, but unfortunately, the process is much too failure prone to be useful. My feeling is that the DNN News Feed (RSS) module needs to forget about being an aggregator altogether, or at least allow only similar formatted newsfeeds sources in any one aggregation. Prior to the latest module's introduction, a very workable aggregator was available with the News Explorer module. Unfortunately, now this is broken.
Now, I know this is a bare bones approach without much in the way of a tutorial, but I don't have a lot of time today, so if you're interested in knowing more, leave a comment, and I'll expand on the topic.
Look for a 'Useful Developer Tools' Blog entry for short descriptions and links to developer tools I use, and why.
(Mission, KS) --- Ok, lets talk about some basics. In the best of all worlds, when you setup a newsfeed using the DNN News Feeds (RSS) module, there should be a display of basic RSS feed info to help you understand the type of feed you have, in case you have to troubleshoot it. Now, for the real world. The module only gives you an error message when setting up the feed after you've set it up, and the feed is accessed. If a feed has trouble, you usually, just get an error message - ya, know the one 'Download Error'. Of course, this gives you nothing to go on. What's up? What can you do to investigate and fix the problem? Well, in my real world, I take these approach.
Let's start from square one...
1) Always, use a browser first to check a newsfeed for accessibility, and to determine what version of RSS is being used. You'll save yourself a lot of time, if you take this fist step before setting it up in DNN. I know you shouldn't have to do this type of thing, but believe me, this is the real world side of RSS syndication, not just DNN news syndication presentation.
If you can't get the feed to display in your browser, it has no chance of displaying in DNN, because the module code basically does a download of the feed in a similar manner, though there are some differences behind the scenes.
2) Next, examine the feed news source by using your browser's 'View Source' feature'. The way to do it, depends on the browser being used, though. Using MS IE, just right click while on the content of the page, and your default text editor will display the info. Using FireFox, right click and choose 'View Page Source'. In both these scenarios, the display of the source will largely be unformatted and difficult to decipher. I select all of the text and copy it. Then, I paste it into either my prefferred text editor, PFE32, or in Xselerator (both indespensible tools). With xslerator, I can use the 'tidy' button to display the feed in better fashion.
3) I examine the source looking at the xml tag that defines the RSS version, and has information about any custom namespaces that may be used in to define tags beyond the default RSS version tags. This part is extremely importand when troubleshooting DNN RSS news module setups. The information of interest looks something like this example:
<?xml-stylesheet href="http://www.blogger.com/styles/atom.css" type="text/css"?><feed xmlns='http://www.w3.org/2005/Atom' xmlns:openSearch='http://a9.com/-/spec/opensearchrss/1.0/'>
In the example, we see that the feed is an RSS Atom v1.0 feed and uses a custom namespace defined in the Atom namespace.
Another example, this one is from USAToday, and it says it's an RSS v2.0. Note there are 2 custom namespaces used in the feed. One signals it is an RSS v2.0 Feedburner type of feed, and the other calls Microsoft's custom namespace cf. Both, types of namespaces will have tags that are not used in the DNN News Feeds (RSS) module. Although, both are available for use and are syntactically correct.
<?xml version="1.0" encoding="UTF-8"?><rss
xmlns:feedburner="http://rssnamespace.org/feedburner/ext/1.0" xmlns:cf="http://www.microsoft.com/schemas/rss/core/2005" version="2.0">
Lastly, though not finally, as there many varieties of news feeds, is the OPML feed. This type of feed is really just a directory style listing of links assembled using the OPML spec, which is a fancy type of XML, as are all newsfeeds. Note, this spec hasn't changed much since it was introduced.
<?xml version="1.0" encoding="UTF-8" ?>
<opml version="1.1">
The above are the 3 most likely types of newsfeeds you'll encounter, although each has a variety of flavors depending on the news source provider. All of these basic types of news feeds are supposed to be supported with the new DNN news module, but there are a lot of gotchas along the way. I'll blog about those in another entry.
4) Again, while using Xselerator, I pull in the default xsl file from DNN, and use the 'green arrow' to translate the feed using the xsl. Now, if all is well, then the feed will display, provided I've set up the necessary paramters for the example with the DNN params used in the RSS module. If the feed does not work, it isn't going to display in DNN, but you're not done. The sad fact is - it may still fail after setting it up in DNN giving you a download error, due to a variety of problems. Notwithstanding, incorrect formatting, missing attributes, or the RSS version is not supported.
5) Validate your news feed source. A newfeed validation service allows you to get a better idea of what kind of errors are being encountered. Most feeds you encounter are going to be either RSS flavored or Atom flavored, and the validation service I find most useful is the W3C Feed Validation Service, for Atom and RSS. This is a very important step, as DNN is going to be more strict about newsfeeds following specifications, even though their internal implementation that generates newsfeed doesn't alway comply either. Strange huh!.
Keep in mind that browsers are a lot more forgiving when they present newsfeeds, and that really has to do more with the differences in a browser application and a web framework like DNN. The browsers are more capable of sanitizing and converting newsfeeds into an acceptable presentation. Why? Well, it's a difficult task to judge a newsfeed's implementation.
The biggest problem with DNN's latest module is attempting to allow aggregation of newsfeeds that use different formats. The idea was interesting, but unfortunately, the process is much too failure prone to be useful. My feeling is that the DNN News Feed (RSS) module needs to forget about being an aggregator altogether, or at least allow only similar formatted newsfeeds sources in any one aggregation. Prior to the latest module's introduction, a very workable aggregator was available with the News Explorer module. Unfortunately, now this is broken.
Now, I know this is a bare bones approach without much in the way of a tutorial, but I don't have a lot of time today, so if you're interested in knowing more, leave a comment, and I'll expand on the topic.
Look for a 'Useful Developer Tools' Blog entry for short descriptions and links to developer tools I use, and why.
Thursday, December 11, 2008
Feed Explorer Broken...
by Phil 'iwonder' Guerra
(Mission, KS) --- I've been using the Feed Explorer module for a bit, so I'm ok with how to set it up and some of the nuances and other tricks using it. However, while investigating an issue for someone else, I've found that there is a problem with it. The Feed Explorer module seems to be busted in v04.09.00 and in v.05.00 rc. I lose the tabs whenever I change the settings for the Feed Explorer's Content Source option. I have to delete the module and recreate it to see them again. Further, this means that I cannot use it for anything other than the default configuration, which is - how do I say it? Very Bogus.
So, it would be helpful to have a Forum for this module, since it is a seperate module, and one that comes with the default setup of DNN. BTW, does anyone else see the same thing in their dnn v04.09.00 and up installs? Losing tabs and inability to configure the module without breaking it.
I did not notice this issue for so long, mainly because I've been so focused on the new release of the News module. Unfortunately, my preference at this stage is to use the Feed Explorer module for situations where I need to aggregate feeds, because I don't like the way that the News modules does it. Now, with this latest issue, I can't use it for DNN sites using versions above v04.06. Hope we can get it fixed soon.
(Mission, KS) --- I've been using the Feed Explorer module for a bit, so I'm ok with how to set it up and some of the nuances and other tricks using it. However, while investigating an issue for someone else, I've found that there is a problem with it. The Feed Explorer module seems to be busted in v04.09.00 and in v.05.00 rc. I lose the tabs whenever I change the settings for the Feed Explorer's Content Source option. I have to delete the module and recreate it to see them again. Further, this means that I cannot use it for anything other than the default configuration, which is - how do I say it? Very Bogus.
So, it would be helpful to have a Forum for this module, since it is a seperate module, and one that comes with the default setup of DNN. BTW, does anyone else see the same thing in their dnn v04.09.00 and up installs? Losing tabs and inability to configure the module without breaking it.
I did not notice this issue for so long, mainly because I've been so focused on the new release of the News module. Unfortunately, my preference at this stage is to use the Feed Explorer module for situations where I need to aggregate feeds, because I don't like the way that the News modules does it. Now, with this latest issue, I can't use it for DNN sites using versions above v04.06. Hope we can get it fixed soon.
Monday, December 1, 2008
How To Get Help on the DNN Forums
by Phil 'iwonder' Guerra
- (Mission, KS) I know this may sound trivial, but the question gets asked many times, so I thought, it would be worthwhile to revisit the approach I find works best for me. Hope it works for you too!
1. Search for a key phrase. There may be an answer to your issue already out in the ether-land. Try using your favorite search engine and enter a key phrase or keywords to check for other posts or information. Not all hits apply to your specific issue, but it gives a head start on how to zero in on a solution. You just may find a resource that can help, or that your issue is already answered, which means you don't have to duplicate it on the official DNN forums.
2. Include Environment Specifics. It's extremely helpful to those anwering posts for help to know the environment details when you encounter an issue. For example, include the following:
- DNN version
- Operating System (i.e. XP Pro, Server 2003, or whatever you are using)
- Database Info - SQL2005, SQLExpress or whatever.
- Hosted or Non-hosted setup. Is this a test private setup or hosted by an outside vendor?
- Module versions. It really helps to know the module version being used.
- Brief error description, doesn't have to be everything that is dumped to the screen, just the meat without the fat.
3 Keep posts friendly. The DNN forums is not a profit-organization, it's maintained by volunteers, and most often the folks answering are willing to help, and are not getting paid. The folks that respond do so because they are committed to the project.
4. Review Existing Posts and Bug Issues. A lot of issues are tracked in the official bug tracker or can be seen as items on a project's road map. While it may take time to go through the posts, it doesn't help to duplicate posts with reporting similar issues. Duplicates only add to the number of posts others have to review. Again, responders tend to want to answer once, and expect folks to look for the help already offerred.
5. Pay It Forward. If you can help answer a post question, do so. Remember it's a community. Give your expertise to further the project.
6. Be Patient. Responders have their priorities as well. Understand folks will help, but it may take some time to duplicate and test the issue you report.
7. Keep On Subject. Resist the urge to hijack a thread with non-relevant comments. If you have positive responses to aid in the solution, add the information, otherwise, keep it real.
8. Say When. If your issue is resolved, say so, and mark the issue answered. Always give thanks to the folks that helped, they will appreciate it.
- (Mission, KS) I know this may sound trivial, but the question gets asked many times, so I thought, it would be worthwhile to revisit the approach I find works best for me. Hope it works for you too!
1. Search for a key phrase. There may be an answer to your issue already out in the ether-land. Try using your favorite search engine and enter a key phrase or keywords to check for other posts or information. Not all hits apply to your specific issue, but it gives a head start on how to zero in on a solution. You just may find a resource that can help, or that your issue is already answered, which means you don't have to duplicate it on the official DNN forums.
2. Include Environment Specifics. It's extremely helpful to those anwering posts for help to know the environment details when you encounter an issue. For example, include the following:
- DNN version
- Operating System (i.e. XP Pro, Server 2003, or whatever you are using)
- Database Info - SQL2005, SQLExpress or whatever.
- Hosted or Non-hosted setup. Is this a test private setup or hosted by an outside vendor?
- Module versions. It really helps to know the module version being used.
- Brief error description, doesn't have to be everything that is dumped to the screen, just the meat without the fat.
3 Keep posts friendly. The DNN forums is not a profit-organization, it's maintained by volunteers, and most often the folks answering are willing to help, and are not getting paid. The folks that respond do so because they are committed to the project.
4. Review Existing Posts and Bug Issues. A lot of issues are tracked in the official bug tracker or can be seen as items on a project's road map. While it may take time to go through the posts, it doesn't help to duplicate posts with reporting similar issues. Duplicates only add to the number of posts others have to review. Again, responders tend to want to answer once, and expect folks to look for the help already offerred.
5. Pay It Forward. If you can help answer a post question, do so. Remember it's a community. Give your expertise to further the project.
6. Be Patient. Responders have their priorities as well. Understand folks will help, but it may take some time to duplicate and test the issue you report.
7. Keep On Subject. Resist the urge to hijack a thread with non-relevant comments. If you have positive responses to aid in the solution, add the information, otherwise, keep it real.
8. Say When. If your issue is resolved, say so, and mark the issue answered. Always give thanks to the folks that helped, they will appreciate it.
Saturday, November 8, 2008
Why No Standard DNN Module RSS Generator?
by Phil 'iwonder' Guerra
(Mission, KS) - Ok, I'm bringing up a old can of worms, I admit straight away, but it's a topic that really gives me a royal pain in the a**. Of all the support questions I get about DNN and news feeds the one that seems to always at the top of the list: 'Why does the newsfeed module fail to render my site's syndicated content?' Well, the answer depends on which module you are using and how the syndicated content is generated.
A long time ago, in a far-away galaxy, I was a member of the DNN Core Team, and ever so briefly was the News Feeds (RSS) project's Team Leader. In that capacity, one of the first assignments I tackled was to begin the process of improving the internal RSS syndication methods. Now, the difficulty here was that the syndication process is tied to the internal search mechanism, which we all know by now, is constantly changing, and seems to never work the way you would suppose it to work. That being said, I could only address the internal process in a very controlled and limited way. I could improve certain aspects, but adding needed features, including the use of custom namespaces was vetoed. The wisdom of the sages was at a point in DNN evolution that wanted to delay these efforts as not to 'break' anything that would negatively impact the spread of DNN to bigger and larger stakeholders. It was probably a wise choice not to let some newbie upstart impact such a central area of DNN.
Now, the ages pass, and DNN is firmly established as a well known and well received entity among the large and respected houses of the Internet applications world. Maybe, it's time to wonder about why there is no standard RSS syndication generation API that is required by all DNN projects. Some projects have gone their own way with generating syndicated content for their projects, while others just use the in-bred methods. Which is best? In a word, neither!
The losers in all of this patchwork of syndication generation is the DNN community at large, who probably don't even realize that the ability to transform and present syndicated content varies with which module and version is being used. Of course, this most often shows up when the poor RSS Newsfeeds (RSS) module is being used by folks expecting things to work correctly out of the box. Sorry Virginia, but the DNN Santa Claus is not well and won't be addressing your needs in this version! There simply is no guarantee that the default news module will present your DNN site's syndicated content. In fact, even so-called improved custom RSS generators contained in some project modules do not even adhere to the syndicated format specs they supposedly follow.
Just like other non-DNN syndicated content, the appearance of a a specs version in the feed does not always guarantee that the spec used is faithfully followed. Elements like dates, author, and others my not follow the spec used and it's up to the consumer or their application to make provision for any errors in syndication. Pretty terrible situation. Imagine if you had the same lack of conformity with the automobile manufactures.
I come from the old school that requires no negative opposition to existing methods and procedures without presenting plausible alternate solutions. So, here's my plausible alternative.
DNN should commit to syndication method that holds developers to using it. In the simpliest transition possible, there could be at minimum, an indentification tag added to their custom methods that indicate which rss generator is being used. In RSS specs there exists an optional channel element tag 'generator', which can effectively identify at bare minimum something like this:
<generator>DNN v4.0.9 Internal RSS Syndication Generator v1.0.x<\generator>
or
<generator>DNN Blog v4.0.x Custom RSS Syndication Generator v2.0.x<\generator>
Inclusion of this information would at least help those who provide 'FREE' support for the benefit of the DNN community a way to quickly troubleshoot the issues being reported daily. Some of us do support and help the DNN community because we believe in the open source project. Can't the DNN Core Team and DNN Corporate members take this small step? We will see.
I'm not even going to go into what improvements in the internal syndication methods are needed, but would love to provide my views sometime when someone is actually going to listen.
(Mission, KS) - Ok, I'm bringing up a old can of worms, I admit straight away, but it's a topic that really gives me a royal pain in the a**. Of all the support questions I get about DNN and news feeds the one that seems to always at the top of the list: 'Why does the newsfeed module fail to render my site's syndicated content?' Well, the answer depends on which module you are using and how the syndicated content is generated.
A long time ago, in a far-away galaxy, I was a member of the DNN Core Team, and ever so briefly was the News Feeds (RSS) project's Team Leader. In that capacity, one of the first assignments I tackled was to begin the process of improving the internal RSS syndication methods. Now, the difficulty here was that the syndication process is tied to the internal search mechanism, which we all know by now, is constantly changing, and seems to never work the way you would suppose it to work. That being said, I could only address the internal process in a very controlled and limited way. I could improve certain aspects, but adding needed features, including the use of custom namespaces was vetoed. The wisdom of the sages was at a point in DNN evolution that wanted to delay these efforts as not to 'break' anything that would negatively impact the spread of DNN to bigger and larger stakeholders. It was probably a wise choice not to let some newbie upstart impact such a central area of DNN.
Now, the ages pass, and DNN is firmly established as a well known and well received entity among the large and respected houses of the Internet applications world. Maybe, it's time to wonder about why there is no standard RSS syndication generation API that is required by all DNN projects. Some projects have gone their own way with generating syndicated content for their projects, while others just use the in-bred methods. Which is best? In a word, neither!
The losers in all of this patchwork of syndication generation is the DNN community at large, who probably don't even realize that the ability to transform and present syndicated content varies with which module and version is being used. Of course, this most often shows up when the poor RSS Newsfeeds (RSS) module is being used by folks expecting things to work correctly out of the box. Sorry Virginia, but the DNN Santa Claus is not well and won't be addressing your needs in this version! There simply is no guarantee that the default news module will present your DNN site's syndicated content. In fact, even so-called improved custom RSS generators contained in some project modules do not even adhere to the syndicated format specs they supposedly follow.
Just like other non-DNN syndicated content, the appearance of a a specs version in the feed does not always guarantee that the spec used is faithfully followed. Elements like dates, author, and others my not follow the spec used and it's up to the consumer or their application to make provision for any errors in syndication. Pretty terrible situation. Imagine if you had the same lack of conformity with the automobile manufactures.
I come from the old school that requires no negative opposition to existing methods and procedures without presenting plausible alternate solutions. So, here's my plausible alternative.
DNN should commit to syndication method that holds developers to using it. In the simpliest transition possible, there could be at minimum, an indentification tag added to their custom methods that indicate which rss generator is being used. In RSS specs there exists an optional channel element tag 'generator', which can effectively identify at bare minimum something like this:
or
Inclusion of this information would at least help those who provide 'FREE' support for the benefit of the DNN community a way to quickly troubleshoot the issues being reported daily. Some of us do support and help the DNN community because we believe in the open source project. Can't the DNN Core Team and DNN Corporate members take this small step? We will see.
I'm not even going to go into what improvements in the internal syndication methods are needed, but would love to provide my views sometime when someone is actually going to listen.
Wednesday, November 5, 2008
Forward to the Past
by Phil 'iwonder' Guerra
(Mission, KS) - Well, just a quick note to let folks know that my old fix to the News module actually does work. I can display Atom feeds with my modified News module. Unfortunately, my mod works with the v4.0.0 module, but not the new v4.0.1 version. I'm still trying to understand why. More later, as I step through the code.
(Mission, KS) - Well, just a quick note to let folks know that my old fix to the News module actually does work. I can display Atom feeds with my modified News module. Unfortunately, my mod works with the v4.0.0 module, but not the new v4.0.1 version. I'm still trying to understand why. More later, as I step through the code.
Tuesday, November 4, 2008
News v4.0.1 Not Rendering Atom Feeds...
by Phil 'iwonder' Guerra
(Mission, KS) - Had some time to play around with the new release of the News Module. Unfortunately, this release will not render Atom feeds, at least the many that I tried. I'm getting the all-too-familiar 'failed to download' error.
Just wanted to post about it here, and I'll have to look into the code more. Even the 'fix' I had made prior to this release does not help, so I'm lost at this point as to what the duece is going on.
Ah, well, I'll get to it, in the morning...
(Mission, KS) - Had some time to play around with the new release of the News Module. Unfortunately, this release will not render Atom feeds, at least the many that I tried. I'm getting the all-too-familiar 'failed to download' error.
Just wanted to post about it here, and I'll have to look into the code more. Even the 'fix' I had made prior to this release does not help, so I'm lost at this point as to what the duece is going on.
Ah, well, I'll get to it, in the morning...
Monday, November 3, 2008
Updated News Module Released...
by Phil 'iwonder' Guerra
(Mission, KS) -The update to the News module was released. The new version v04.00.01 fixes some of the reported issues with the initial release.
(Mission, KS) -The update to the News module was released. The new version v04.00.01 fixes some of the reported issues with the initial release.
- Add accept and user agent for web request
- Remove email address constraints
- Add option to not use Ajax rendering in module settings
- Reorganized and rewritten Javascript to allow rendering of multiple News modules on a single page in Ajax mode
- Fix for XHTML issue (div ending with span)
However, you should note that while several issues were fixed, many others persist. Including support of non-standard pubDates, and transformation of Atom feeds. Some will find that their feed still will not download.
The option pending review of these issues and subsequent fixes is to use the XML/XSL module with a custom XSL. This option is not welcome news for novice users, who are inexperienced in writing their own custom xsl transformations.
More on this release as more folks post their issues. My own issue is that the Atom feed for this very blog cannot be rendered by the latest DNN News module. During testing I found some issues with with DNN's method of 'sanitizing and transforming' Atom feeds into RSSv2.0 DNN specific format. I've fixed the issue in my code, but since the release was 'in the tracker' this fix could not be added to the update. That's a sad reality of the way things move in the development world. I didn't have the source to the v04.00.01, so I could not confirm that the issue persisted in that version until today.
Ah, well, all in due time I suppose. Meantime, I'm fixing it in the latest version and will submit it to Peter for review and hopefully inclusion in the next release.
As always, please test any new release in a non-production area. You'll be glad you did.
Saturday, October 4, 2008
SourceForge DNN News Zips
by Phil 'iwonder' Guerra
- (Mission, KS) - In case you need a previous version of the DNN News module, you can still find them at SourceForge. These previous versions are no longer available on the DNNN Downloads page. Thanks to Jan Olsmar for the info. Of course, you could opt to use the XML/XSL module instead, which basically performs the same type of functions as the previous v03.00.xx module.
Some folks are reluctant to move to the new DNN News module due to the 'breaking' issues reported in the forums. My advice for folks is to install a version of the new News module in a test environment ONLY. Then, evaluate the issues BEFORE moving it to Production areas.
If you are using a lot of non-RSSv2.0 newssources with custom XSLs, these will not work with the new module, and you'll need to move the setup information into an XML/XSL module. There is NO backward compatibilty provided with the new module.
All of your newssources will be converted to DNN's custom RSSv2.0 format, which may not include all of the content you may have provided for with a custom XSL. Some newssources are failing due to using non-standard formatting in the pubDate, and author elements. Validation is strictly enforced with DNN v04.00.00 with an XSD. The issues prompted a 'fix' to the code, which will relax the validation requirements. The Beta version is close to release on this fix, however, there may be other issues that are not fixed in this newer release.
So, again, my recommendation:
Install a version of the new News module in a test environment ONLY. Then, evaluate the issues BEFORE moving it to Production areas.
Note: Currently DNN offers downloads on the Codeplex site. Thanks to Sebastian Leupold for the updated information. As of 3/10/2009, the DNN Codeplex site has versions:
- (Mission, KS) - In case you need a previous version of the DNN News module, you can still find them at SourceForge. These previous versions are no longer available on the DNNN Downloads page. Thanks to Jan Olsmar for the info. Of course, you could opt to use the XML/XSL module instead, which basically performs the same type of functions as the previous v03.00.xx module.
Some folks are reluctant to move to the new DNN News module due to the 'breaking' issues reported in the forums. My advice for folks is to install a version of the new News module in a test environment ONLY. Then, evaluate the issues BEFORE moving it to Production areas.
If you are using a lot of non-RSSv2.0 newssources with custom XSLs, these will not work with the new module, and you'll need to move the setup information into an XML/XSL module. There is NO backward compatibilty provided with the new module.
All of your newssources will be converted to DNN's custom RSSv2.0 format, which may not include all of the content you may have provided for with a custom XSL. Some newssources are failing due to using non-standard formatting in the pubDate, and author elements. Validation is strictly enforced with DNN v04.00.00 with an XSD. The issues prompted a 'fix' to the code, which will relax the validation requirements. The Beta version is close to release on this fix, however, there may be other issues that are not fixed in this newer release.
So, again, my recommendation:
Install a version of the new News module in a test environment ONLY. Then, evaluate the issues BEFORE moving it to Production areas.
Note: Currently DNN offers downloads on the Codeplex site. Thanks to Sebastian Leupold for the updated information. As of 3/10/2009, the DNN Codeplex site has versions:
Wednesday, October 1, 2008
Can't See the Tree for the Forest...
by Phil 'iwonder' Guerra
-- (Mission, KS) - A question popped up on the forums the other day asking a simple question, 'Why would the 4.0.0 upgrade not preserve XSLs?'. My answer was to offer that the module was completely redesigned and the new design took a path that changed how news feeds were handled. The module takes an incoming news source file, converts it to a 'standard' RSS v2.0 feed. This processing is needed only for the aggregation of dissimilar feeds, but is forced in the case of a module setup for just single feeds, which is what most folks have with existing modules using the previous version of the Newsfeeds (RSS) module.
You can combine different feed formats into a module for presentation, but they all must ultimately be in the same format. The trouble with this design is that the underlying conversion of feeds has issues that you would never see without digging into the code. Mostly, when that type of issue happens, the feed will just throw an exception saying the feed could not be downloaded, or you get errors in feed validation. I've been working on testing the beta correction to the issues with the new module, but what I found last night was that many of these types of errors could probably be attributed to feed conversion issues rather than due to the validation of the final feed formatting. I'll take about that more in another entry, though.
My main point with this entry is that many folks are seeing a lot of extra work because they lost all of the formatting in their feeds if they used a custom xsl for presentation. The new module only allows 3 basic xsl choices. One of them really doesn't work well, the Horizontal Ticker. Now, you can write a custom xsl for your feeds that are converted to the RSS v2.0 DNN standard, but it has to be written for the DNN RSS v2.0 format, which is very limited in what it will include from a feed. Again, this is due to the need to have content that is similar, with a small subset of the RSS v2.0 elements. Basically, what you get is similar to the RSS v0.91 content.
Now, on the way to work I had a thought. Why not just add a Module 'Mode' option? You could allow a module to be setup that only is used for 'Single Feed' Mode, and an option for 'Aggregate' mode. The 'Single Feed' mode would allow the user to specify the URL, and the XSL for use in presentation, without worrying about having to conform to one standard presentation format. If the mode is 'Single Feed' you don't have to use the logic that converts the incoming format to the DNN RSS v2.0 format. You would just use a custom xsl for the feed type you are using. Sounds simple enough, right?
Well, that's the theory. Now, in practice, more is required. The beauty of one standard presentation layer is that users don't have to think about the type of feed format their chosen feed is in, the module takes care of it all. However, I think that with a little more effort, a feed can be analyzed, and then present the results to the user, or give a dropdown of available xsl choices to use for the feed type. Admittedly, that's more work, but it is a slicker, backward compatible design.
Now, with a site that is already using different types of news formatted feeds, and custom xsl files, the upgrade would simply default to 'Single Feed' mode, and use the existing settings for use in the new module setup. Thus, you preserve the existing feed setup, and the loss of functionality by merely upgrading is gone.
That's my thinking this morning, anyway. Instead of not seeing the 'tree' for the 'forest', you can actually see the 'tree' and if you want to see the 'forest', you can do that too!
Let me know what you think?
-- (Mission, KS) - A question popped up on the forums the other day asking a simple question, 'Why would the 4.0.0 upgrade not preserve XSLs?'. My answer was to offer that the module was completely redesigned and the new design took a path that changed how news feeds were handled. The module takes an incoming news source file, converts it to a 'standard' RSS v2.0 feed. This processing is needed only for the aggregation of dissimilar feeds, but is forced in the case of a module setup for just single feeds, which is what most folks have with existing modules using the previous version of the Newsfeeds (RSS) module.
You can combine different feed formats into a module for presentation, but they all must ultimately be in the same format. The trouble with this design is that the underlying conversion of feeds has issues that you would never see without digging into the code. Mostly, when that type of issue happens, the feed will just throw an exception saying the feed could not be downloaded, or you get errors in feed validation. I've been working on testing the beta correction to the issues with the new module, but what I found last night was that many of these types of errors could probably be attributed to feed conversion issues rather than due to the validation of the final feed formatting. I'll take about that more in another entry, though.
My main point with this entry is that many folks are seeing a lot of extra work because they lost all of the formatting in their feeds if they used a custom xsl for presentation. The new module only allows 3 basic xsl choices. One of them really doesn't work well, the Horizontal Ticker. Now, you can write a custom xsl for your feeds that are converted to the RSS v2.0 DNN standard, but it has to be written for the DNN RSS v2.0 format, which is very limited in what it will include from a feed. Again, this is due to the need to have content that is similar, with a small subset of the RSS v2.0 elements. Basically, what you get is similar to the RSS v0.91 content.
Now, on the way to work I had a thought. Why not just add a Module 'Mode' option? You could allow a module to be setup that only is used for 'Single Feed' Mode, and an option for 'Aggregate' mode. The 'Single Feed' mode would allow the user to specify the URL, and the XSL for use in presentation, without worrying about having to conform to one standard presentation format. If the mode is 'Single Feed' you don't have to use the logic that converts the incoming format to the DNN RSS v2.0 format. You would just use a custom xsl for the feed type you are using. Sounds simple enough, right?
Well, that's the theory. Now, in practice, more is required. The beauty of one standard presentation layer is that users don't have to think about the type of feed format their chosen feed is in, the module takes care of it all. However, I think that with a little more effort, a feed can be analyzed, and then present the results to the user, or give a dropdown of available xsl choices to use for the feed type. Admittedly, that's more work, but it is a slicker, backward compatible design.
Now, with a site that is already using different types of news formatted feeds, and custom xsl files, the upgrade would simply default to 'Single Feed' mode, and use the existing settings for use in the new module setup. Thus, you preserve the existing feed setup, and the loss of functionality by merely upgrading is gone.
That's my thinking this morning, anyway. Instead of not seeing the 'tree' for the 'forest', you can actually see the 'tree' and if you want to see the 'forest', you can do that too!
Let me know what you think?
Tuesday, September 30, 2008
Progress - News Beta Testing...
by Phil 'iwonder' Guerra
--- (Mission, KS). While testing I found some Atom feeds failing to download. It's strange, but I did manage to get at least one to download and display, but others failed. I took a look at the conversion xsl files in the RssToolKit.
I actually found a line in the AtomToRss20.xsl that seemed to be the culprit, moreso than the date cnversion, although there is an issue with that too. The basic reason why it wouldn't load was becasue the conversion xsl has an invalid directive:
<xml:output mode="xml" encoding="UTF-8"/>
This was probably throwing an error during the attempt to convert it or download it. I put the xsl into my xsl editor, with an input Atom xml file, and it choked, with an error: The namespace prefix is not allowed to start with the reserved string "xml". So, I replaced that line with this one:
<xsl:output method="xml" encoding="UTF-8"/>
Then, it began to work. The date conversion routine had issues too, with not producing a proper formatted date. I corrected that issue, too. I'll send the updated xsl file to Peter, as soon as I can go through the other files in the RssToolKit.
Strange thing, though I don't know why one of the feeds I tested, actually did work.?!? I'll have to go back to that one, to check it out more closely.
Now, after looking at the conversion xsl again, I noticed some other issues with it. For example, the title links to a comment area, and not the actual article. More work needs to be done.
--- (Mission, KS). While testing I found some Atom feeds failing to download. It's strange, but I did manage to get at least one to download and display, but others failed. I took a look at the conversion xsl files in the RssToolKit.
I actually found a line in the AtomToRss20.xsl that seemed to be the culprit, moreso than the date cnversion, although there is an issue with that too. The basic reason why it wouldn't load was becasue the conversion xsl has an invalid directive:
<xml:output mode="xml" encoding="UTF-8"/>
This was probably throwing an error during the attempt to convert it or download it. I put the xsl into my xsl editor, with an input Atom xml file, and it choked, with an error: The namespace prefix is not allowed to start with the reserved string "xml". So, I replaced that line with this one:
<xsl:output method="xml" encoding="UTF-8"/>
Then, it began to work. The date conversion routine had issues too, with not producing a proper formatted date. I corrected that issue, too. I'll send the updated xsl file to Peter, as soon as I can go through the other files in the RssToolKit.
Strange thing, though I don't know why one of the feeds I tested, actually did work.?!? I'll have to go back to that one, to check it out more closely.
Now, after looking at the conversion xsl again, I noticed some other issues with it. For example, the title links to a comment area, and not the actual article. More work needs to be done.
Friday, September 26, 2008
DNN Make Feed Display on All Pages
by Phil 'iwonder' Guerra
--- (Mission, KS). A common question about the News Module, or any DNN core module for that matter, is how to make it show up on all portal web pages. It's pretty simple, but can be easily overlooked. Here's the simple solution, most modules have an option that give an administrator the option to display it on all pages.
In the news module, just go to the module settings, expand the Advanced Settings area and check the box next to the settings label:
Display Module On All Pages?
This will display the module in all of the pages. I use it to display a Headline ticker in the top pane on all of the pages.
Most core DNN modules work the same way.
--- (Mission, KS). A common question about the News Module, or any DNN core module for that matter, is how to make it show up on all portal web pages. It's pretty simple, but can be easily overlooked. Here's the simple solution, most modules have an option that give an administrator the option to display it on all pages.
In the news module, just go to the module settings, expand the Advanced Settings area and check the box next to the settings label:
Display Module On All Pages?
This will display the module in all of the pages. I use it to display a Headline ticker in the top pane on all of the pages.
Most core DNN modules work the same way.
Wednesday, September 24, 2008
Localized RSS Date Time...
by Phil 'iwonder' Guerra
--- (Mission, KS). Not sure why folks want to change the pubDate format given in a newsfeed. I have nothing but trouble when I try to base anything on pubDate. I can understand the desire to show feeds with localized date/time, but seems like a whole lot of trouble to go through. My experience with most feeds generated is that they don't even reflect correct information in about 80% of the usage I've seen. The discrepency usually can be attributed to developers not understanding how to correctly use date/time fields and convert them, and the further complication of date/times being formatted in databases based on the server date/time setup, which may not be correctly setup or maintained.
It's really puzzling to me how RSS specs decided to use the RFC822 date/time format in the first place. This was a standard developed for first gen email text messages. Peter's correct in that it was an American originated spec, but it did have a group of international folks working on it, which is why the format doesn't even match American date formats either. Now to really confuse matters, the RFC822 spec is really obsolete, the newer RFC2822 is the defacto standard. So, why in the world do we not use it? Well, it isn't all that much better for this type of usage, folks.
Perhaps a better standard would be ISO8601 (see a Wiki entry here. If you still are not totally confused, and want to press further, I suppose you are just bent that way, and since you are using MS prodcuts with DotNetNuke, you could prolly find a way to do this in the News module, since it's rewritting the incoming news source anyway. However, that brings us back to the lack of folks using any standard to start. Any code fix requires some kind of 'rule' to fallback on, and with many news feeds, there just isn't any reliability. Also, what do you suggest is used for the default language? Is it the portal setting for preferred language, the host server setting for language, or the end-user's machine language setting? Those questions have never been answered in the core DotNetNuke code. I know because, I tried to get folks to make a decision on it, and never got any DNN Core Team members to attach enough significance to it to make it happen. It's still not resolved in the DNN.
In fact, to be fair, it's not really resolved in Microsoft's world either. Yes, I know about the Olson timezone, tz database in use on Unix, Linux, and other implementations. I am a member of the tz mail list, and over the years, even that solution goes through incredible changes in year, almost daily. I've come to the conclusion that until the world comes under one umbrella, there is not going to be a solution to please everyone. Although, if you need me to vote, I'd say hitch your wagon to the tz database if you can, at least it has provision for being used for historical context, supported by users throughout the globe, not just in Redmond.
Now, you can change the format using XSL, but it's a real chore to provide a solution that's universal and fully globalized. Most solutions are going to be local solutions as far as I can tell. I've done a bit of that stuff, but reverted back to not caring about it because most feeds don't always give you pubDate in the rfc822 format, and trying to figure out universal routines to deal with all the variances of gloablized date/time formats is difficult to say the least. So, I just take it as it is - much like the content in a feed.
I don't even like to validate the pubDate format because I'd rather worry about getting the content than stressing over whether the pubDate is valid and miss displaying the content. Maybe I'm funny that way, but my usage of feeds is not based on pubDate, and if I choose to cache, I think the better approach would be to simulate a ttl element based on the date/time I pulled the feed originally, if one is not available. I'd use whatever is there, if easily parsed, so I can display the pubDate as given, and still have control over timing for feed retrieval and display. Just my thoughts...
--- (Mission, KS). Not sure why folks want to change the pubDate format given in a newsfeed. I have nothing but trouble when I try to base anything on pubDate. I can understand the desire to show feeds with localized date/time, but seems like a whole lot of trouble to go through. My experience with most feeds generated is that they don't even reflect correct information in about 80% of the usage I've seen. The discrepency usually can be attributed to developers not understanding how to correctly use date/time fields and convert them, and the further complication of date/times being formatted in databases based on the server date/time setup, which may not be correctly setup or maintained.
It's really puzzling to me how RSS specs decided to use the RFC822 date/time format in the first place. This was a standard developed for first gen email text messages. Peter's correct in that it was an American originated spec, but it did have a group of international folks working on it, which is why the format doesn't even match American date formats either. Now to really confuse matters, the RFC822 spec is really obsolete, the newer RFC2822 is the defacto standard. So, why in the world do we not use it? Well, it isn't all that much better for this type of usage, folks.
Perhaps a better standard would be ISO8601 (see a Wiki entry here. If you still are not totally confused, and want to press further, I suppose you are just bent that way, and since you are using MS prodcuts with DotNetNuke, you could prolly find a way to do this in the News module, since it's rewritting the incoming news source anyway. However, that brings us back to the lack of folks using any standard to start. Any code fix requires some kind of 'rule' to fallback on, and with many news feeds, there just isn't any reliability. Also, what do you suggest is used for the default language? Is it the portal setting for preferred language, the host server setting for language, or the end-user's machine language setting? Those questions have never been answered in the core DotNetNuke code. I know because, I tried to get folks to make a decision on it, and never got any DNN Core Team members to attach enough significance to it to make it happen. It's still not resolved in the DNN.
In fact, to be fair, it's not really resolved in Microsoft's world either. Yes, I know about the Olson timezone, tz database in use on Unix, Linux, and other implementations. I am a member of the tz mail list, and over the years, even that solution goes through incredible changes in year, almost daily. I've come to the conclusion that until the world comes under one umbrella, there is not going to be a solution to please everyone. Although, if you need me to vote, I'd say hitch your wagon to the tz database if you can, at least it has provision for being used for historical context, supported by users throughout the globe, not just in Redmond.
Now, you can change the format using XSL, but it's a real chore to provide a solution that's universal and fully globalized. Most solutions are going to be local solutions as far as I can tell. I've done a bit of that stuff, but reverted back to not caring about it because most feeds don't always give you pubDate in the rfc822 format, and trying to figure out universal routines to deal with all the variances of gloablized date/time formats is difficult to say the least. So, I just take it as it is - much like the content in a feed.
I don't even like to validate the pubDate format because I'd rather worry about getting the content than stressing over whether the pubDate is valid and miss displaying the content. Maybe I'm funny that way, but my usage of feeds is not based on pubDate, and if I choose to cache, I think the better approach would be to simulate a ttl element based on the date/time I pulled the feed originally, if one is not available. I'd use whatever is there, if easily parsed, so I can display the pubDate as given, and still have control over timing for feed retrieval and display. Just my thoughts...
Tuesday, September 23, 2008
RSS XSL Stripping HTML
by Phil 'iwonder' Guerra
I get a fair amount of questions about how to handle transformations, either related to custom XML data islands or RSS newsfeeds. One question that seems to be near the top of the list is "How can I get rid of all HTML in the description of an RSS newsfeed?" Well, the answer involves a bit of study of the source, and then, a bit of tweaking, and testing of a custom XSL.
Searching the web, I located several examples of XSL functions that I could tweak to provide a flexible solution that integrates well into the DotNetNuke framework, either with the News module or the XML/XSL module. I found the code that worked the best for me at this URL:
Stripping HTML Template
<xsl:template name="strip_HTML">
<xsl:param name="value"/>
<xsl:choose>
<xsl:when test="contains($value,'<')">
<xsl:value-of select="substring-before($value,'<')" disable-output-escaping="yes"/>
<xsl:choose>
<xsl:when test="contains(substring-after($value,'<'),'>')">
<xsl:call-template name="strip_HTML">
<xsl:with-param name="value"><xsl:value-of select="substring-after($value,'>')"/></xsl:with-param>
</xsl:call-template>
</xsl:when>
<xsl:otherwise>
</xsl:otherwise>
</xsl:choose>
</xsl:when>
<xsl:otherwise>
<xsl:value-of select="$value" disable-output-escaping="yes"/>
</xsl:otherwise>
</xsl:choose>
</xsl:template>
Using my basic XSL, I added the template for 'stripping-HTML' and tweaked it until it functioned as I needed. Now, it's just a matter of calling the template when I want to use it. In this case, I want to strip the HTML from the <description> element, so the call to the template is done this way:
<xsl:call-template name="strip_HTML">
<xsl:with-param name="value" select="description" />
</xsl:call-template>
Friday, September 19, 2008
DNN News Failing? Relax...
by Phil 'iwonder' Guerra
Woe is us, huh?!? The DNN News module is failing on many newsfeeds sources that worked without issue on the previous version. Why? Well, the new module places some very tight constraints on the incoming newsfeed used. They must be able to be successfully transformed into a valid RSS v2.0 to be displayed using the News module v04.00.00. Simply, a newsfeed will fail if the elements do not pass validation specified in the module's XSD file.
The problem is most newsfeeds do not care about conforming to any RSS spec, their developers do not understand what is needed, or the users creating them do not understand what to use in the placeholders to which they add content. Anyway you slice it, there is a problem that is causing many users to shy away from the new module, or move back to the previous version of the News module. There's even a thread to report a feed that does not work here.
Now, the issue is a hot topic on the forums, especially visible within the first few days of the modules' release. In the process of these discussion some folks found a workaround that takes the steps of relaxing those constraints, by modifying the modules' XSD file.
You can read about the issue here on the forums, or take a look at another's view of the situation here, which includes some detail on how to fix it. I've already commented on the issue, but am adding my fix, which is basically the same as Craig's. He beat me to posting it. No matter, because the point is folks needed a fix.
Since, I knew about the XSD issue, but didn't yet have the source, I couldn't fix the problem. The fix involves modifying the Rss20.xsd file located in the \Website\DesktopModules\News\RssToolkit\Resources folder. There you will find the description of the elements used to validate a feed which eventually gets transformed from its' source format, Atom, RDF, RSSv0.91, RSSv1.0 to RSSv2.0.
The constraints used to descibe some elements can be lifted entirely, or you could manage to ease them back a tad, depending on your capability and needs. I chose to relax them entirely for the elements using these custom types:
- tEmailAddress
- tRfc822FormatDate
<xs:simpleType name="tEmailAddress">
<xs:annotation>
<xs:documentation>Not Using the regexp definiton of E-Mail Address </xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="tRfc822FormatDate">
<xs:annotation>
<xs:documentation>A date-time displayed in RFC-822 format.</xs:documentation>
<xs:documentation>Not Using the regexp definiton of rfc-822 date </xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
</xs:restriction>
</xs:simpleType>
Making those changes, recompiling the module, and placing the resulting DotNetNuke.Modules.News.dll into the \Website\Bin folder fixed many of my issues. There are still some odd ones floating about, like constraints on image size, but this first set of mods, gives me the most benefit.
Now, is this the way to fix it overall? I don't think it is a 'best practice' by any means. I'm testing it at this point, so you can follow this example and test it yourself, or wait for the 'official' fix. My plan is to provide validation at the time of adding a feed, rather than validating after the feed is fetched. Also, I think it better to provide a gracefull correction to these issues by coding a way to provide a usable alternative element.
I'll post more details later. BTW - Thanks to Craig Hubbard for adding the information in the forums about how he fixed his issues. I was floundering about making the XSD changes, and didn't realize I had to recompile the project for it to pick up the changes.
Woe is us, huh?!? The DNN News module is failing on many newsfeeds sources that worked without issue on the previous version. Why? Well, the new module places some very tight constraints on the incoming newsfeed used. They must be able to be successfully transformed into a valid RSS v2.0 to be displayed using the News module v04.00.00. Simply, a newsfeed will fail if the elements do not pass validation specified in the module's XSD file.
The problem is most newsfeeds do not care about conforming to any RSS spec, their developers do not understand what is needed, or the users creating them do not understand what to use in the placeholders to which they add content. Anyway you slice it, there is a problem that is causing many users to shy away from the new module, or move back to the previous version of the News module. There's even a thread to report a feed that does not work here.
Now, the issue is a hot topic on the forums, especially visible within the first few days of the modules' release. In the process of these discussion some folks found a workaround that takes the steps of relaxing those constraints, by modifying the modules' XSD file.
You can read about the issue here on the forums, or take a look at another's view of the situation here, which includes some detail on how to fix it. I've already commented on the issue, but am adding my fix, which is basically the same as Craig's. He beat me to posting it. No matter, because the point is folks needed a fix.
Since, I knew about the XSD issue, but didn't yet have the source, I couldn't fix the problem. The fix involves modifying the Rss20.xsd file located in the \Website\DesktopModules\News\RssToolkit\Resources folder. There you will find the description of the elements used to validate a feed which eventually gets transformed from its' source format, Atom, RDF, RSSv0.91, RSSv1.0 to RSSv2.0.
The constraints used to descibe some elements can be lifted entirely, or you could manage to ease them back a tad, depending on your capability and needs. I chose to relax them entirely for the elements using these custom types:
- tEmailAddress
- tRfc822FormatDate
<xs:simpleType name="tEmailAddress">
<xs:annotation>
<xs:documentation>Not Using the regexp definiton of E-Mail Address </xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="tRfc822FormatDate">
<xs:annotation>
<xs:documentation>A date-time displayed in RFC-822 format.</xs:documentation>
<xs:documentation>Not Using the regexp definiton of rfc-822 date </xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
</xs:restriction>
</xs:simpleType>
Making those changes, recompiling the module, and placing the resulting DotNetNuke.Modules.News.dll into the \Website\Bin folder fixed many of my issues. There are still some odd ones floating about, like constraints on image size, but this first set of mods, gives me the most benefit.
Now, is this the way to fix it overall? I don't think it is a 'best practice' by any means. I'm testing it at this point, so you can follow this example and test it yourself, or wait for the 'official' fix. My plan is to provide validation at the time of adding a feed, rather than validating after the feed is fetched. Also, I think it better to provide a gracefull correction to these issues by coding a way to provide a usable alternative element.
I'll post more details later. BTW - Thanks to Craig Hubbard for adding the information in the forums about how he fixed his issues. I was floundering about making the XSD changes, and didn't realize I had to recompile the project for it to pick up the changes.
Thursday, September 18, 2008
Building the DNN News Module With Visual Web Developer 2008
by Phil 'iwonder' Guerra
With all of the new tools available from Microsoft, and so many swift changes in technology, it's really difficult to keep up. I took some time off from DNN development to focus on HPUX System Administration, which is another topic. In the course of that time, Microsoft released the many varieties of Vista, VS2008, SQL2008, SQL2008Express, and Visual Web Developer 2008 among others. Phew, what's a self employed single consultant to do? Can't go out and buy all of the bells and whistles. So, I'm setting up shop again, using nothing but freebies. Of course, many who know me, would say what's different? Nothing, exactly, I did get the more pricey tools as part of payment for consulting work, but I really want to go about just using tools that others have readily available to them. It makes teaching folks how to take care of things themselves much easier.
Anyways, part of the ongoing discussion in the DNN News forums is about how to fix the strict validation of incoming newsfeeds. The validation is done using a xsd that specifies the restrictions of fields used by the module. While you can change the xsd to relax the constraints, you will need to recompile the News module for your changes to take affect. That's where this tidbit comes in...
The primary DNN project comes in 2 flavors at the moment, a vs2005 and vs2008 solution. The DNN News module was built using either vs2008 or vwd2008. So, if you want to make any changes to the module, you need to use one of those tools. In my case, I'm using VWD2008. Since, I'm not really an expert on it, I asked for some help on the forums, which got some pretty terse response, still gave me enough to 'remember' that the missing ingredient in all of my troubles was just to add the missing references in the project.
If you are using MS VWD 2008, it is possible to make your own changes to the News module. Open up the project in VWD2008, and add the references for the following dlls located in the folder where you put dnn \Website\Bin\:
DoteNetNuke.dll
DotnNetNuke.WebUtility.dll
Microsoft.ApplicationBlocks.Data.dll
Then, try a quick rebuild before making any changes. If your setup is acceptable, the project will rebuild successfully, then the module will be ready for more changes. If you have errors, there may be other references to add, but those are the only ones I needed to add.
After you make your changes, just replace the resulting DotNetNuke.Modules.News.dll in your Website\DesktopModules\News\bin folder (or wherever your source is located), into the \Website\Bin folder.
The easiest fix is to relax the constraints that are causing folks so much trouble with their existing feed sources. Thats the next topic...
With all of the new tools available from Microsoft, and so many swift changes in technology, it's really difficult to keep up. I took some time off from DNN development to focus on HPUX System Administration, which is another topic. In the course of that time, Microsoft released the many varieties of Vista, VS2008, SQL2008, SQL2008Express, and Visual Web Developer 2008 among others. Phew, what's a self employed single consultant to do? Can't go out and buy all of the bells and whistles. So, I'm setting up shop again, using nothing but freebies. Of course, many who know me, would say what's different? Nothing, exactly, I did get the more pricey tools as part of payment for consulting work, but I really want to go about just using tools that others have readily available to them. It makes teaching folks how to take care of things themselves much easier.
Anyways, part of the ongoing discussion in the DNN News forums is about how to fix the strict validation of incoming newsfeeds. The validation is done using a xsd that specifies the restrictions of fields used by the module. While you can change the xsd to relax the constraints, you will need to recompile the News module for your changes to take affect. That's where this tidbit comes in...
The primary DNN project comes in 2 flavors at the moment, a vs2005 and vs2008 solution. The DNN News module was built using either vs2008 or vwd2008. So, if you want to make any changes to the module, you need to use one of those tools. In my case, I'm using VWD2008. Since, I'm not really an expert on it, I asked for some help on the forums, which got some pretty terse response, still gave me enough to 'remember' that the missing ingredient in all of my troubles was just to add the missing references in the project.
If you are using MS VWD 2008, it is possible to make your own changes to the News module. Open up the project in VWD2008, and add the references for the following dlls located in the folder where you put dnn \Website\Bin\:
DoteNetNuke.dll
DotnNetNuke.WebUtility.dll
Microsoft.ApplicationBlocks.Data.dll
Then, try a quick rebuild before making any changes. If your setup is acceptable, the project will rebuild successfully, then the module will be ready for more changes. If you have errors, there may be other references to add, but those are the only ones I needed to add.
After you make your changes, just replace the resulting DotNetNuke.Modules.News.dll in your Website\DesktopModules\News\bin folder (or wherever your source is located), into the \Website\Bin folder.
The easiest fix is to relax the constraints that are causing folks so much trouble with their existing feed sources. Thats the next topic...
Saturday, September 13, 2008
DNN News Module Too Strict?
by Phil 'iwonder' Guerra
One thing that is difficult to manage is the aggregation of feeds without standards. Unfortunately, the strict enforcement of RSS v2.0 implementation is more for the aggregation rather than just the display of a single feed. At this point, I believe the DNN News module is being too strict, as most newsfeed sources will never all comply with the specs for any version of the RSS or Atom specs. One of the more common errors is in the display of date of publication, which is not even a standard element between RSS v2.0, RSS v1.0 (RDF), and Atom feeds. Also, the date formatting is totally out of whack for for a lot of feeds, even when somethings gives GMT as its' base, you cannot rely on the develper actually giving you that correctly.
Other troublesome elements are those that are supposed to include and email in the content, but only provide a name. This is a common error emitted for a lot of popular newsfeeds, but one easily avoided with including the Dublin Core namespace in a feed, and using one of the 3 included metadata elements that do not require email:
- creator
- publisher
- contributor
There are other DC elements that are useful, as well. In fact many newsfeeds incorporate them as extensions to whatever version RSS they emit.
The other option is for the DNN module to include the Dublin Core namespace and use one of the above elements in place of the RSS v2.0 author element when an email format fails, and always provide the associated DC element with the email stripped when one is present. In this way the feed validates and can be used without penalty.
With the apps I write for desktop, I just take this information without trying to validate it or use it for anything other than displaying it as given. If I can't make sense of a date element in a feed, I find it easier to fashion a date for sorting, or caching, which I take from the time I first bring in the element. It's not going to make a whole lot of difference in the presentation anyway IMHO. The main usage for me of having a pubDate is for sorting, and accuracy in attribution of the news source.
It's mostly a matter of lack of attention by developers writing the feed generators. We see it in the DNN modules as well. The whole point of specs is to keep folks from having to worry about issue with code that is supposed to be compliant. Of course, that's not what we see in the real information world. If auto makers disregarded safety specifications as much as developers, we'ld have pulled the offenders off the market. Unfortunately, there is no similar enforcement in our IS world.
I think going into this update, most didn't realize the number of newsources that were not compliant. If something says it's RSSv2.0 then it should be expected to be a valid feed. There's the trouble, even larger news providers don't offer compliant RSS, so it's something the industry just avoids by coding around it. In the end, that's probably what will have to be done in the module, because aggregation should not cause aggrevation.
One thing that is difficult to manage is the aggregation of feeds without standards. Unfortunately, the strict enforcement of RSS v2.0 implementation is more for the aggregation rather than just the display of a single feed. At this point, I believe the DNN News module is being too strict, as most newsfeed sources will never all comply with the specs for any version of the RSS or Atom specs. One of the more common errors is in the display of date of publication, which is not even a standard element between RSS v2.0, RSS v1.0 (RDF), and Atom feeds. Also, the date formatting is totally out of whack for for a lot of feeds, even when somethings gives GMT as its' base, you cannot rely on the develper actually giving you that correctly.
Other troublesome elements are those that are supposed to include and email in the content, but only provide a name. This is a common error emitted for a lot of popular newsfeeds, but one easily avoided with including the Dublin Core namespace in a feed, and using one of the 3 included metadata elements that do not require email:
- creator
- publisher
- contributor
There are other DC elements that are useful, as well. In fact many newsfeeds incorporate them as extensions to whatever version RSS they emit.
The other option is for the DNN module to include the Dublin Core namespace and use one of the above elements in place of the RSS v2.0 author element when an email format fails, and always provide the associated DC element with the email stripped when one is present. In this way the feed validates and can be used without penalty.
With the apps I write for desktop, I just take this information without trying to validate it or use it for anything other than displaying it as given. If I can't make sense of a date element in a feed, I find it easier to fashion a date for sorting, or caching, which I take from the time I first bring in the element. It's not going to make a whole lot of difference in the presentation anyway IMHO. The main usage for me of having a pubDate is for sorting, and accuracy in attribution of the news source.
It's mostly a matter of lack of attention by developers writing the feed generators. We see it in the DNN modules as well. The whole point of specs is to keep folks from having to worry about issue with code that is supposed to be compliant. Of course, that's not what we see in the real information world. If auto makers disregarded safety specifications as much as developers, we'ld have pulled the offenders off the market. Unfortunately, there is no similar enforcement in our IS world.
I think going into this update, most didn't realize the number of newsources that were not compliant. If something says it's RSSv2.0 then it should be expected to be a valid feed. There's the trouble, even larger news providers don't offer compliant RSS, so it's something the industry just avoids by coding around it. In the end, that's probably what will have to be done in the module, because aggregation should not cause aggrevation.
Wednesday, September 10, 2008
DNN News Module - Headlines.xsl Ticker Available
Two XSL files are included that allow vertical or horizontal scrolling of newsfeeds items in the new DNN News module v04.00.00. After playing around with the new News module, I found a slight implementation issue with using the Ticker.xsl. When I choose to use this xsl, I don't get the expected results, which is seeing a display of the news headlines scroll across my module 1 at a time. Instead the xsl displays all of the items, and scrolls them all across the module container. If you have 10 or more items, this kind of implementation is really distracting, as all of the items display and are scrolled.
Now, that is not the implementation I've seen with other similar web usage. So, I created an alternative xsl that can be dropped into the modules transformation folder and used to provide the display of News Headlines scrolling across the module container. This is mostly useful for the Top container area, but suppose you could put it elsewhere - I use it in the Top area.
The settings for 'Show Items Date', and 'Show Items Detail' are not used, as this xsl is desigened just to display the headlines (title element), which I think is the more oft used implementation.
The other thing about this new xsl is that it will support the "ItemsToShow" parameter, but keep in mind that if you are agregating a number of feeds, the count is for the total number of items to show, not the number of items to show per feed.
I placed this HeadlinesTicker.xsl in the same folder as the other default News xsl files
\Website\DesktopModules\News\Transformations
I'm guessing that you could upload it, and choose it for using for your module, as it does transform RSSv2.0 feeds, which is the only custom xsl types that I've seen actually work with the new module. Copy and paste the code, save it to a file using your favorite bare bones text editor. Then, place it our upload it. Be sure to test it out first, though to ensure it does what you think it should.
Click on the blog Title to view the DNN News Forum post where I give the actual code. Sorry, can't provide it here.
Now, that is not the implementation I've seen with other similar web usage. So, I created an alternative xsl that can be dropped into the modules transformation folder and used to provide the display of News Headlines scrolling across the module container. This is mostly useful for the Top container area, but suppose you could put it elsewhere - I use it in the Top area.
The settings for 'Show Items Date', and 'Show Items Detail' are not used, as this xsl is desigened just to display the headlines (title element), which I think is the more oft used implementation.
The other thing about this new xsl is that it will support the "ItemsToShow" parameter, but keep in mind that if you are agregating a number of feeds, the count is for the total number of items to show, not the number of items to show per feed.
I placed this HeadlinesTicker.xsl in the same folder as the other default News xsl files
\Website\DesktopModules\News\Transformations
I'm guessing that you could upload it, and choose it for using for your module, as it does transform RSSv2.0 feeds, which is the only custom xsl types that I've seen actually work with the new module. Copy and paste the code, save it to a file using your favorite bare bones text editor. Then, place it our upload it. Be sure to test it out first, though to ensure it does what you think it should.
Click on the blog Title to view the DNN News Forum post where I give the actual code. Sorry, can't provide it here.
Monday, September 8, 2008
DNN News Module v04.00.00 Released
The new release of the DotNetNuke News module brings some nice new features to the module. Peter Donker blogs about it on his DNN Blog. You'll need at least DNN v04.06.02 to integrate into your DNN website. Also, the new module has some gotchas, so visit the DNN News Forum for a review of the discussions.
Be aware that the new module is very strict in its' validating a newsfeed source, so don't expect all of your existing newsfeeds to work straight away. The issues causing folks so much trouble are mostly due to the lack of newsfeed providers to emit valid RSS feeds. The most troublesome aspect of all of all is that even certain DNN Core modules suffer this same condition.
Most feeds that are being reported as failing are due to validation failing on the newsfeed item elements that do not provide rfc822 dates or valid email information for elements that require them.
I've been using the module for a bit now, and will blog more about it later. For now, download it, install it in a test environment, and put it to the test. It's more advanced than the previous version, which only used a news source link to make a web request and transform it using xsl. The new module is the second DNN attempt at news aggregation (the FeedExplorer was the first). It works reasonably well, but newbies and some 'oldies' with little experience with RSS and newsfeeds will need help in using it out of the box. The strict RSS validation is rough going.
Also, new is the ability to use passed parameters to control some of the display of a newsfeed. You can control the number of elements and choose to display or not display the item date and details.
There are some included XSL files which allow scrolling and default look and feel. The basic approach is to provide a newsfeed display much like many new browsers are doing, but allowing several differnt types of newsfeeds, Atom, RSSv0.91, RSSv1.0 (RDF), and RSSv2.0 to be used without worrying the details. Of course, the implementation still needs some work, but the overall direction of the DNN News module is finally getting an update.
More on the module later. I'll have some tips, and workarounds posted for you.
Be aware that the new module is very strict in its' validating a newsfeed source, so don't expect all of your existing newsfeeds to work straight away. The issues causing folks so much trouble are mostly due to the lack of newsfeed providers to emit valid RSS feeds. The most troublesome aspect of all of all is that even certain DNN Core modules suffer this same condition.
Most feeds that are being reported as failing are due to validation failing on the newsfeed item elements that do not provide rfc822 dates or valid email information for elements that require them.
I've been using the module for a bit now, and will blog more about it later. For now, download it, install it in a test environment, and put it to the test. It's more advanced than the previous version, which only used a news source link to make a web request and transform it using xsl. The new module is the second DNN attempt at news aggregation (the FeedExplorer was the first). It works reasonably well, but newbies and some 'oldies' with little experience with RSS and newsfeeds will need help in using it out of the box. The strict RSS validation is rough going.
Also, new is the ability to use passed parameters to control some of the display of a newsfeed. You can control the number of elements and choose to display or not display the item date and details.
There are some included XSL files which allow scrolling and default look and feel. The basic approach is to provide a newsfeed display much like many new browsers are doing, but allowing several differnt types of newsfeeds, Atom, RSSv0.91, RSSv1.0 (RDF), and RSSv2.0 to be used without worrying the details. Of course, the implementation still needs some work, but the overall direction of the DNN News module is finally getting an update.
More on the module later. I'll have some tips, and workarounds posted for you.
Subscribe to:
Posts (Atom)
