thellebuyck
  • Posts: 2
  • Joined: 29/09/2008
Hello,

I am running YAF 1.9.3 with the ASP.NET Membership and Role Provider (SQL Provider) and the default YAF Profile Provider. On a Windows Vista Development machine updating a user's profiles works just fine. When I deploy to a production server (Win2k3 SP2) the same configuration doesn't allow a user to update their profile. Entering and saving profile information doesn't save the profile information when you return to the user's profile. No errors are being reported. I have been chasing this issue for a day or so and don't know where to look. Any suggestions?
Sponsor
mddubs
  • Posts: 476
  • Joined: 07/08/2008
Try using the SqlProfileProvider instead.
UserPostedImage 
www.bunkerhollow.com  | www.careercomputing.com 
When I post fp:mddubs in a topic, I'm leaving my footprint there so I can track it once I get into coding/supporting. (Yes I stole this off Mek 🙂, who stole this off Ederon 🙂 )
juan.p
  • Posts: 13
  • Joined: 24/06/2009

>> Entering and saving profile information doesn't save the profile information when you return to the user's profile.

Working in this area of the code right now, trying to integrate final into my site. I have almost the same scenario as you, but I am using my own customProfileProvider.

Profile information will appear to be saved because it is cached. But when you log out/log in again, the cache gets cleared and any changes are lost.

The problem you have is the YAFProfileProvider makes the assumption that 'if you are using the YAFProfileProvider, then you are using the YAFMemberShipProvider'.

You'll see it here...

In Yaf.Providers.Profile.YafProfileProvider:


public override void SetPropertyValue(.... )
....

//****   this is looking for the user from the YAFMembershipProvider!!!
object userID = DB.GetProviderUserKey( this.ApplicationName, username );

if ( userID != null )
{
    // start saving...
    DB.SetProfileProperties(this.ApplicationName, userID, collection, _settingsColumnsList);
    // erase from the cache
    DeleteFromProfileCacheIfExists( username.ToLower() );
}



As you see above, it is absolutely hard wired to the MembershipProvider of YAF. Since you are not using that Provider,
it will not find a userID (because yours are stored in the SQLmembershipProvider), the userID!=null will fail, and there is no error thrown. It fails silently.

I'm currently testing the following code...



//replaced:
//     object userID = DB.GetProviderUserKey( this.ApplicationName, username );
//with:
System.Web.Security.MembershipUser curUser = System.Web.Security.Membership.GetUser(username);
object userID = curUser.ProviderUserKey;



The above code change is 'membership provider nuetral' and will return the userID from whatever provider you are using... be it YAF or ASP, as long as it implements the MembershipProvider correctly. But I haven't finished testing, so be careful... it is saving in the yaf table, but I'm currently not loading correctly. But that might be something related to my custom profileprovider. I'll keep you posted.


juan.p
  • Posts: 13
  • Joined: 24/06/2009
The above code changes will save but it you won't load the profile again.. just found the following...

In the stored procedure prov_profile_getprofiles it is hard wired to lookup the userID from the prov_Membership based on the username. So that is where it all (starts) to break.


    -- Insert into our temp table
    INSERT INTO #PageIndexForUsers (UserID)
        SELECT  m.UserID
        FROM    [smarter].[yaf_prov_Membership] m, [smarter].[yaf_prov_Profile] p
        WHERE   ApplicationID = @ApplicationID
            AND m.UserID = p.UserID
            AND (@InactiveSinceDate IS NULL OR LastActivity <= @InactiveSinceDate)
            AND (@UserNameToMatch IS NULL OR m.UserNameLwd LIKE LOWER(@UserNameToMatch))
        ORDER BY UserName


    SELECT  m.UserName, m.LastActivity, p.*
    FROM    [smarter].[yaf_prov_Membership] m, [smarter].[yaf_prov_Profile] p, #PageIndexForUsers i
    WHERE   m.UserId = p.UserId AND p.UserId = i.UserId AND i.IndexId >= @PageLowerBound AND i.IndexId <= @PageUpperBound



