Saturday, January 23, 2010

DotNetNuke - Alternative for using getTabByName or getTab - Part 2

If you have gone through this post you will find that there are alternatives like storing the TabIds in session state, or cache, or creating entries in siteUrl.config. In this post we will see some more options regarding the same problem and advantages and disadvantages of all of them.

Let's look at other two options that are available:

(1) Accessing Tabs without tabId is another option that you can choose. Good thing is you don't have to worry about tabId and bad thing with this is it will not work with querystring params.

(2) Store the tab ids you require by providing a module setting. If you choose this option, you have to create a settings page which provides a drop down for each tab that you are using link of navigation, and you can then simply use the tab id stored in settings everytime. Good thing is that all other information along with the tab id is not loaded from the database.

Now Let's look at the detail of each method:
(1) Session State:

Good When: If you are using the tabId in the session that is strongly depend to the current session (for example link to user's profile) it's good to store the tabId in the session. But that doesn't mean I'm in favour of adding entire TabInfo object in to the session, If you want to use TabId only, you can directly add TabId into the session. If you are using more than one tab you can maintain hash table. Use some utility class for boxing and unboxing the HasTable from the session.

Not Good when: If your module needs a tab that is providing navigation to other related tabs of the site, that are static (for example a help page for the module of features) you should not use session, as it will aquire large set of memory for the sites that are heavy loeaded with users.
Multi-Portal Considerations: Works fine if module is used in multi-portal or not.

(2) Cache:

Good When: storing the link of tab that is not dependent on session. 'Not Good When' for sessuib state is resolved with the cache. If you are new to dnn data cache, please go through the help articles before doing anything.

Not Good When: I don't see any disadvantages of using cache if used properly. Common problems with using caches are, refreshing and populating the cache at correct time, If you are good enough to understand that, there are no problems with this. I will recommend to google this for getting in-depth understanding of this topic.

Multi-Portal Considerations: Works fine if module is used in multi-portal or not, but it's good practice to add portalId at the end of the key if you are planning to use the module in multi-portal environment.

(3) SiteUrl.Config:

Good When: you have small number of static tabs to redirect. You can just create an entry and use it from any where in any modules. I've used this trick many times to show user's shopping cart from anywhere in the site by redirecting them to shoppingCart.aspx. You can use it for the same purpose.

Not Good When: NA

Multi-Portal Considerations: If you are dealing with multiple portals having same tab name, Either you have to create site url entries with different names or you cannot do it. For example, if you are using this feature for help, you cannot give all the tab's name as help.aspx, but you can do it help1.aspx, help2.aspx which is possible. or It may be possible, But I am not able to find the correct solution for this. But atleast consider this when you are in multi-portal module development.

(4) Tab Names:

Good When: You are sure that you will never change the tab name

Not Good When: You are using Query string

Multi-portal Considerations: No worries, works fine without any problems.

(5) Module Settings:

Good When: You are not sure what would be the tab name when you deploy the page (because only client can name it correcly ;) ) so, it's wise decision to provide ui with Drop downs to store the it as a module setting once and forget for the rest of the life time after that.

Not Good When: you have a module that is accessing database agressively, this will add additional data access load to the database server. Bad thing with this is you cannot control number of round trips to the database for a specific instance of the

Multi-portal Considerations: It's not possible to deploy local setting with dnn portal templates using export featrues.

I hope this is useful to you when you develop modules.

No comments:

Post a Comment

Please add your valuable comments about this post if it helped you. Thanks