<rss version="2.0" 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/"><channel><title>AppTheory</title><link>http://www.apptheory.com</link><description>RSS feeds for AppTheory</description><ttl>60</ttl><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/531/New-Telerik-Release.aspx#Comments</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=531</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=531&amp;PortalID=2&amp;TabID=411</trackback:ping><title>New Telerik Release</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/531/New-Telerik-Release.aspx</link><description>Telerik released their updated set of components for Q3 2009 the today. One of the things I find great about this release is their Visual Style Builder is now capable of producing detailed skins for all of their controls now. If you haven’t heard about the Style Builder, it basically allows you to redesign the user interface of the Telerik controls without having to write a single line of code or HTML code. To checkout the Visual Style Builder, follow this link to create your own set of custom Telerik control skins: http://stylebuilder.telerik.com/. New controls which are included in the release that may appeal to DotNetNuke developers is their new SiteMap control (which allows you to render from the google xml sitemap created by DNN, if you so desire), RadRating control, RadListView (basically a data list replacement), A new skin for all controls, Suite control installer now permits upgrading (instead of a completely re-install) and some performance enhancements. Also worth mentioning is it looks like they are getting about a 30% performance gain by removing some generic reflection use that was done in all controls previously vs. Telerik releases of the past.   You can read the full details for this release here:http://www.telerik.com/products/aspnet-ajax/whats-new.aspx</description><dc:creator>Chris Paterra</dc:creator><pubDate>Wed, 04 Nov 2009 22:01:04 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:531</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/520/DotNetNuke-Telerik-amp-Ajax.aspx#Comments</comments><slash:comments>1</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=520</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=520&amp;PortalID=2&amp;TabID=411</trackback:ping><title>DotNetNuke, Telerik &amp;amp; Ajax</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/520/DotNetNuke-Telerik-amp-Ajax.aspx</link><description>If you have worked with Telerik you are probably familiar with the “RadAjax” component which is a part of the ASP.NET Controls suite from them. Generally, you throw a RadAjaxManager on your page/control and you are pretty much set to have full Ajax functionality in your application. From here you can include/exclude controls and add a loading panel that can be shared by all panels on the page. Finally, you code your application pretty much like before, adding business logic in Page Load and button click events, and poof you have a full ajaxified application. While this works pretty much the same in any DotNetNuke module, it is important to do two things in your module otherwise you may not get the results you expect. The first is to set the SupportsPartialRendering equal to true. If just starting, this is done from the module definition for the specific control. Otherwise, it is done from a node in your dnn manifest file for your module. Next, the other thing you need to do is on Page_Init of your control you need to place a script manager on the page (if Ajax is installed). You can do this using the following code:    1: If DotNetNuke.Framework.AJAX.IsInstalled Then   2:     DotNetNuke.Framework.AJAX.RegisterScriptManager()   3: End IfOR:   1: if (DotNetNuke.Framework.AJAX.IsInstalled) {   2:     DotNetNuke.Framework.AJAX.RegisterScriptManager();   3: }</description><dc:creator>Chris Paterra</dc:creator><pubDate>Mon, 19 Oct 2009 14:47:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:520</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/513/DotNetNuke-amp-Telerik-CSS-Clashes.aspx#Comments</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=513</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=513&amp;PortalID=2&amp;TabID=411</trackback:ping><title>DotNetNuke &amp;amp; Telerik CSS Clashes</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/513/DotNetNuke-amp-Telerik-CSS-Clashes.aspx</link><description>This week I was spending more time working with Telerik controls in DotNetNuke modules. While I may have several other future topics to discuss because of this, waiting on a response from Telerik before I do that though, I do have some useful information. Previously, I was using pre DNN 5.x releases to create modules. What I am about to touch on was never a problem in any of those versions. However, moving into DNN (and mainly, the new skin) I found one thing that really annoyed me. I kept seeing bullet points next to (on the left) my RadListBox. About a month or two ago I was working with RadUpload and saw a similar problem there but it went away after I played with some options/properties of that control. In the case of the RadListBox, nothing like this was available. After some research I found out it appears to be some CSS conflict in the Extropy skin (and the key here is I never thought of ‘bullet points’ as a search term).The correction is adding a class to your module.css:    1: .rlbItem     2: {     3:     list-style-type:none !important;     4: }   </description><dc:creator>Chris Paterra</dc:creator><pubDate>Sat, 03 Oct 2009 08:43:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:513</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/510/0-Telerik-RadEditor-Google-Chrome.aspx#Comments</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=510</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=510&amp;PortalID=2&amp;TabID=411</trackback:ping><title>$0 Telerik RadEditor Google Chrome</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/510/0-Telerik-RadEditor-Google-Chrome.aspx</link><description>On a clients site we were receiving complaints of ‘$0’ showing up in peoples posted content. After a bit of research we narrowed this down to an issue with older versions of the Telerik RadEditor rich text editor and the Google Chrome browser. You can read the thread on the Telerik forums here. According to Telerik staff this was resolved in the SP2 release of RadControls for ASP.NET AJAX Q2 2008. So updating the installed version of RadEditor should resolve the issue.</description><dc:creator>Scott Schecter</dc:creator><pubDate>Tue, 29 Sep 2009 01:09:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:510</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/501/RadUpload-Doesnrsquot-Run-Under-Medium-Trust.aspx#Comments</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=501</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=501&amp;PortalID=2&amp;TabID=411</trackback:ping><title>RadUpload Doesn&amp;rsquo;t Run Under Medium Trust</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/501/RadUpload-Doesnrsquot-Run-Under-Medium-Trust.aspx</link><description>One thing I often take for granted is that DotNetNuke runs under Medium Trust. Of course, you can add modules and this may no longer be the case but out of the box it does work. As a core module developer, we are required to ensure our modules run in Medium Trust environments. However, most of my time is spent working on things for AppTheory where this requirement is often not necessary. Recently I was checking to see if our modules work properly under Medium trust (there is a setting in your DNN web.config file for this) and found that those using Telerik’s RadUpload had problems. After a bit of research I found that it cannot run under Medium trust. Telerik’s explanation is they require reflection (and with this component it does make sense) but I can’t figure out (honestly, haven’t spent much time investigating) what exactly they are doing that can’t be worked around. </description><dc:creator>Chris Paterra</dc:creator><pubDate>Mon, 14 Sep 2009 07:08:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:501</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/493/Telerik-Upload-Progress-Indicator-Disappears-in-FireFox-35.aspx#Comments</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=493</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=493&amp;PortalID=2&amp;TabID=411</trackback:ping><title>Telerik Upload Progress Indicator Disappears in FireFox 3.5</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/493/Telerik-Upload-Progress-Indicator-Disappears-in-FireFox-35.aspx</link><description>As you can probably tell from any of my blogs in the past, we often work with Telerik controls (specifically their ASP.NET AJAX suite) and integrate them with DotNetNuke solutions here at AppTheory. Typically, we don’t rush to upgrade our Telerik dependency in modules and instead we usually wait until we are going to upgrade a site’s DNN core and then update all of our modules and providers. Well, there is one exception to that and it is when Telerik releases a major bug fix or a security fix (I am not sure in the past 4 years or so I have seen a security fix publicized).Today, I was doing some work with replacing the core URL control’s upload mechanism with the Telerik equivalent. The primary purpose of this is to handle large file and display a progress of the upload to the site visitor. After wrapping up the development and pushing to a remote server (btw, it’s difficult to really test file upload progress locally because it happens so fast) I did my initial testing in IE and things went great. I then had one of our other developers take a look and he informed me that he is not seeing any progress. Initially, I figured he was using such a small file that he wasn’t seeing the area (I mean, I just saw it with my own eyes). I then remembered that he uses FireFox so I started up FireFox and saw that it was still working (I figured as much, I generally test locally with FireFox as well). I then asked him which version of FireFox he was using and he told me the latest 3.5. I checked mine, realized I was on 3.0 something and then upgraded. Once I loaded up the site I saw immediately the problem he was having, but I wasn’t sure why. I did some searching and came up with the following statement from the Telerik support team “Indeed there is a problem with Q1 2009 under FireFox 3.5, but it should work as expected in IE. For Q2 2009 we have fixed the FF bug as well.”So, if you are using the Telerik Upload component and/or the ProgressArea you should really consider a move to Q2 2009 which just so happened to have a point release just this past Wednesday.</description><dc:creator>Chris Paterra</dc:creator><pubDate>Fri, 28 Aug 2009 22:12:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:493</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/489/DotNetNuke-511-and-Telerik-Skin-Objects.aspx#Comments</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=489</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=489&amp;PortalID=2&amp;TabID=411</trackback:ping><title>DotNetNuke 5.1.1 and Telerik Skin Objects</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/489/DotNetNuke-511-and-Telerik-Skin-Objects.aspx</link><description>In a previous blog post I discussed DotNetNuke 4.x to 5.1.1 upgrade issues I found upgrading the www.dnnforums.com site. Well, since that original blog post we have done several module upgrades and found a solution to some previous issues. One of the previous issues identified was the RadMenu skin object available via Telerik not properly showing icon paths for the menu. The reason behind this is that the path to the icons via the IconFile property has changed it’s format. Previously, icons were a relative link but since the 5.x base they have become absolute. We also found that this same situation can occur with the SolpartMenuProvider, which many installs still use today (although it is no longer actively developed, it was updated for DNN 5.x) and can typically be corrected by parsing the skin package. An example of the code change for the Telerik skin object can be found below, the item commented out is the old line of code used while the new one is below it.    1: If ((tab.IconFile &amp;lt;&amp;gt; String.Empty) AndAlso (node.ImageUrl.Length = 0)) Then   2:     Dim imgaddress As String   3:     If (tab.IsAdminTab Or tab.IsSuperTab) Then   4:         'imgaddress = CStr(IIf(Me.Request.ApplicationPath &amp;lt;&amp;gt; "/", Me.Request.ApplicationPath.ToUpper, String.Empty)) &amp;amp; "/images/" &amp;amp; tab.IconFile   5:         imgaddress = tab.IconFile   6:     Else   7:         imgaddress = PortalSettings.HomeDirectory &amp;amp; tab.IconFile   8:     End If   9:     node.ImageUrl = imgaddress  10: End If </description><dc:creator>Chris Paterra</dc:creator><pubDate>Fri, 21 Aug 2009 16:48:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:489</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/453/The-Scourge-Of-Pasting-From-Microsoft-Word-Into-Rich-Text-Editors.aspx#Comments</comments><slash:comments>1</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=453</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=453&amp;PortalID=2&amp;TabID=411</trackback:ping><title>The Scourge Of Pasting From Microsoft Word Into Rich Text Editors</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/453/The-Scourge-Of-Pasting-From-Microsoft-Word-Into-Rich-Text-Editors.aspx</link><description>One of the biggest challenges you face with user input apart from scripting attacks is the general tag soup that is produced when pasting from arbitrary source from a clipboard into rich text editors. A common example would be a blog module where the post body field is entered into a rich text editor in the user interface. DotNetNuke has built in functions in DotNetNuke.Common.Utilities.HtmlUtils. While I have found these useful the .Clean() method also seems to remove line breaks which tends to be problematic for us. At AppTheory we have created a DotNetNuke html provider for Telerik’s Editor control which allows us to have much more granular cleaning/formatting options when capturing user input. Specifically, you would want to look at the ‘StripFormattingOnPaste’ property of the Telerik Editor to see all of your options. Currently they are as follows:</description><dc:creator>Scott Schecter</dc:creator><pubDate>Sun, 14 Jun 2009 23:21:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:453</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/238/DotNetNuke-HTML-Providers.aspx#Comments</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=238</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=238&amp;PortalID=2&amp;TabID=411</trackback:ping><title>DotNetNuke HTML Providers</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/238/DotNetNuke-HTML-Providers.aspx</link><description>A recent forum post on the DotNetNuke site had me thinking about the available DotNetNuke HTML Providers. Many people use DotNetNuke for their web site framework because, like me, they don't want to re-invent the wheel. Thousands of hours have been spent on the framework's development, not to mention the thousands of hours of development time spent on providers, skin objects, modules, etc. I have no idea exactly how many hours I have spent developing the forums module but I would say its multiple thousands of hours over a few years.</description><dc:creator>Chris Paterra</dc:creator><pubDate>Sat, 25 Oct 2008 22:24:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:238</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/234/Using-Telerik-RadGrid-On-DotNetNuke.aspx#Comments</comments><slash:comments>0</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=234</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=234&amp;PortalID=2&amp;TabID=411</trackback:ping><title>Using Telerik RadGrid On DotNetNuke</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/234/Using-Telerik-RadGrid-On-DotNetNuke.aspx</link><description>Recently on a project we replaced the standard DotNetNuke GridView's with Telerik RadGrids. There are plenty of reasons we chose to do this such as functionality, flexibility, and esthetics. Locally everything worked as expected, however on our Test and QA installations we were receiving JavaScript errors when viewing any page that contained a RadGrid. After a bit of Google Fu, I ran a few Telerik forum posts that suggested that partial rendering being disabled was the culprit. It seems that DNN does not include PageRequestManager object if this property is disabled, thus causing the error. Below is a quick piece of TSQL that can be used to enable partial rendering for all module controls.</description><dc:creator>Scott Schecter</dc:creator><pubDate>Mon, 20 Oct 2008 00:31:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:234</guid></item><item><comments>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/202/Best-Practices-Development-Team-Collaboration-and-DotNetNuke-Part-3-The-References-amp-Project-Structure.aspx#Comments</comments><slash:comments>3</slash:comments><wfw:commentRss>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/RssComments.aspx?TabID=411&amp;ModuleID=1002&amp;ArticleID=202</wfw:commentRss><trackback:ping>http://www.apptheory.com/DesktopModules/DnnForge%20-%20NewsArticles/Tracking/Trackback.aspx?ArticleID=202&amp;PortalID=2&amp;TabID=411</trackback:ping><title>Best Practices: Development Team Collaboration and DotNetNuke (Part 3: The References &amp;amp; Project Structure)</title><link>http://www.apptheory.com/DotNetNuke/articleType/ArticleView/articleId/202/Best-Practices-Development-Team-Collaboration-and-DotNetNuke-Part-3-The-References-amp-Project-Structure.aspx</link><description>This is a continuation of the "Best Practices: Development Team Collaboration and DotNetNuke" multi-part series of blogs. If you have not read Part 1: The Development Environment, Part 2: The SqlDataProvider Files, you may wish to do so before reading this entry. The second installment covered not only the actual SqlDataProvider files, it also covered how to use those files to keep database structure synchronized for all developers collaborating on a project. This installment will cover some basic project structure, primarily focused on the WAP project structure, and also how to manage references for your team collaborating on a single project.</description><dc:creator>Chris Paterra</dc:creator><pubDate>Tue, 23 Sep 2008 10:25:00 GMT</pubDate><guid isPermaLink="false">f1397696-738c-4295-afcd-943feb885714:202</guid></item></channel></rss>