And if you look at the other stored procedures related to the profile, they are tied to the yah membership table as well.

I'm going to unravel the dependency because I *have to*. I don't want to and can't use the YAFMembership provider and since I have a custom profile provider, I can't use the SqlProfileProvider.


By the way, the SqlProfileProvider does work fine with YAF. That is because it stores the profile properties packed as xml (?) in the table, so it will just add the YAF profile properties into the string and save/retrieves them. It is very independant this way. The YafProfileProvider is never used when you do it this way... so if I'm not mistaken, that basically disables the caching built into the YafProfileProvider. (correct me if i'm wrong)

When you use a custom profile, you have basically two options that I can see.

1) You can make your custom profile handle the yaf profile properties. In which case it has to load/save the properties defined in the YafUserProfile class. This should be easy.. in most cases a custom profile provider has a flat table, so just add the columns to handle the yaf values. Only disadvantage is your application is now tied to any changes that happen to the YafUserProfile.

2) You can try to make the yaf profile provider work in conjunction/independant of your custom profile. This is harder because YAF isn't designed to work like this. But it lets yaf handle its own baggage and be independant of your application. Only disadvantage is you must merge your changes with future releases of YAF and possibly break something. (Unless YAF integrates your changes of course.)

To do #1, make your CustomUserProfile class inheret from the YafUserProfile, and your CustomProfileProvider will then receive *all* the properties of both your CustomUserProfile and the YafUserProfile. You then load/save the properties in your custom profile provider. In web.config, your CustomProfileProvider is the default, inherets='myCustomUserProfile'. YafProfileProvider is not needed/used.

To do #2. This is where it gets interesting. Let the YAFUserProfile handle its own YafUserProfile properties, as it is already .. almost.. designed to do. To do this, your myCustomUserProfile class should still inheret from the YafUserProfile class (in the code). Then you need to add your CustomProfileProvider and the YafProfileProvider to the providers list of web.config (make sure to set the application name in the yaf provider). Set your provider to be the default but with it's inherets='myCustomUserProfile'.

Now, to get the YafProvider to handle its Profile properties, you can add the tag :

[ProfileProvider( "myYAFProfileProvider" )]

where 'myYAFProfileProvider' is the name you gave the YAFProfileProvider in the web.config. Add it to each property in YafUserProfile class. (Not sure if this can be defined in the web.config.. never tried it).

Now asp.net will call the YafProfileProvider with the values from the YafUserProfile, and your CustomProfileProvider with the values from your CustomUserProfile. If the YAFProfileProvider wasn't hard coded to the YAFMembershipProvider, it would work practically out of the box, you'd just need to add the profileprovider tags.


juan.p
  • Posts: 13
  • Joined: 24/06/2009
I've edited this post a few times, since it is hard to find an answer. I'm not sure if this is a YAF design issue, or a Microsoft Provider interface problem.

If you look at the ProfileProvider interface...

public ProfileInfoCollection GetAllInactiveProfiles( ProfileAuthenticationOption authenticationOption, DateTime userInactiveSinceDate, int pageIndex, int pageSize, out int totalRecords )

The ProfileProvider interface needs an activity date, which in YAF is stored in the membershipProvider. I don't think that is a requirement of the membershipProvider, but even the ASP Membership provider stores a lastLoginDate. If this is going to work, I'd need to add an activity date to the YafUserProfile, and base everything off of that.

On that note... I'm not going to try to unroll the dependencies... it is too much work within YAF and I don't have enought time to start breaking things. I'll just make my customProfileProvider handle the YAFUserProfile properties and be done with it. But it is a shame, because I think I'll lose the great caching that they put in the YAFUserProfile.
mddubs
  • Posts: 476
  • Joined: 07/08/2008
Thanks a lot for the research Juan. I decided a long time ago to use the default .NET providers, but I've seen a few people have issues like this with Profile.

If you have any final code changes you think would help just post them and I'll commit them to source.

