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.
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.....
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)
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.