Design advice: email collection

Design advice: email collection

Old forum URL: forums.lhotka.net/forums/t/5989.aspx


ajj3085 posted on Saturday, December 13, 2008

Hi,

I have a use case where the user will be entering multiple email addresses.  I'm trying to figure out the best way to handle this.  Here's what I've come up with.

1.  A string.  The string will contain addresses separated by ; which is what the System.Net.StmpMail class expects.
2.  A simple string[] or List<string>.  Doesn't require any more classes, but keeps the addresses separate.  however, I'll need to join to a single string anyway.
3.  EmailAddresses BLB, containing EmailAddress.   This would allow business rules and such... although I don't have any validation requirements as of now.  The problem is that the UI is geared toward option one; just a text box to enter.

What do you guys think?

Thanks
Andy

sergeyb replied on Saturday, December 13, 2008

I’d vote for option three.  There actually are rules of email addresses that are global.  If you search for reg ex for email address, you will find it.  It does not assure that the address is valid, but it will catch typos.

 

Sergey Barskiy

Principal Consultant

office: 678.405.0687 | mobile: 404.388.1899

cid:_2_0648EA840648E85C001BBCB886257279
Microsoft Worldwide Partner of the Year | Custom Development Solutions, Technical Innovation

 

From: ajj3085 [mailto:cslanet@lhotka.net]
Sent: Saturday, December 13, 2008 2:07 PM
To: Sergey Barskiy
Subject: [CSLA .NET] Design advice: email collection

 

Hi,

I have a use case where the user will be entering multiple email addresses.  I'm trying to figure out the best way to handle this.  Here's what I've come up with.

1.  A string.  The string will contain addresses separated by ; which is what the System.Net.StmpMail class expects.
2.  A simple string[] or List<string>.  Doesn't require any more classes, but keeps the addresses separate.  however, I'll need to join to a single string anyway.
3.  EmailAddresses BLB, containing EmailAddress.   This would allow business rules and such... although I don't have any validation requirements as of now.  The problem is that the UI is geared toward option one; just a text box to enter.

What do you guys think?

Thanks
Andy


ajj3085 replied on Monday, December 15, 2008

Ya, I'd like to go that route.  Option #3 though means I need to have something that maps the single text input box to multiple child objects.  I'll also need a way to highlight addresses in error within that text box (this is for a Web UI). 

Anyone done something like this before?  Any advice for going between the UI and the business layer?

sergeyb replied on Monday, December 15, 2008

Hmmm.  I would lean toward a grid in the UI to type each individual address.  This way it would be pretty clean.  I would even stored them in a child table instead of a single field.  If this is not an option, then I would go a different route.  You can still have a single box/property with a validation rule.  The rule would parse the text on “:” then run reg ex rule on each string in the array.

 

Sergey Barskiy

Principal Consultant

office: 678.405.0687 | mobile: 404.388.1899

cid:_2_0648EA840648E85C001BBCB886257279
Microsoft Worldwide Partner of the Year | Custom Development Solutions, Technical Innovation

 

From: ajj3085 [mailto:cslanet@lhotka.net]
Sent: Monday, December 15, 2008 8:37 AM
To: Sergey Barskiy
Subject: Re: [CSLA .NET] RE: Design advice: email collection

 

Ya, I'd like to go that route.  Option #3 though means I need to have something that maps the single text input box to multiple child objects.  I'll also need a way to highlight addresses in error within that text box (this is for a Web UI). 

Anyone done something like this before?  Any advice for going between the UI and the business layer?


ajj3085 replied on Monday, December 15, 2008

I would prefer a grid as well, but my client is pretty particular about the UI, and they are the one's that design it.  I didn't think of the rule breaking up the string.. maybe I will go that route. 

Thanks for the feedback!

SonOfPirate replied on Wednesday, December 17, 2008

I have done this and gone a few different ways based on the customer's preference:

1. If you are also identifying the type of e-mail address, e.g. work, home, etc., then the MS-Outlook approach could suffice.  In this case, you'd have a drop-down list/button that identifies the type and a single textbox that displays the address corresponding to the selected type.  This option limits you to a finite number of e-mail addresses, though, based on the number of types.

2. If you are interested in what I would consider more straight-forward code (than #3), you could have a list/grid bound to your list of e-mail addresses and indicated above.  Then, it would be up to you if you want to support inline editing or have buttons that display a dialog to create and modify the items.

3. Another path I have taken in the past, also borrowed from Outlook, is a open text field that accepts a semicolon- or comma-delimited list of e-mail addresses.  When the form is posted back, you'd Split the string on the delimiter and have your string[] of e-mail addresses.

In any case, I would recommend using BO's so that you can validate the addresses - at least the format using RegEx.  You can, if the business case exists, find examples online that demonstrate how to actually verify that an e-mail address is legitimate but that is quite a bit of work and I'd only recommend it if you really needed to know.

Hope that helps.

 

ajj3085 replied on Wednesday, December 17, 2008

Hi Pirate,

I think the UI they want is most like your #3.  In my case though I'll end up storing the value(s) until later, when an email is actually sent.  This use case is a setup for an automated email that is sent by another part of the system.

Thanks, your feedback does help.

Andy

Copyright (c) Marimer LLC