I have just started out on my first Umbraco project (and, in fact, my first ASP/C#/MVC project). On the whole I am happy with how everything works. I have configured a custom Member Type and have created a form to enable membership creation. But I have noticed a difference in data types.
When I create a member using the BackOffice, any properties that use a DropDown control store the ValueRef from the enumeration of values. If I use the Razor Partial View for a user facing form, it will default to a String value. I have created my own form, and I can pass either the ValueRef ID, or the String value, but which is correct - and what is the impact on querying my Members at a later date (say that I want a query which returns members, with all their custom property values (as strings) joined to a separate "Answers" table)?
Not being familiar with this way of doing things (very familiar with Java/SQL) my inclination is to actually take all my custom properties and map them to a separate (non-umbraco) table (I will have a lot of tables anyway).
Apologies if this is a crazy question, I have looked around a lot, but it seems like most people are mixing Strings and ints (ValueRefs). Would my life be easier if I just changed the backoffice membership type to only have TextBox properties? (Which I guess would at least mean that the stored values would render in the BackOffice, as they do not at the moment)
So, I have ended up with what feels like a bit of a mishmash!
When populating the form for register, I pull values from Umbraco and store them in a Dictionary using using (Where the Dictionary stores the ID and the PreValue String):
Then when registering a new Member I use (which stores the PreValue ID, rather than the String value):
var member = memberService.CreateMember(model.Email, model.Email, model.Firstname + " " + model.Surname, model.MemberTypeAlias);
member.SetValue("ethnicity", model.Ethnicity);
Which makes register play nicely with the BackOffice views.
When a Member is viewing their own account I use:
MembershipUser memberUser = Membership.GetUser();
var typedMember = Umbraco.TypedMember(memberUser.ProviderUserKey);
SetDataValueIfExists(typedMember, "ethnicity", value => rmm.Ethnicity = value);
private void SetDataValueIfExists(IPublishedContent tm, String testValue, Action<String> setValue)
{
if (tm.GetProperty(testValue).HasValue)
{
setValue((String)tm.GetProperty(testValue).DataValue);
}
}
Which gets me the String values for a Member to see. And when a Member is editing their own account to populate the form I use the below which gives me the PreValue IDs:
var memberService = Services.MemberService;
var profileModel = Members.GetCurrentMemberProfileModel();
var member = memberService.GetByEmail(profileModel.Email);
SetValueIfExists(member, "ethnicity", value => rmm.Ethnicity = value);
private void SetValueIfExists(IMember member, String testValue, Action<String> setValue)
{
if (member.HasProperty(testValue) && member.GetValue(testValue) != null)
{
setValue(member.GetValue(testValue).ToString());
}
}
This is all working just fine, have I done anything crazy in there? Is that how I am expected to develop using the various Members[hip] APIs?
Remaining question - is there a tidy way to perform a query that will join the membership table to my custom tables and pull out data values rather than IDs? Or is it the case that I need to pull the raw member data from Umbraco and then perform a manual join with my own tables?
Umbraco Member Custom Properties
Hi Our!
I have just started out on my first Umbraco project (and, in fact, my first ASP/C#/MVC project). On the whole I am happy with how everything works. I have configured a custom Member Type and have created a form to enable membership creation. But I have noticed a difference in data types.
When I create a member using the BackOffice, any properties that use a DropDown control store the ValueRef from the enumeration of values. If I use the Razor Partial View for a user facing form, it will default to a String value. I have created my own form, and I can pass either the ValueRef ID, or the String value, but which is correct - and what is the impact on querying my Members at a later date (say that I want a query which returns members, with all their custom property values (as strings) joined to a separate "Answers" table)?
Not being familiar with this way of doing things (very familiar with Java/SQL) my inclination is to actually take all my custom properties and map them to a separate (non-umbraco) table (I will have a lot of tables anyway).
Apologies if this is a crazy question, I have looked around a lot, but it seems like most people are mixing Strings and ints (ValueRefs). Would my life be easier if I just changed the backoffice membership type to only have TextBox properties? (Which I guess would at least mean that the stored values would render in the BackOffice, as they do not at the moment)
Thanks,
Mark.
So, I have ended up with what feels like a bit of a mishmash!
When populating the form for register, I pull values from Umbraco and store them in a Dictionary using using (Where the Dictionary stores the ID and the PreValue String):
Then when registering a new Member I use (which stores the PreValue ID, rather than the String value):
Which makes register play nicely with the BackOffice views.
When a Member is viewing their own account I use:
Which gets me the String values for a Member to see. And when a Member is editing their own account to populate the form I use the below which gives me the PreValue IDs:
This is all working just fine, have I done anything crazy in there? Is that how I am expected to develop using the various Members[hip] APIs?
Remaining question - is there a tidy way to perform a query that will join the membership table to my custom tables and pull out data values rather than IDs? Or is it the case that I need to pull the raw member data from Umbraco and then perform a manual join with my own tables?
is working on a reply...
This forum is in read-only mode while we transition to the new forum.
You can continue this topic on the new forum by tapping the "Continue discussion" link below.