Products

Solutions

Resources

Partners

Community

Blog

About

QA

Ideas Test

New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

Welcome to the DNN Community Forums, your preferred source of online community support for all things related to DNN.
In order to participate you must be a registered DNNizen

HomeHomeDNN Open Source...DNN Open Source...Module ForumsModule ForumsForm and ListForm and ListReferencing calculated fieldsReferencing calculated fields
Previous
 
Next
New Post
11/29/2012 4:03 PM
 

I am starting to realize that you can only reference a calculated field from within another calculated field, not a text field or an email field. It would be very nice to be able to put in either a text or email field, a default value of [field:CalcMyField] and have the value be represented. I have tried this and got no value at all. If I leave out the 'field:' part and only have [CalcMyField], I get those characters as a literal in the value of the field.

If I should post this as a feature request on the Forge, or elsewhere, please let me know. I just want to make sure that I am not doing something wrong and that you can portray the value of a calculated field in another (albeit non-calculated) field.

Why I want to do this: Outlook has this neat feature that when you drag and drop an email to your Contacts folder, it pops up the Add New Contact window and pre-populates the Name and Email fields with the parsed 'From' email field in the incoming email. So an incoming email with a From address of Joe Smith [joe@abc.com] gets dealt with nicely. In FnL, I would like to combine a 'Name' field with an 'Email' field to create a 'From' field for the email message. I created a calculated field, CalcEmail, that constructs the requsite string with the name before the email address. Being a calculated field, it cannot be used for an email address, since the validator checks that the field type is 'Email'. Therefore, I tried to create another field of type 'Email', called EmailName and have it's default value be taken from the CalcEmail field, using a default value of [field:CalcEmail]. After all my trials, I believe this is not currently possible, correct?

Thanks for any insights.

 
New Post
11/29/2012 5:53 PM
 

Thomas, a very good -and detailed - question.

The main problem is that the from/to/cc/bcc settings are only supporting fields that guarantee valid email addresses (or field is empty) . It is not only email, but also link to user or created by/ changed by. Technically, the datatype needs to implement the interface IEmailAddressSource - as the email address is maybe not directly part of the stored value.

The datatype calculated column doesn't implement that interface. The token approach [fileld:fieldname] supplements calculated expressions but works different.  It is often used to initialize values in form, but also for example for captions in links. You requirement is similar, but tokens won't help here. It is not a question about the rendered output - as the passed email address is retrieved by the interface.

So you have two options:

  • Add a work item and ask for a modification of the datatype email to add a new setting display name.  
  • Write your own custom datatype, for example a modification of calculated column which supports the interface.

Stefan   


 
New Post
11/29/2012 6:52 PM
 

Thanks for your reply, Stefan. I now see that the solution is a little more complex than I had thought.

I am reluctant to implement a modified version of this core module, since that would place it outside of the update stream. I'd rather see if I can get a feature implemented in a future version of this module.

When you suggest I add a work item, I presume you are talking about the Extension Forge for this project. However, I don't see anyplace to add a work item; only Reviews. Gemini seems to be only for the core. Perhaps I am missing something, yes?

Also, you suggested I might ask for a modification of the email datatype to add a new setting display name. Presumably that would allow an email datatype to get a value from a calculated field. However, I imagine that to look like tokens and use rendered output, which you said wouldn't work, so I must be misunderstanding that.

I am thinking that perhaps a new option on the caclulated column datatype could allow it to support the IEmailAddressSource interface and might be cleanest. The user interface on the Calculated datatype might be a checkbox for "Allow use as email field" or something like that.

Thanks for your guidance on this issue.

-Thomas.

 
New Post
11/30/2012 10:42 AM
 

A custom datatype doesn't require any changes to Form and List source. In fact, it even doesn't require Visual Studio or a compilation. It can be as simple as these steps:

1. Save the following code as file to  ~/App_Code/DataTypeExpessionEmail.cs 

using System.Data;
using DotNetNuke.Modules.UserDefinedTable.Components;
using DotNetNuke.Modules.UserDefinedTable.DataTypes;
using DotNetNuke.Modules.UserDefinedTable.Interfaces;