fp:mddubs
UserPostedImage 
www.bunkerhollow.com  | www.careercomputing.com 
When I post fp:mddubs in a topic, I'm leaving my footprint there so I can track it once I get into coding/supporting. (Yes I stole this off Mek 🙂, who stole this off Ederon 🙂 )
jshepler
  • Posts: 189
  • Joined: 09/08/2008
juan.p wrote:

I'm going to unravel the dependency because I *have to*. I don't want to and can't use the YAFMembership provider and since I have a custom profile provider, I can't use the SqlProfileProvider.



If you're not using the yaf providers, why do you *have to*? You said you can't use the yaf membership provider and you say you have a custom profile provider - so what's the problem?

I've read your posts over and over and I'm confused. You keep saying you have a custom profile provider, but keep talkin about code changes to the yaf profile provider. I understand your complaint about the yaf profile provider being dependent on use the yaf membership provider, but since you're not using either one what's the problem??

not jsheLPer
jshepler
  • Posts: 189
  • Joined: 09/08/2008
juan.p wrote:

By the way, the SqlProfileProvider does work fine with YAF. That is because it stores the profile properties packed as xml (?) in the table, so it will just add the YAF profile properties into the string and save/retrieves them. It is very independant this way. The YafProfileProvider is never used when you do it this way... so if I'm not mistaken, that basically disables the caching built into the YafProfileProvider. (correct me if i'm wrong)



This is how profile providers *should* work. They shouldn't be dependent on a specific set of profile properties. They just take whatever properties are there and persist them somewhere. Yaf's profile provider is not tied to the specific YafUserProfile properties - it handles whatever properties are passed to it. If you look at the code, you'll see that it alters the profile table to add property columns as needed.

not jsheLPer
jshepler
  • Posts: 189
  • Joined: 09/08/2008
juan.p wrote:

I've edited this post a few times, since it is hard to find an answer. I'm not sure if this is a YAF design issue, or a Microsoft Provider interface problem.

If you look at the ProfileProvider interface...

public ProfileInfoCollection GetAllInactiveProfiles( ProfileAuthenticationOption authenticationOption, DateTime userInactiveSinceDate, int pageIndex, int pageSize, out int totalRecords )

The ProfileProvider interface needs an activity date, which in YAF is stored in the membershipProvider. I don't think that is a requirement of the membershipProvider, but even the ASP Membership provider stores a lastLoginDate. If this is going to work, I'd need to add an activity date to the YafUserProfile, and base everything off of that.



The activity date is kind of required in the membership provider. The MembershipProvider.GetUser() method takes a bool to indicate if it should update the last-activity date/time stamp for the user. I suppose if you store that value in the profile, your membership provider could update it but it would need to KNOW that is the case and so is dependent on the profile having that property. So, for all practical purposes, yes, the last-activity date is a requirement of the membership provider.

Basically, the profile provider only needs it when pulling inactive profiles to define what "inactive" means - how long is long enough to equate being inactive. The downside here is how is the profile provider supposed to know where to find the last-activity date and so is hard-coded to use the approprate provider's table (e.g. the SqlProfileProvider will pull the lastActivity date from the aspnet_Users table) and so ties the two together. Yaf does the same thing.

Knowing that, you can write your custom profile provider to use whatever membership/users table your app is using.


juan.p wrote:

On that note... I'm not going to try to unroll the dependencies... it is too much work within YAF and I don't have enought time to start breaking things. I'll just make my customProfileProvider handle the YAFUserProfile properties and be done with it. But it is a shame, because I think I'll lose the great caching that they put in the YAFUserProfile.



Your custom profile provider should be written to handle any properties passed to it. You can implement the caching yourself, too. Yaf just uses the System.Web.HttpContext.Current.Cache to store a dictionary of the profile properties. You can do that or use the session or whatever caching mechanism you want.

not jsheLPer
juan.p
  • Posts: 13
  • Joined: 24/06/2009
Quote:


I've read your posts over and over and I'm confused. You keep saying you have a custom profile provider, but keep talkin about code changes to the yaf profile provider. I understand your complaint about the yaf profile provider being dependent on use the yaf membership provider, but since you're not using either one what's the problem??



And if you read the post multiple times, you'd see that I *was* trying to use the yaf profile provider and use it in conjunction with my custom profile provider. I was hoping I could just 'plug-in' the YAF profile provider and it would handle its own profile information. Like I demonstrated, ASP.NET can be configured to do this. That for me was the most logical and safest choice in the long term since it would be totally independant of my application and allow YAF to use whatever optimizations that are built into it and shield my application from any future YAF changes.

I think you are confused about my intent. I'm trying to be helpful. I brought up this topic, to give information to others trying to follow in my footsteps, give some details of what I tried, plus point out an area/idea that could improve yaf and give the information required to do it. I even got into the code to see if it would be simple to implement, but its not.

There is not a lot of detailed documentation about the limitations/design of the yaf providers, so this should help a few people and maybe YAF in the future. Making Yaf integratable, seems to be a sort-of a design goal of the YAF project. And having the profiles work independant, would be a fantastic feature. I was hoping I could contributed a bit back.

I understand your point that *ideally* a profile provider should be able to dynamically handle whatever properties are added to it. You are basically implying that the responsibility is for my custom profile provider to add the YafUserProfile to it. I can add the YAf properites to my provider in 15 minutes. But I was hoping not to tie my application to YAF if I didn't have to. I have spent a lot more than 15 minutes, because that goal was worth it to me.

I saw that the YAF dynamically handles properties, but if I add a one-to-many relationship like save a List<string> as a profile property, will it handle that? The microsoft provider would, but I don't think the YAF one will. The effort it takes to make a provider that handles everthing, is just not worth the effort.

Microsoft wrote an aggressive feature-rich provider interface. It suites their self-serving interests of marketing "easy out of the box web sites". But even they flopped on the implementation because it is hard to make an efficient design. And they failed to define the contract/responsibility of each interface... so now every project defines its own contract between providers, which ends up breaking a a lot of the interopability that this provider model could offer. Thats my two cents.
juan.p
  • Posts: 13
  • Joined: 24/06/2009
Quote:


Your custom profile provider should be written to handle any properties passed to it. You can implement the caching yourself, too. Yaf just uses the System.Web.HttpContext.Current.Cache to store a dictionary of the profile properties. You can do that or use the session or whatever caching mechanism you want.



Thank you for the feedback. I definitely like how the provider was coded and I'm going to borrow a few ideas to make mine better.

Quote:

Basically, the profile provider only needs it when pulling inactive profiles to define what "inactive" means



On the surface this appears to be the deal breaker in the membership-profile provider interfaces. It implies that the profile needs to get this information from the membership. I'm not sure why they would have defined 'inactive profiles' in the interface.. since it should be an inactive membership that gets its corresponding profile.

But if you think about it, it is left up to the implementers to define the contracts between the two and explicity define the requirements of each. If YAF wanted to break the dependency, they could add an activity date to the profiles and explicitly say that it needs to be manually updated, however/whenever someone wants it to be. And from what I saw, I think there would be need to store the username as well in the profile for lookup purposes.

But I imagine this is not a *huge* priority and perhaps not even a design concideration for the yaf project, so I don't want to be talking much ado about nothing.

I'll leave the topic. I hope other people using YAF find it helpful.
jshepler
  • Posts: 189
  • Joined: 09/08/2008
juan.p wrote:

And if you read the post multiple times, you'd see that I *was* trying to use the yaf profile provider and use it in conjunction with my custom profile provider.



That's what I'm talking about - you keep talking about using both providers and that just doesn't make any sense.


juan.p wrote:

I was hoping I could just 'plug-in' the YAF profile provider and it would handle its own profile information.



Given the context of your posts, I'm not clear on what you mean by 'plug-in' - plug it into what?

