Yes, this feature is not finished yet. I plan to finish this implementation for the next release.

I will be implementing something quite different than the typical ASP.NET profile provider because it seems very limiting to me.

Joe

Ok, so they do have readOnly and allowAnonymous but there are still too many things is doesn't have to use it as a starting point.

I am defining allowAnonymous, but that if implemented would really be for tracking properties of an unauthenticated user. What I was thinking about while writing my comments was visableToAnonymous which is about allowing anonymous visitors to view other member's profiles. Currently mojoPortal only allows authenticated users to view the memberlist or user profiles but I'm planning for more flexibility there. Also the readOnly property is insufficient, we might want to allow an admin to edit a property but not the user. The biggest benefit to my planned profile system will be that you can specify which properties are required for registration and these properties will automatically show up on the registration page and there is nothing like this in the regular ProfileProvider API.

What about just using the order in which they are placed in the config file? That seems the most natural thing to do and the easiest to implement? I'm building a collection of ProfilePropretyDefinition objects by reading the config file and they will already be in that order.

It might be ok to use a separate Resource file for this but I'm want to avoid an explosion of Resource files. I think it is easier to manage translation contributions when it is in one file. I think for things implemented as external modules, separate files are the way to go but core features its best for me if they are all in one file per language. Profile is kind of a special case though since the idea is for it to be customizable and while there will be a core set of profile properties included by default, the power of the feature is that any arbitrary properties can be defined. So I guess in this case a separate file is a good idea.

For help I was thinking of using my existing help feature and automatically generating a key like "profile_" + propertykey + "_help"
Help files don't come from the resource but are localizable. I don't really like the explosion of files there either but I haven't found a better way to do it since the help needs to be editable. If we could implement a web based resource editor that would be good. Not sure how feasible it would be though and it seems likely that there would be a problem making it work under Medium trust.

I am defining a regexValidationExpression attribute and a validationErrorResourceKey so a warning for something that doesn't match the regex pattern can be added to the Resource file.

Well for the Profile system you will get your wish, I will use a separate Resource file like ProfileResource.resx
For help files I'm going to have to stick with the current model for now. Its not a perfect solution but it works.

Joe

That almost sounds like we are storing the Properties in the resource file which we are not. The profile properties are being stored in the db and only Profile System resources are being stored in the .resx file so doesn't it make more sense with syntax like
Resources.ProfileResources.BirthdayLabel
Resources.ProfileResources.BirthdayValidationFailedMessage

Joe