public class DataTypeExpessionEmail : DataTypeExpression, IEmailAdressSource
{
    public string GetEmailAddress(string fieldName, DataRow row)
    {
        return row[fieldName].AsString();
    }
}

2. Edit ~/desktopmodules/userdefinedtable/datatypes.config and change

<dataType name="Expression"/>

to

<dataType name="Expression" typeName="DataTypeExpessionEmail"/>

3. Done

Now you have replaced the datatype for a caclulated column (which names DataTypeExpression) with a custom modification that also implements the required email interface.

There is one downside: An update of formandlist would overwrite datatypes.config again.

This modification would fullfill your requirements, but I would never use that kind of code in a new version. There is no validation which ensures that the email address is valid. 

 
New Post
11/30/2012 1:59 PM
 

Thanks Stefan! I had no idea it would be so easy to implement. Your point about validation is a good one. I am already validating the Email field, but I should also validate the Name field so it doesn't have any funny stuff in it.

As described on Wikipedia,
To indicate for whom the message is intended, a user can use the "display name" of the recipient followed by the address specification surrounded by angled brackets, for example: John Smith <john.smith@example.org>.

 I ran into trouble with that with the error log showing

InnerException: An invalid character was found in the mail header: '>'.

Method: System.Net.Mail.DotAtomReader.ReadReverse

StackTrace:

Message: DotNetNuke.Services.Exceptions.ModuleLoadException: An invalid character was found in the mail header: '>'. ---> System.FormatException: An invalid character was found in the mail header: '>'. at System.Net.Mail.DotAtomReader.ReadReverse(String data, Int32 index) at System.Net.Mail.MailAddressParser.ParseDomain(String data, Int32& index) at System.Net.Mail.MailAddressParser.ParseAddress ...

Therefore, I tried an experiment where I just used the Email field as the sole input to the calculated field. The expression was [Email]

The result was another error in the log:
The specified string is not in the form required for an e-mail address.

Method: System.Net.Mail.MailAddressParser.ParseAddress

StackTrace:

Message: DotNetNuke.Services.Exceptions.ModuleLoadException: The specified string is not in the form required for an e-mail address. ---> System.FormatException: The specified string is not in the form required for an e-mail address. at System.Net.Mail.MailAddressParser.ParseAddress(String data, Boolean expectMultipleAddresses, Int32& index) at System.Net.Mail.MailAddressParser.ParseAddress(String data) at System.Net.Mail.MailAddress..ctor(String address, String displayName, Encoding displayNameEncoding) at DotNetNuke.Services.Mail.Mail.SendMail(String mailFrom, String mailTo, String cc, String bcc, String replyTo, MailPriority priority, String subject, MailFormat bodyFormat, Encoding bodyEncoding, String body, List`1 attachments, String smtpServer, String smtpAuthentication, String smtpUsername, String smtpPassword, Boolean smtpEnableSSL) at ...

I think the calculated field may have an extra space added at the front and end, since appended characters show a spaces around the field value in the List mode when the calculate field is displayed. For example, an expression of '[<'+[Email]+'>]' produces this in the List: < joe@abc.com > and I can't seem to get rid of the spaces. So I am wondering if specifying the expression of [Email] produces " joe@abc.com " and that is perhaps what the MailAddressParser is complaining about.

Anyway, if it is complaining about a single space, it likely will not accept the Display Name before the address either. So maybe this plan won't work afterall.

Any thoughts?

Thanks again for your insights.

 

 
Previous
 
Next
HomeHomeDNN Open Source...DNN Open Source...Module ForumsModule ForumsForm and ListForm and ListReferencing calculated fieldsReferencing calculated fields


These Forums are dedicated to discussion of DNN Platform and Evoq Solutions.

For the benefit of the community and to protect the integrity of the ecosystem, 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 DNN.
  2. No vendor trolling / poaching. If someone posts about a vendor issue, allow the vendor or other customers to respond. Any post that looks like trolling / poaching will be removed.
  3. Discussion or promotion of DNN Platform product releases under a different brand name are strictly prohibited.
  4. No Flaming or Trolling.
  5. No Profanity, Racism, or Prejudice.
  6. Site Moderators have the final word on approving / removing a thread or post or comment.
  7. English language posting only, please.
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out