tailieunhanh - Professional DotNetNuke ASP.NET Portals wrox phần 7

Giao diện của DotNetNuke được thiết kế với kiến trúc sử dụng skin cho phép tách biệt nội dung và giao diện của hệ thống. Kiến trúc này cho phép người thiết kế giao diện có khả năng làm việc độc lập với quá trình phát triển trong và chỉ đòi hỏi kiến thức về HTML cùng với cách thức thiết kế skin của DotNetNuke. | Chapter 8 and determines whether the user is anonymous or authenticated then proceeds to store the request in cache. Anonymous users are also given a temporary cookie so they are not counted twice in the future. A scheduled job from the Scheduler executes every minute on a background thread pulling the relevant details out of cache and updating them in the database it will also clear up any old records. The records are stored within two tables AnonymousUsers and UsersOnline. This HTTP module is a good module to disable comment out of config if you do not need this information within your portal. Alternatively you can just disable it in Host Settings. DNNMembership The DNNMembership HTTP module performs tasks around the security of a user. It stores role information about a user in an HTTP cookie to save requesting the same information again and performs security checks for users switching portals. There is no real need to extend this module because it is critical to DotNetNuke s operation. Personalization The personalization HTTP module is very similar to the Microsoft-provided Profile HTTP module and in fact was based on the same concept just integrated much earlier. It loads a user s personalized information into a serialized XML object at the beginning of the request and saves it at the end of the request. If you are interested in storing personalized information about a user see the personalization classes under Components Personalization . Module Interfaces Modules represent a discrete set of functionality that can extend the portal framework. In past versions of DotNetNuke module interactions with the portal were primarily limited to making method calls into the core portal APIs. While this one-way interaction provides some ability to utilize portal services and methods within the module it limits the ability of the portal to provide more advanced services. In order to provide two-way interactions with modules the portal needs to have a mechanism to make .