This article aims at helping developers understand the latest offerings available in DotNetNuke 7.0.0.
With the 7.0 release, DotNetNuke has changed pre-requisites for installation/upgrade. These are required for a number of reasons, but primarily to utilize the Web API from Microsoft and leverage some additional new capabilities of .net 4.0.
Services Framework built on top of ASP.Net WebAPI
Services Framework allows developers to easily create a Web API that any "device" that speaks HTTP can call. In this sense "device" can be almost anything such as a smart phone, curl script, XmlHttpRequest. Almost anything that has an internet connection will do, and that means if you can write code for it, Services Framework will probably help you to integrate it with your DotNetNuke site. The single biggest convenience of Services Framework is that authentication, authorization and establishing a DotNetNuke context are all built in.
Services Framework is built on top of ASP.Net WebAPI. There are only a couple of small things that must be done a bit different in Services Framework than in ASP.Net WebAPI. In almost all cases when the question "How do I do X with Services Framework?" comes up, the answer is "The same way you do it in ASP.Net WebAPI.".
Modules utilizing 6.2.x services framework need to be updated for 7.0
Due to breaking changes explained above, modules which utilized the services framework in 6.2.x versions will need to be updated for 7.0 in order to operate. It is also worth noting that any module that utilizes notifications with custom API's call will also need to be updated.
Social Groups And Security Roles
Role and Social Group Renaming
-Social Groups can now be renamed.
- Security Roles can also be renamed with the exception of System Roles
- System Roles(Administrators, Registered Users, Subscribers, Unverified Users) are marked as IsSystemRole in the database and thus cannot be renamed.
- Security Roles can now have multiple owners.
Social Group Filtering
- Social Groups have new settings under Group Module Settings such as Enable Search, Sort Field and Sort Direction, Page Size
DotNetNuke has always shipped with Public set as it's default portal (site) Registration Type. This was a decision that was inherited from the IBuySpy portal codebase that early versions of DotNetNuke utilized, and whilst it has advantages in enabling users to sign up immediately after installation, there are some drawbacks. Analysis of 18 months of security issues showed that 44% of them required the potential hacker to have a valid, authorized user account to start off with. As many sites ultimately aren't intended for public users (e.g. a personal site may have only one user or a business site may use active directory integration), the decision was made to change the site registration type to "Private" in 7.0.0
The default.css is one of the most important files as it is responsible for how DotNetNuke looks and helps to establish the user experience. It has over time collected styles for features that have been removed or changed and has collected declarations to mitigate upgrade concerns from legacy versions of DotNetNuke; consequently, this file has become inadvertently bloated with redundant styles, overwrites, and workarounds. These deviations can affect many of the more delicate rendering behaviors of browsers and can make skin and module development a challenge. In addition, these nuisances have made it difficult to validate default.css for standards compliance as well as made for a much larger CSS file. Furthermore, DNN team wanted to introduce some more exciting and advanced UI features in DotNetNuke 7.0 which has encouraged us to re-evaluate default.css file in order to determine a style framework that could support them.
Enhanced Installer log
DotNetNuke 7.0.0 introduces a new "Installer" log that logs actions (both information and errors) that occur during installation, upgrade and extension installation.
Introduced DAL 2
DotNetNuke has introduced a new (optional) datalayer, that utilizes a micro-orm called Peta-Poco. It provides the following:
- A close-to-the-metal option to execute any sql - basic SqlHelper like functionality. This would allow us to replace SqlHelper with a PetaPocoHelper class, which we have done in the core.
- Fetch (retrieve) methods that can take a parameterized SQL snippet as a parameter e.g.. “WHERE PortalID = @0”, thus reducing the overhead of creating and managing stored procedures.
- Page methods that can auto-generate the sql required to return a page of data from the database.
- Simple methods to Insert, Update and Delete “objects” in the database, with no need to write any sql.
- An IMapper interface which, while it doesn’t support cross-table mapping, will support things like an object qualifier (or table prefix)
Currently rated 0.0 by 0 people