Search Results

Search found 14 results on 1 pages for 'componentart'.

facebook twitter digg google delicious technorati stumbleupon myspace wordpress linkedin gmail igoogle windows live tumblr viadeo yahoo buzz yahoo mail yahoo bookmarks favorites email print

Page 1/1 | 1 

  • Introduction to ComponentArt's TabStrip Control

    This article describes how to use the ComponentArt's TabStrip control to create tab-based contents in asp.net applications.Did you know that DotNetSlackers also publishes .net articles written by top known .net Authors? We already have over 80 articles in several categories including Silverlight. Take a look: here.

    Read the article

  • Which ASP.NET MVC controls toolset do you prefer?

    - by papakost
    I have seen demos of ComponentArt's and Telerik's toolsets. I am interested mainly on finding a grid control, a tabstrip control, a menu control and a treeview control Do you know any company besides the forementioned that offers ASP.NET MVC controls solutions? Which one do you think is the best/most reliable?

    Read the article

  • Modal PopUp Extender labels wont update on Asynchronous Postback

    - by newbie2k
    Hi everyone! I have a ModalPopUpExtender with an UpdatePanel on it. On the UpdatePanel,there few labels and componentart Grid which Updates from the server on every Asynchronous postback when an image button is clicked. The Problem is that the server code updates the modalpopupextender labels as the information on the grid but it wont display the Updated version of it on the modal Popup Extender. Need some Help... Heres the sample code:     Name:     Loyalty Mode:     Expire Mode:     LoadingPanelClientTemplateId="LoadingFeedbackTemplate3" LoadingPanelPosition="MiddleCenter" LoadingPanelFadeDuration="1000" LoadingPanelFadeMaximumOpacity="60" OnNeedDataSource="LItemGrid_NeedDataSource" OnNeedRebind="LItemGrid_NeedRebind" OnPageIndexChanged="LItemGrid_PageIndexChanged" OnFilterCommand="LItemGrid_FilterCommand" OnSortCommand="LItemGrid_SortCommand" ShowFooter="true" PageSize="10" PagerStyle="Numbered" </Columns> </ComponentArt:GridLevel> </Levels> <ClientTemplates><ComponentArt:ClientTemplate Id="ClientTemplate2"> <table width="200" ><tr><td valign="center" align="center"> <table cellspacing="0" cellpadding="0" border="0"> <tr> <td style="font-size:10px;font-family:Verdana;">Loading...&nbsp;</td> <td><img src="images/spinner.gif" width="16" height="16" border="0"></td> </tr> </table> </td></tr></table> </ComponentArt:ClientTemplate> </ClientTemplates> </ComponentArt:Grid></ContentTemplate> <asp:Button ID="btnClose" runat="server" Text="Close" /> </asp:Panel> <asp:ModalPopupExtender TargetControlID="SaveImageButton1" ID="pnlModal_ModalPopupExtender" runat="server" DynamicServicePath="" Enabled="True" BackgroundCssClass="modalBackground" PopupControlID="pnlModal" CancelControlID="btnClose" DropShadow="true"> </asp:ModalPopupExtender> </ContentTemplate> </asp:UpdatePanel>

    Read the article

  • Working with DataBinding and Page_Load in ASP.NET MVP

    - by Joel
    I'm using WebForms MVP to create some simple reporting applications. Most of these applications consist of a few search criteria inputs and a ComponentArt datagrid that I'm populating with data from the database. Most of the markup is in a UserControl, which is in a content page with a master page. My problem is that the control's Page_Load event is firing before the control events that caused the postback in the first place. Basically, the user clicks the search button, and Page_Load is fired BEFORE Search_Click. This is messing with the databinding scheme I've been using. So that's the question: Why is my Page_Load event firing before the event handler, and what can I do about it? I don't THINK this problem is related to WebForms MVP or ComponentArt, but obviously I could be wrong. Thanks.

    Read the article

  • Chart controls for ASP.NET

    - by tolism7
    I am looking people's opinion and experience on using chart controls within an ASP.NET application (web forms or MVC) primarily but also in any kind of project. I am currently doing my research and I have a pretty big list of controls to evaluate. My list includes (in no particular order): ASP.NET controls: DevExpress XtraCharts (http://demos.devexpress.com/XtraChartsDemos/) Dundas Chart for .NET (http://www.dundas.com/) Telerik RadChart for ASP.NET AJAX (http://www.telerik.com/) ComponentArt Charting & Visualization for ASP.NET (http://www.componentart.com/) Infragistics WebChart (http://www.infragistics.com/dotnet/netadvantage/aspnet.aspx#Overview) .net Charting (http://www.dotnetcharting.com/) Chart Control for .Net Framework (Microsoft's) (http://weblogs.asp.net/scottgu/archive/2008/11/24/new-asp-net-charting-control-lt-asp-chart-runat-quot-server-quot-gt.aspx) Flash controls: FusionCharts v3 (http://www.fusioncharts.com/) XML/SWF Charts (http://www.maani.us/xml%5Fcharts/index.php) amCharts (http://www.amcharts.com/) AnyChart (http://www.anychart.com/home/) Javascript: Flot (http://code.google.com/p/flot/) Flotr (http://solutoire.com/flotr/) jqPlot (http://www.jqplot.com/index.php) (If I missed some that worth to be compared against the above please let me know.) What I am looking is opinions on using any of the above so I can form my own and help others do the same, based on what I read here. I do not care which one is better. What I care for is why someone likes one of the above and what do these controls offer as a distinct advantage. I am interested in developer's opinion and I would like to find out which things are difficult doing with any of the above controls and which things are easy to achieve. AJAX compatibility (build in to the controls but also manual), ASP.NET compatibility, input capabilities, data binding options, performance, how much code does one need to write in order to create a chart, are some of the things that I would want to read about. I have already done my research on StackOverflow for relevant questions but there is nothing on the level of detail that I would want to read in order to make a responsible decision.

    Read the article

  • Which JavaScript or ASP.NET Charting Component/Tool/Library Will Work For This?

    - by Jason Bunting
    [Update]: Forgot to include ComponentArt... Hi, An interaction designer employed by the client I am currently working for produced some mock-ups, and now it is my job to determine the best way of implementing the charts included therein. After looking at the options I am aware of and was able to find doing some simple Google searches, I have narrowed it down to using either ComponentArt, Dundas Charts or Infragistics, simply because from what I can see of their demos, they have certain features I believe I will need to get things done. Here are the pictures from the mock-ups - ideally I need one piece of software that will cover all of these: This chart seems to be simple enough. Notice the arbitrary spacing between the years - not yet sure if this will be a sticking-point for the client or not. I don't know that I have ever seen a chart like this one - it combines the previous chart with some additional data. Here is the same chart, only this time illustrating what happens when a user mouses-over or clicks on an annotation within the chart. They want the nice styling within the pop-up, so the pop-up needs to be something like an iframe or similar. Any ideas or recommendations would be appreciated, I haven't used charting controls in years, so I am at a bit of a loss and the client wants an estimate soon. Thank you!

    Read the article

  • Is it normal that .Net combobox postback always contains data items?

    - by BlueFox
    I have a dynamically populated ComponentArt:ComboBox with Autopostback property set to true. So every time the selection changes, a postback to server would be fired. Everything seems to work fine except that the lists of all available items are also posted back to the server. from Firebug: ComboBox1_Data %3Cr%3E%3Cc%3E%3Cr%3E%3Cc%3E%3Cr%3E%3Cc%3EText%3C%2Fc%3E%3Cc%3E150%20Mile%20House%3C%2Fc%3E%3C%2Fr%3E%3C%2Fc%3E%3C%2Fr%3E%3C%2Fc%3E%3Cc%3E%3Cr%3E%3Cc%3E%3Cr%3E%3Cc%3EText%3C%2Fc%3E%3Cc%3EAach%3C%2Fc%3E%3C%2Fr%3E%3C%2Fc%3E%3C%2Fr%3E%3C%2Fc%3E%3Cc%3E%3Cr%3E%3Cc%3E%3Cr%3E%3Cc%3EText%3C%2Fc%3E%3Cc%3EAachen%3C%2Fc%3E%3C%2Fr%3E%3C%2Fc%3E%3C%2Fr%3E%3C%2Fc%3E%3Cc%3E%3Cr%3E%3Cc%3E%3Cr%3E%3Cc%3EText%3C%2Fc%3E%3Cc%3EAaheim%3C%2Fc%3E%3C%2Fr%3E%3C%2Fc%3E%3C%2Fr%3E%3C%2Fc%3E%3Cc%3E%3Cr%3E%3Cc%3E%3Cr%3E%3Cc%3EText%3C%2Fc%3E%3Cc%3EAakrehamn%3C%2Fc%3E%3C%2Fr%3E%3C%2Fc%3E%3C%2Fr%3E%3C%2Fc%3E%3Cc%3E%3Cr%3E%3Cc%3E%3Cr%3E%3Cc%3EText%3C%2Fc%3E%3Cc%3EAalbeke%3C%2Fc%3E%3C%2Fr%3E%3C%2Fc%3E%3C%2Fr%3E%3C%2Fc%3E%3Cc%3E%3Cr%3E%3Cc%3E%3Cr%3E%3Cc%3EText%3C%2Fc%3E%3Cc%3EAalen%3C%2Fc%3E%3C%2Fr%3E%3C%2Fc%3E%3C%2Fr%3E%3C%2Fc%3E%3Cc%3E%3Cr%3E%3Cc%3E%3Cr%3E%3Cc%3EText%3C%2Fc%3E%3Cc%3EAalst%3C%2Fc%3E%3C%2Fr%3E%3C%2Fc%3E%3C%2Fr%3E%3C%2Fc%3E%3Cc%3E%3Cr%3E%3Cc%3E%3Cr%3E%3Cc%3EText%3C%2Fc%3E%3Cc%3EAalter%3C%2Fc%3E%3C%2Fr%3E%3C%2Fc%3E%3C%2Fr%3E%3C%2Fc%3E%3Cc%3E%3Cr%3E%3Cc%3E%3Cr%3E%3Cc%3EText%3C%2Fc%3E%3Cc%3E%C3%84%C3%A4nekoski%3C%2Fc%3E%3C%2Fr%3E%3C%2Fc%3E%3C%2Fr%3E%3C%2Fc%3E%3Cc%3E%3Cr%3E%3Cc%3E%3Cr%3E%3Cc%3EText%3C%2Fc%3E%3Cc%3EAarau%3C%2Fc%3E%3C%2Fr%3E%3C%2Fc%3E%3C%2Fr%3E%3C%2Fc%3E%3Cc%3E%3Cr%3E%3Cc%3E%3Cr%3E%3Cc%3EText%3C%2Fc%3E%3Cc%3EAarberg%3C%2Fc%3E%3C%2Fr%3E%3C%2Fc%3E%3C%2Fr%3E%3C%2Fc%3E%3Cc%3E%3Cr%3E%3Cc%3E%3Cr%3E%3Cc%3EText%3C%2Fc%3E%3Cc%3EAarbergen%3C%2Fc%3E%3C%2Fr%3E%3C%2Fc%3E%3C%2Fr%3E%3C%2Fc%3E%3Cc%3E%3Cr%3E%3Cc%3E%3Cr%3E%3Cc%3EText%3C%2Fc%3E%3Cc%3EAarburg%3C%2Fc%3E%3C%2Fr%3E%3C%2Fc%3E%3C%2Fr%3E%3C%2Fc%3E%3Cc%3E%3Cr%3E%3Cc%3E%3Cr%3E%3Cc%3EText%3C%2Fc%3E%3Cc%3EAarebakken%3C%2Fc%3E%3C%2Fr%3E%3C%2Fc%3E%3C%2Fr%3E%3C%2Fc%3E%3Cc%3E%3Cr%3E%3Cc%3E%3Cr%3E%3Cc%3EText%3C%2Fc%3E%3Cc%3EAarschot%3C%2Fc%3E%3C%2Fr%3E%3C%2Fc%3E%3C%2Fr%3E%3C%2Fc%3E%3Cc%3E%3Cr%3E%3Cc%3E%3Cr%3E%3Cc%3EText%3C%2Fc%3E%3Cc%3EAarsele%3C%2Fc%3E%3C%2Fr%3E%3C%2Fc%3E%3C%2Fr%3E%3C%2Fc%3E%3Cc%3E%3Cr%3E%3Cc%3E%3Cr%3E%3Cc%3EText%3C%2Fc%3E%3Cc%3EAartrijke%3C%2Fc%3E%3C%2Fr%3E%3C%2Fc%3E%3C%2Fr%3E%3C%2Fc%3E%3Cc%3E%3Cr%3E%3Cc%3E%3Cr%3E%3Cc%3EText%3C%2Fc%3E%3Cc%3EAartselaar%3C%2Fc%3E%3C%2Fr%3E%3C%2Fc%3E%3C%2Fr%3E%3C%2Fc%3E%3Cc%3E%3Cr%3E%3Cc%3E%3Cr%3E%3Cc%3EText%3C%2Fc%3E%3Cc%3EAavasaksa%3C%2Fc%3E%3C%2Fr%3E%3C%2Fc%3E%3C%2Fr%3E%3C%2Fc%3E%3C%2Fr%3E ComboBox1_Input Aalst ComboBox1_SelectedIndex 7 As most my clients are using slow connections, this amount of postback has a huge impact on their user experience. Since I'm storing the viewstates in session already, there's really no need for any of the component to restore states from the client. So I'm wondering if this is normal for ComponentArt:ComboBox to do this and not other controls, or this is the normal way of doing things?

    Read the article

  • Which datagrid to use for ASP.NET MVC2 project?

    - by Nick
    Hi, I am developing a commercial MVC2 app that requires a grid that has callback update in some form to support 10,000+ rows. It should also support relatively rich content (icons, multiline descriptions etc). Although it requires the usual paging/scrolling/sorting features it does not need support for grouping. So nothing that special. The commercial grids I looked at were Component Art (http://www.componentart.com/products/aspnetmvc/datagrid/) and Telerik (http://www.telerik.com/products/aspnet-mvc/grid.aspx) which both look pretty good but may be a little OTT for what I need. They are also $800 and $999 respectively (1 developer). I've also looked at jqGrid (http://www.trirand.net/download.aspx) and the grid from MvcContrib. These appear ok but for a commercial app I am concerned that these may be risky options - though could be wrong there. I'd really appreciate any views/exprience on either the above grids or perhaps you can suggest a better option/approach. FYI I am using EF4 and C#. Cheers

    Read the article

  • Most performant ASP.NET web controls suite

    - by DotNetter
    Personally I've been working for years with Telerik's RadControls and DevExpress ASP.NET controls. IMHO they both produce quite a lot HTML overhead on the client side thus for that I've never been highly pleased with them. I also know about Infragistics, ComponentOne, ComponentArt, etc. How are these? I'd assume they are not much different than those I mentioned. Which (commercial) controls suite generates the most compact HTML on the client side? Do you have any recommendations?

    Read the article

  • Recommed html element theme engine for ASP.NET ?

    - by TatMing
    Sorry about my bad english, i am chinese live in HongKong* Is it any theme or css framework can apply to ASP.NET? I work with ASP.NET webform, everybody known web controls generate pure html to work. But i am not good at graphic design, so i want to find some UI helper. I already work with jQuery and Ajax Controll Tookit,but it not much help to make a modern UI design. I have found some commercial library like ComponentArt,DevExpress etc, but is it any free or opensource i can use?

    Read the article

  • Microsoft Declares the Future of ASP.NET is Web API

    - by sbwalker
    Sitting on a plane on my way home from Tech Ed 2012 in Orlando, I thought it would be a good time to jot down some key takeaways from this year’s conference. Some of these items I have known since the Microsoft MVP Summit which occurred in Redmond in late February ( but due to NDA restrictions I could not share them with the developer community at large ) and some of them are a result of insightful conversations with a wide variety of industry insiders and Microsoft employees at the conference. First, let’s travel back in time 4 years to the Microsoft MVP Summit in 2008. Microsoft was facing some heat from market newcomer Ruby on Rails and responded with a new web development framework of its own, ASP.NET MVC. At the Summit they estimated that MVC would only be applicable for ~10% of all new web development projects. Based on that prediction I questioned why they were investing such considerable resources for such a relative edge case, but my guess is that they felt it was an important edge case at the time as some of the more vocal .NET evangelists as well as some very high profile start-ups ( ie. Twitter ) had publicly announced their intent to use Rails. Microsoft made a lot of noise about MVC. In fact, they focused so much of their messaging and marketing hype around MVC that it appeared that WebForms was essentially dead. Yes, it may have been true that Microsoft continued to invest in WebForms, but from an outside perspective it really appeared that MVC was the only framework getting any real attention. As a result, MVC started to gain market share. An inside source at Microsoft told me that MVC usage has grown at a rate of about 5% per year and now sits at ~30%. Essentially by focusing so much marketing effort on MVC, Microsoft actually created a larger market demand for it.  This is because in the Microsoft ecosystem there is somewhat of a bandwagon mentality amongst developers. If Microsoft spends a lot of time talking about a specific technology, developers get the perception that it must be really important. So rather than choosing the right tool for the job, they often choose the tool with the most marketing hype and then try to sell it to the customer. In 2010, I blogged about the fact that MVC did not make any business sense for the DotNetNuke platform. This was because our ecosystem relied on third party extensions which were dependent on the WebForms model. If we migrated the core to MVC it would mean that all of the third party extensions would no longer be compatible, which would be an irresponsible business decision for us to make at the expense of our users and customers. However, this did not stop the debate from continuing to occur in our ecosystem. Clearly some developers had drunk Microsoft’s Kool-Aid about MVC and were of the mindset, to paraphrase an old Scottish saying, “If its not MVC, it’s crap”. Now, this is a rather ignorant position to take as most of the benefits of MVC can be achieved in WebForms with solid architecture and responsible coding practices. Clean separation of concerns, unit testing, and direct control over page output are all possible in the WebForms model – it just requires diligence and discipline. So over the past few years some horror stories have begun to bubble to the surface of software development projects focused on ground-up rewrites of web applications for the sole purpose of migrating from WebForms to MVC. These large scale rewrites were typically initiated by engineering teams with only a single argument driving the business decision, that Microsoft was promoting MVC as “the future”. These ill-fated rewrites offered no benefit to end users or customers and in fact resulted in a less stable, less scalable and more complicated systems – basically taking one step forward and two full steps back. A case in point is the announcement earlier this week that a popular open source .NET CMS provider has decided to pull the plug on their new MVC product which has been under active development for more than 18 months and revert back to WebForms. The availability of multiple server-side development models has deeply fragmented the Microsoft developer community. Some folks like to compare it to the age-old VB vs. C# language debate. However, the VB vs. C# language debate was ultimately more of a religious war because at least the two dominant programming languages were compatible with one another and could be used interchangeably. The issue with WebForms vs. MVC is much more challenging. This is because the messaging from Microsoft has positioned the two solutions as being incompatible with one another and as a result web developers feel like they are forced to choose one path or another. Yes, it is true that it has always been technically possible to use WebForms and MVC in the same project, but the tooling support has always made this feel “dirty”. The fragmentation has also made it difficult to attract newcomers as the perceived barrier to entry for learning ASP.NET has become higher. As a result many new software developers entering the market are gravitating to environments where the development model seems more simple and intuitive ( ie. PHP or Ruby ). At the same time that the Web Platform team was busy promoting ASP.NET MVC, the Microsoft Office team has been promoting Sharepoint as a platform for building internal enterprise web applications. Sharepoint has great penetration in the enterprise and over time has been enhanced with improved extensibility capabilities for software developers. But, like many other mature enterprise ASP.NET web applications, it is built on the WebForms development model. Similar to DotNetNuke, Sharepoint leverages a rich third party ecosystem for both generic web controls and more specialized WebParts – both of which rely on WebForms. So basically this resulted in a situation where the Web Platform group had headed off in one direction and the Office team had gone in another direction, and the end customer was stuck in the middle trying to figure out what to do with their existing investments in Microsoft technology. It really emphasized the perception that the left hand was not speaking to the right hand, as strategically speaking there did not seem to be any high level plan from Microsoft to ensure consistency and continuity across the different product lines. With the introduction of ASP.NET MVC, it also made some of the third party control vendors scratch their heads, and wonder what the heck Microsoft was thinking. The original value proposition of ASP.NET over Classic ASP was the ability for web developers to emulate the highly productive desktop development model by using abstract components for creating rich, interactive web interfaces. Web control vendors like Telerik, Infragistics, DevExpress, and ComponentArt had all built sizable businesses offering powerful user interface components to WebForms developers. And even after MVC was introduced these vendors continued to improve their products, offering greater productivity and a superior user experience via AJAX to what was possible in MVC. And since many developers were comfortable and satisfied with these third party solutions, the demand remained strong and the third party web control market continued to prosper despite the availability of MVC. While all of this was going on in the Microsoft ecosystem, there has also been a fundamental shift in the general software development industry. Driven by the explosion of Internet-enabled devices, the focus has now centered on service-oriented architecture (SOA). Service-oriented architecture is all about defining a public API for your product that any client can consume; whether it’s a native application running on a smart phone or tablet, a web browser taking advantage of HTML5 and Javascript, or a rich desktop application running on a PC. REST-based services which utilize the less verbose characteristics of JSON as a transport mechanism, have become the preferred approach over older, more bloated SOAP-based techniques. SOA also has the benefit of producing a cross-platform API, as every major technology stack is able to interact with standard REST-based web services. And for web applications, more and more developers are turning to robust Javascript libraries like JQuery and Knockout for browser-based client-side development techniques for calling web services and rendering content to end users. In fact, traditional server-side page rendering has largely fallen out of favor, resulting in decreased demand for server-side frameworks like Ruby on Rails, WebForms, and (gasp) MVC. In response to these new industry trends, Microsoft did what it always does – it immediately poured some resources into developing a solution which will ensure they remain relevant and competitive in the web space. This work culminated in a new framework which was branded as Web API. It is convention-based and designed to embrace native HTTP standards without copious layers of abstraction. This framework is designed to be the ultimate replacement for both the REST aspects of WCF and ASP.NET MVC Web Services. And since it was developed out of band with a dependency only on ASP.NET 4.0, it means that it can be used immediately in a variety of production scenarios. So at Tech Ed 2012 it was made abundantly clear in numerous sessions that Microsoft views Web API as the “Future of ASP.NET”. In fact, one Microsoft PM even went as far as to say that if we look 3-4 years into the future, that all ASP.NET web applications will be developed using the Web API approach. This is a fairly bold prediction and clearly telegraphs where Microsoft plans to allocate its resources going forward. Currently Web API is being delivered as part of the MVC4 package, but this is only temporary for the sake of convenience. It also sounds like there are still internal discussions going on in terms of how to brand the various aspects of ASP.NET going forward – perhaps the moniker of “ASP.NET Web Stack” coined a couple years ago by Scott Hanselman and utilized as part of the open source release of ASP.NET bits on Codeplex a few months back will eventually stick. Web API is being positioned as the unification of ASP.NET – the glue that is able to pull this fragmented mess back together again. The  “One ASP.NET” strategy will promote the use of all frameworks - WebForms, MVC, and Web API, even within the same web project. Basically the message is utilize the appropriate aspects of each framework to solve your business problems. Instead of navigating developers to a fork in the road, the plan is to educate them that “hybrid” applications are a great strategy for delivering solutions to customers. In addition, the service-oriented approach coupled with client-side development promoted by Web API can effectively be used in both WebForms and MVC applications. So this means it is also relevant to application platforms like DotNetNuke and Sharepoint, which means that it starts to create a unified development strategy across all ASP.NET product lines once again. And so what about MVC? There have actually been rumors floated that MVC has reached a stage of maturity where, similar to WebForms, it will be treated more as a maintenance product line going forward ( MVC4 may in fact be the last significant iteration of this framework ). This may sound alarming to some folks who have recently adopted MVC but it really shouldn’t, as both WebForms and MVC will continue to play a vital role in delivering solutions to customers. They will just not be the primary area where Microsoft is spending the majority of its R&D resources. That distinction will obviously go to Web API. And when the question comes up of why not enhance MVC to make it work with Web API, you must take a step back and look at this from the higher level to see that it really makes no sense. MVC is a server-side page compositing framework; whereas, Web API promotes client-side page compositing with a heavy focus on web services. In order to make MVC work well with Web API, would require a complete rewrite of MVC and at the end of the day, there would be no upgrade path for existing MVC applications. So it really does not make much business sense. So what does this have to do with DotNetNuke? Well, around 8-12 months ago we recognized the software industry trends towards web services and client-side development. We decided to utilize a “hybrid” model which would provide compatibility for existing modules while at the same time provide a bridge for developers who wanted to utilize more modern web techniques. Customers who like the productivity and familiarity of WebForms can continue to build custom modules using the traditional approach. However, in DotNetNuke 6.2 we also introduced a new Service Framework which is actually built on top of MVC2 ( we chose to leverage MVC because it had the most intuitive, light-weight REST implementation in the .NET stack ). The Services Framework allowed us to build some rich interactive features in DotNetNuke 6.2, including the Messaging and Notification Center and Activity Feed. But based on where we know Microsoft is heading, it makes sense for the next major version of DotNetNuke ( which is expected to be released in Q4 2012 ) to migrate from MVC2 to Web API. This will likely result in some breaking changes in the Services Framework but we feel it is the best approach for ensuring the platform remains highly modern and relevant. The fact that our development strategy is perfectly aligned with the “One ASP.NET” strategy from Microsoft means that our customers and developer community can be confident in their current and future investments in the DotNetNuke platform.

    Read the article

facebook twitter digg google delicious technorati stumbleupon myspace wordpress linkedin gmail igoogle windows live tumblr viadeo yahoo buzz yahoo mail yahoo bookmarks favorites email print

1