Profile providers are "profile information"-agnostic. Yaf's, like asp.net's, handles whatever profile properties are there - it's not hard-coded for yaf profile properties.


juan.p wrote:

I think you are confused about my intent. I'm trying to be helpful. I brought up this topic, to give information to others trying to follow in my footsteps, give some details of what I tried, plus point out an area/idea that could improve yaf and give the information required to do it. I even got into the code to see if it would be simple to implement, but its not.



You're right - I missed your intent. It looks like you were having problems getting something to work and was wanting help. I have some experience in this area, but I don't know how to help you because I'm confused on what you're doing.

Trying to be helpful is good and all, but (to me) you "muddied up the water". I'm trying to figure out if I'm being dense or you're being inaccurate/unclear. If it's not me, then your posts will only serve to confuse people more and so is not being very helpful.



juan.p wrote:

I understand your point that *ideally* a profile provider should be able to dynamically handle whatever properties are added to it. You are basically implying that the responsibility is for my custom profile provider to add the YafUserProfile to it.



Writing a profile provider that is only able to persist a specific set of properties is a "bad thing". Asp.net doesn't do it. Yaf doesn't do it. Mine doesn't do it. It's not that it's the *ideal* way of doing it, it's *the* way of doing it. Anything less is a poor design.



juan.p wrote:

I can add the YAf properites to my provider in 15 minutes. But I was hoping not to tie my application to YAF if I didn't have to. I have spent a lot more than 15 minutes, because that goal was worth it to me.



Profile providers should not be tied to any profile class. You shouldn't need to "add the YAF properties" to your provider. The provider is just the piece that persists data. The provider doesn't care what the data is or where it comes from or how it's used. The provider's only job is to store the data somewhere and retrieve it later.


juan.p wrote:

I saw that the YAF dynamically handles properties, but if I add a one-to-many relationship like save a List<string> as a profile property, will it handle that? The microsoft provider would, but I don't think the YAF one will. The effort it takes to make a provider that handles everthing, is just not worth the effort.



I had to look at the code again to verify that yaf doesn't persist complex data types and you're right! That definately needs to be added.

A year ago, I would have agreed with you that it'd be pretty hard to implement, but it ended up not being all that bad. Here's a snippet of my custom profile provider that generates the value to be stored. The only data type it can't handle is a complex type that is not serializable and doesn't implement a type converter to/from a string:

TypeConverter converter = TypeDescriptor.GetConverter(propertyValue.Property.PropertyType);
if (converter.CanConvertTo(typeof(string)) && converter.CanConvertFrom(typeof(string)))
    value = converter.ConvertToString(propertyValue.PropertyValue);
else
{
    XmlSerializer xs = new XmlSerializer(propertyValue.Property.PropertyType);
    StringWriter sw = new StringWriter();
    xs.Serialize(sw, propertyValue.PropertyValue);
    value = sw.ToString();
}



Maybe we should just start over. What is it, exactly, that you're trying to accomplish?

not jsheLPer
jshepler
  • Posts: 189
  • Joined: 09/08/2008
juan.p wrote:

Quote:

Basically, the profile provider only needs it when pulling inactive profiles to define what "inactive" means



On the surface this appears to be the deal breaker in the membership-profile provider interfaces. It implies that the profile needs to get this information from the membership. I'm not sure why they would have defined 'inactive profiles' in the interface.. since it should be an inactive membership that gets its corresponding profile.


Heh, I agree with you here. I don't know what the intent was of having the profile provider to return a collection of profiles of any kind, not just inactive.


juan.p wrote:

But if you think about it, it is left up to the implementers to define the contracts between the two and explicity define the requirements of each. If YAF wanted to break the dependency, they could add an activity date to the profiles and explicitly say that it needs to be manually updated, however/whenever someone wants it to be. And from what I saw, I think there would be need to store the username as well in the profile for lookup purposes.



I don't think I agree with you here. I thnk having yaf "say" that you need to manually update the last activity date in the profile would hinder integration into existing sites. It's like standards vs. non-standards. You may not agree with the standard and think your way is better, but since it's not standard, everyone else will have to bend over backwards to get their stuff to work with your stuff.

