Small width layout Medium width layout Maximum width layout Small text Medium text Large text
     Search
Downloads Downloads Directory Directory Forums Forums Forge Forge Blogs Blogs        Marketplace Marketplace Careers Program Careers
Community › Forums Register  |  

telerik -- supercharge your DNN websites
  Ads  
OnyakTech
 


  Sponsors  

Meet Our Sponsors

Red-Gate Software
MaximumASP
SourceGear - Tools for Developers
.: CounterSoft :.
telerik
ExactTarget email software solutions
 


DotNetNuke Forums
 
  Forum  General DotNetN...  Extend It! ( Pr...  Custom Library component best practice
Previous Previous
 
Next Next
New Post 5/25/2008 2:15 AM
Unresolved
User is offline Neil Burnett
34 posts
10th Ranked


Custom Library component best practice 

I want to change the functionality of a library component property (UserInfo.Email) to do what I want (return a preset email address for testing).

I am simply modifying the component directly and recompiling for now, but is there a better way I should be approaching this?

 
New Post 5/27/2008 8:53 PM
User is offline Wes Tatters
410 posts
8th Ranked




Re: Custom Library component best practice 

You should really try to avoid making any changes to the DNN core framework if you want to maintain future compatibility.

Having said that - given what you seem to be doing - there is probably not any other quick way to achieve what you need for testing purposes.

If however you wanted a longterm change to the functionaly of say the email property - you would most likely need to look at creating
a custom membership provider in the case of the email property or profile provider for other profile properties -
instead of changing the core code.

Westa

 
New Post 5/28/2008 9:08 AM
User is offline Mitch Sellers
5712 posts
www.mitchelsellers.com
3rd Ranked




Re: Custom Library component best practice 

Rather than changing the core code for your example, I would simply offload the existing e-mail addresses to a temporary table and update the users table to have the default address.


-Mitchel Sellers
MCITP, MCPD, MCTS
CEO/Director of Development - IowaComputerGurus Inc.
LinkedIn Profile

Visit mitchelsellers.com for my mostly DNN Blog and support forum.

Visit IowaComputerGurus.com for free DNN Modules, DNN Consulting Quotes, and DNN Technical Support Services

I reccomend 3Essentials for shared hosting and BaseCamp for project management
 
New Post 6/2/2008 1:54 AM
User is offline Neil Burnett
34 posts
10th Ranked


Re: Custom Library component best practice 

@Wes - Thanks for the thoughts. It seems that Mail.vb is used directly by a dozen or more .ascx files as well as inside modules and membership providers. Maybe commercial modules will use it too. This means a custom membership provider may not help as there could be functionality that uses Mail.SendMail that needs to be tested elsewhere . The custom membership provider would need to know that the email address was being requested for use in an email rather than for any other purpose (user details form form example).

If the asp.net class SmtpClient had a SendStarted event as well as a SendCompleted event, then it might be simple. Until then, I could always add this event in a wrapper class (two send methods each with two signatures would need to have the SendStarted event fired) around SmtpClient then use the wrapper in Mail.vb. Then an httpModule could sort out the test address.Still core changes though as I can't directly inject the wrapped class into Mail. Besides, It gets complex here as MailMessage.To is read only.

Maybe the core team could be persuaded to add (in 4.8.04?)  a SendPreparationStarted event in Mail.SendMail to allow for changes like this and others? I imagine a future release will have dependency injection, but that is probably a long way off.

So for now, if I need to change Mail.vb anyway, then I can simply add the 3 lines of code needed to test for a cookie (with Test Address) then change the MailTo local variable accordingly. This is what I have done currently to get the functionality.

 

 
New Post 6/2/2008 1:59 AM
User is offline Neil Burnett
34 posts
10th Ranked


Re: Custom Library component best practice 

@Mitch - Thanks for the sugestion. That would work fine on a dev site which only uses the local database. Most of my clients will need email verification via a remote database, as well as login by email address , so the email needs to be accurate (and unique) for that to work. Thus  I am unsure if this approach would be practical in my case. I am hoping to get a procedure worked out that can be used at any time when new functionality is added or changed on the site. Automated testing of this functionality is also something I want to achieve.

 
Previous Previous
 
Next Next
  Forum  General DotNetN...  Extend It! ( Pr...  Custom Library component best practice
 


Forum Policy

These Discussion Forums are dedicated to the discussion of the DotNetNuke Web Application Framework.

For the benefit of the community and to protect the integrity of the project, please observe the following posting guidelines:

1. No Advertising. This includes promotion of commercial and non-commercial products or services which are not directly related to DotNetNuke.
2. Discussion or promotion of DotNetNuke product releases under a different brand name are strictly prohibited.
3. No Flaming or Trolling.
4. No Profanity, Racism, or Prejudice.
5. Site Moderators have the final word on approving/removing a thread or post or comment.
6. English language posting only, please.

 


Active Modules, Inc.
Creators of Active Forums, the best forum module for DotNetNuke
www.activemodules.com
DotNetNuke Marketplace - Modules & Skins
The DotNetNuke Marketplace is the official e-commerce gateway for the DNN ecosystem. It's the place to buy and sell DotNetNuke modules, DotNetNuke skins, and other DNN offerings.
DotNetNuke Marketplace
ExactTarget Email Marketing Software and Solutions
ExactTarget delivers on-demand email software solutions for permission-based email marketing. ExactTarget offers solutions that meet the needs of all industry verticals and all size organizations, including SMB, corporate divisions, not-for-profits, large retail/direct marketers, agencies and enterprises.
ExactTarget.com

DotNetNuke Corporation   Terms Of Use  Privacy Statement
DotNetNuke®, DNN®, and the DotNetNuke logo are trademarks of DotNetNuke Corporation
Hosted by MaximumASP