Yeah, user name/id is in the same boat. So is application name/id. The membership/profile provider system is not perfect, but is MUCH better than what we had before. I think it's a valiant effort to provide a common authentication/roles/profile system that can be shared between various components in a site.

not jsheLPer
juan.p
  • Posts: 13
  • Joined: 24/06/2009
I wrote a good response, and of course lost it, so I'll try to re-write it but it may not be as complete... don't be too critical.

But look.. my intention is to leave a trail for people that want to integrate YAF and their options.

If you look at it from the perspective of an end user, you'd appreciate what I left. Someone just reading it might not quite get it.

If you are using YAF you have 3 options

1) Use YAF as is. No problem. It just works. (this is the same as #2)
2) Use the YAF Membership and Profile Provider. Not a good option if you have an existing users, because you'll probably want to use your existing
membership provider.
3) Use your own Membership custom Profile provider.


If you need to make a choice between 2 and 3, the next logical step is "What do I do with the Profile Provider"????

Then you have a few options..

3.1) Add the YAFUserProfile to your own ProfileProvider
3.2) Add your UserProfile to YAF.
3.3) Try to let YAFProfileProvider use its own YAFUserProfile and your ProfileProvider use your UserProfile

The majority of people that do integration work, will select option 3.3 because it is the *safest*. There is no dependancy (in theory) between the two applications and isolates the two from future versions and changes. IF you select 3.1 or 3.2 you need to do a lot of testing to make sure one doesn't break the other. i.e. if you have complex types, you will break option 3.2 or if your ProfileProvider isn't fully implemented, you might break 3.1. That should be pretty straight forward to understand.

Quote:


It's not that it's the *ideal* way of doing it, it's *the* way of doing it. Anything less is a poor design.



My profile provider does not implement all the interfaces defined, plus is optimized in ways that I need it to be. I don't need to implement all the interfaces exactly as they *ideally* should be and I'm not going to write code that I don't need. Nobody is going to integrate my project and so its not a requirement. What you call *poor design* most people would call a trade off between time, budget and features. It looks to me that this version of YAF also made that same trade off. Its not the fault of YAF nor am I critizing the developers.. its a necesesity of real-world projects.





juan.p
  • Posts: 13
  • Joined: 24/06/2009
Quote:


I don't think I agree with you here. I thnk having yaf "say" that you need to manually update the last activity date in the profile would hinder integration into existing sites. It's like standards vs. non-standards. You may not agree with the standard and think your way is better, but since it's not standard, everyone else will have to bend over backwards to get their stuff to work with your stuff.



You shouldn't critize me for not liking *the standard*. I like standards. If you want to sling things, I could say you like to invent standards that don't exist, but that wouldn't be very constructive nor very professional of me, so I won't say it. Show me where is *the standard* you are refering to is and I'll read it. If there were a well defined standard we wouldn't have this discussion, we'd just reference the standard for clarification.

So, apart from YAF... lets finish this discussion and take a hard look at the Profile and Member Providers.....

There is no standard. Microsoft defined an interface, and poorly defined some of its variables at that, leaving a lot of valuable information scattered or implied. Its like an UML object diagram without an interaction diagram.

================================================================================
Even Microsoft developers are confused in how to implement their interface. If you start digging in the MSDN, you'll find they change how they define the properties, when they describe what they do. I had good examples, but I lost my original post and I don't want to dig again....

==========================================================================================
public abstract MembershipUser GetUser (string username, bool userIsOnline);

Note that the boolean is called "userIsOnline", not "profileIsActive" or some other definition. You eluded to this before.. it is however you want to define it, which is definitely not what a *standard* does. It is at best a guideline with just enough rope to hang yourself. Most people implementing this would immediately think this is the obvious manner to deduce when a profile is inactive. But is it??? Not really. It makes a dependency between the implementation of the membership provider and the profile provider.

And then examine that ellusive [ProfileProvider()] tag that can be added to the UserProfile, and that furthers this idea. Using logical deduction, this tag would have no purpose if the MembershipProvider was supposed to be dependant on the UserProfile. You can use multiple ProfileProvider at the same time, but (at least to my knowledge) you can't use multiple MembershipProviders.

Quote:



http://msdn.microsoft.co...us/library/d8b58y5d.aspx 

provider Specifies a provider specific to the property. By default, all properties are managed using the default provider specified for profile properties, but ***individual properties can also use different providers****.



=========================================================

Okay look at this.....

Quote:



http://msdn.microsoft.co...us/library/0580x1f5.aspx 

DeleteInactiveProfiles method

Takes as input a ProfileAuthenticationOption value and a DateTime object and deletes from the data source all profile information and property values where the ***last activity date*** is less than or equal to the specified date and time ..snip...



Note it is called "last activity date". What is that? Could be last activity of the profile, not of the membership.

Now look at this...

How to: Build and Run the Profile Provider Example
http://msdn.microsoft.co...us/library/ta63b872.aspx 


CREATE TABLE Profiles
(
  UniqueID AutoIncrement NOT NULL PRIMARY KEY,
  Username Text (255) NOT NULL,
  ApplicationName Text (255) NOT NULL,
  IsAnonymous YesNo, 
  LastActivityDate DateTime,
  LastUpdatedDate DateTime,
    CONSTRAINT PKProfiles UNIQUE (Username, ApplicationName)
)

CREATE TABLE ProfileData
(
  UniqueID Integer,
  ZipCode Text (10),
    CONSTRAINT FKProfiles2 FOREIGN KEY (UniqueID)
      REFERENCES Profiles
)


Note how they self-contain the ProfileData and ProfileProvider with the LastActivityDate and LastUpdatedDate and then provide a magic function to update the values (and personally I think it should be public):

Private Sub UpdateActivityDates(username As String, isAuthenticated As Boolean, activityOnly As Boolean)


Quote:


I don't think I agree with you here. I thnk having yaf "say" that you need to manually update the last activity date in the profile would hinder integration into existing sites.



Since the 'last activity date' can be whatever you want to define it, allowing YAF's ProfileProvider to be manually updated, makes sense. For example, if the YAF Membership provider updates the Profile Provider's 'lastActivity' automatically, but don't use the YAF Membership Provider, how do you update it?? However you want implement it. Could be a web.config setting "AutoUpdate" to turn it on or off. This approach provides flexibility for integrators that want to use it and or they can then implement their own definition of 'last activity date'. If I want to base it off the membership provider, I could inherit it and just override the MembersShip.GetUser()' to call the YAFProfileProvider with an updateProfileLastActiveDate(). And since this is an interface 'by standards' it is meant to be extended. Another example is the Membership.GetUser(), even they allow the developer to define when the 'userIsOnline' or when they aren't. They don't just assume MembersShip.GetUser() means 'you are online'.


So in the end, I was trying to point out to the YAF development team, that by tying their ProfileProvider to the Membership provider, they have created an unnecessary dependency. And I showed that ASP.NET has functionality that allows *ideally* should allow a ProfileProvider to work independant of the Membership provider. Again, not critizing YAF, just trying to point out something that may be helpful in future versions. If they broke this dependency, they probably would have almost *no* support questions related to YAF and existing sites.
Users browsing this topic
    Forum Jump  
    • You cannot post new topics in this forum.
    • You cannot reply to topics in this forum.
    • You cannot delete your posts in this forum.
    • You cannot edit your posts in this forum.
    • You cannot create polls in this forum.
    • You cannot vote in polls in this forum.

    About Us

    The YAF.NET is an open source .NET forum project. YAF.NET is supported by an team of international developers who are build community by building community software.

    Powered by Resharper Donate with PayPal button

    Project Twitter Updates

    Copyright © YetAnotherForum.NET & Ingo Herbote. All rights reserved