Author |
Topic |
kentk
Starting Member
USA
30 Posts |
Posted - 22 May 2006 : 16:25:09
|
One other thing I could think of to define the scope of this project and how big the core project will be:
Current Add-On mods people would like to see installed by default:
The wish list
Private Messaging - most of the forums out their today that I have looked at have PM by default
Please post to the topic and I will add on to this list. |
Kent
"Wakey, wakey, hands off snakey!" |
|
|
Ghostnetworks
New Member
95 Posts |
Posted - 22 May 2006 : 19:30:27
|
I feel like Santa, two days before the day after Christmas Before we even consider the wishlist, I think we should get basic forum functions up and running.
The easiest way ( I think ) to handle user functions is to use handlers.
I already use AJAX on most of my CP work that use some form of handler to add/remove/modify entries. It saves a lot of resources by only tapping into the authentication class and not System.Web.UI.Page. The same can be applied for forum work. Think how easy it would be if we could arrange categories and forums by dragging them. Or moving users into groups by dragging them into group columns. Provisions made for text-only/mobile browsers, of course, but even on a regular PC the scripts can be kept surprisingly small and clean.
Keeping things modular like this will help with updates later on. If there's an authentication or validation bug in one form or another, the affected file can be quickly replaced without touching the rest of the application. ( Goes very easy any mods/add-ons a user will have. )
A side note : The data wrapper and data access classes can be combined into one DAL. I'm working on that right now, so we'll have something to work with when we get around to DB interaction. This is what I have so far.
It compiles without errors in command-line, and should be fine with an IDE too. Please post any errors/omissions/suggestions here or email it to me or Cassius so we can correct it.
As for MySQL, we can safely keep forward of the last two versions (5.0, 4.1) Very few hosts keep earlier versions anyway. |
|
|
|
GwynneR
Starting Member
7 Posts |
Posted - 23 May 2006 : 04:59:33
|
If you'll excuse the intrusion, I'd suggest that using the provider model for db access might be the best route to take. That way you wouldn't have to worry about which db's you were going to support at this stage and can just concentrate on what functionality you'd need in the abstract base classes for each provider. Using providers makes implementing new/alternative datastores trivial, you could even mix and match datastores if you so desired. You'll also be opening up a whole new avenue for integrating Snitz with other systems, since the code is no longer concerned with what the datastore looks like, just what the providers feed it, so you could bolt it onto the likes of DNN, Rainbow, PHPNuke etc with very little work. |
Edited by - GwynneR on 23 May 2006 05:19:13 |
|
|
Ghostnetworks
New Member
95 Posts |
Posted - 23 May 2006 : 15:25:46
|
Hi, GwynneR
Yes, that's what our next step will be. But we can't use strict 2.0 models at least for a while, since we're aiming to provide 1.1 backwards compatibility. Right now we're trying to emulate the same functionality in 1.1
That's why the Data Access seems a bit crude at this point. Hopefully we can have selector mode that can switch base classes to a Client Provider Model depending on what version of .Net the user has running.
edit_ I really like the DNN / PHPNuke integration idea, but right now we're having growing pains with just the Snitz implementaion .
And I for one would reeeeally like this to be far more efficient and simple than Community Server Forums or the like. And I don't think I'm the only one that feels that way. Sheesh, what a monster that is! |
|
Edited by - Ghostnetworks on 23 May 2006 15:31:42 |
|
|
kentk
Starting Member
USA
30 Posts |
Posted - 23 May 2006 : 16:26:38
|
Off-topic,
Huw, I'm now a believer took my own advice ran tests against our companies Great Pains DB and the results were basically even between inline and stored procs as far as performance...which leads me to more questions how did I get such great results? The apps I was programming at the time were on SQL 7.0, is there such a difference in how SQL 7 and SQL 2000 handles inline code vs stored procs? The only other difference I could think of is the versions of ADO I was using. The hardware never changed that is why I don't think it was a network or server issue.
Removing foot from mouth now.
Please forgive me Oh SQL God Huw :-) |
Kent
"Wakey, wakey, hands off snakey!" |
|
|
GwynneR
Starting Member
7 Posts |
Posted - 23 May 2006 : 16:41:53
|
quote: Originally posted by GhostnetworksBut we can't use strict 2.0 models at least for a while,
The Provider model isn't solely a Framework 2 feature, it's just a model and works fine under Framework 1.1. The difference with Framework 2 is that it comes with the base support classes already written. I have partially written but functional Membership and Role providers that use the Snitz db as the datastore for use under the Membership/Role/Profile classes that Ms released as a retro-fit for Framework 1.1 and the default system under Framework 2.
You can find information on using the provider model in 1.1 here and here and more background information on the provider model itself here.
quote: since we're aiming to provide 1.1 backwards compatibility. Right now we're trying to emulate the same functionality in 1.1
Yep, I have to ask at this point, if you don't mind, what the rationale is behind that? Seems to me you're building in obsolescence before you've written any code. Not to mention that 1.1 mangles HTML to such an extent it could almost be classed as an HTML obfuscater. Again, an advantage of framework 2 is the CSS Adapter toolkit that gives you better control over how elements actually render as HTML e.g. you can stop it rendering tables wrapped in span tags.
quote: I really like the DNN / PHPNuke integration idea, but right now we're having growing pains with just the Snitz implementaion
That's the joy of providers, you don't have to worry about it, if someone comes along and wants to integrate Snitz to DNN, all they need to do is implement the relevent provider so that Snitz will run from DNN's membership tables or vice versa. All you have to do at the Snitz end is write the abstract base classes that need to be implemented.
|
Edited by - GwynneR on 23 May 2006 17:22:18 |
|
|
Ghostnetworks
New Member
95 Posts |
Posted - 23 May 2006 : 18:05:30
|
Oh no, we'll most likely leave built in web controls out of this. Most likely, we'll be using HtmlGenericControl for most of the Presentation stuff. Custom Repeaters/Databound controls from scratch.
I've seen the 2.0 HTML implementation, but even this seems a bit messy to me when page arrangements get complex. We're also trying to keep this simple, remember ? The control adapter looks awsome, but that would effectively kill 1.1 compatibility.
As for provider model examples... The code that I've been putting together is really a fruit salad of code written in the "Who Cares, I'll Write My Own" principle from your first link .
Don't worry, we are not going to keep those as-is. They are only there to get a base system up and running. Like I said, the Data Layer can be replaced any time. So the obsolescence is only temporary, and only for the development team, at least until we get the core functionality working (Forums/Profiles etc..). For now, someone can port a Snitz db to MySQL, MS SQL and Access (the most common ones) and we can still get data without hiccups. When the Provider Model works, we can go on the rest.
I like the direction you're going. Care to write us up a provider class? The CONFIG class can be extended to include provider selectors or you can write a Friend Class to do the same. |
|
Edited by - Ghostnetworks on 23 May 2006 18:11:38 |
|
|
Ghostnetworks
New Member
95 Posts |
Posted - 24 May 2006 : 06:27:11
|
I've played around with the basic DAL for a while..
Right now I'm about to write down our own Provider/Membership classes (considering some very convincing info from GwynneR)
I won't be writing in all the Methods as with the 2.0 default. Before implementing Membership in 1.1, I just want to get the basic requirements list
'## Overload of System.Web.Security for Membership Provider
'## Methods for commonly used Provider functions
Namespace System.Web.Security
Public MustInherit Class MembershipProvider
Inherits ProviderBase '## Base Provider abstract
'## Login Method
Public MustOverride Function Validate(ByVal UserName As String, ByVal Password As String) As Boolean
'## Register new user
Public MustOverride Sub CreateUser(ByVal Username As String, ByVal Password As String, ByVal Email As String)
'## Delete user
Public MustOverride Sub DeleteUser(ByVal Username As String, ByVal DeleteAllRelatedData As Boolean) As Boolean
'## Restore login/posting privileges
Public MustOverride Function UnlockUser(ByVal Username As String) As Boolean
'## Update user/profile info
Public MustOverride Sub UpdateUser(ByVal user As MembershipUser)
'## Reset a user password
Public MustOverride Function ChangePassword(ByVal Username As String, ByVal OldPassword As String, ByVal NewPassword As String) As Boolean
'## Change the password question
Public MustOverride Function ChangePasswordQuestionAndAnswer(ByVal Username As String, ByVal Password As String, ByVal NewPasswordQuestion As String, ByVal NewPasswordAnswer As String) As Boolean
'## Maximum invalid password entries
Public MustOverride ReadOnly Property MaxInvalidPasswordAttempts() As Integer
'## Only one email per user
Public MustOverride ReadOnly Property RequiresUniqueEmail() As Boolean
'## Login attempt limit including passwords and user provided reminders
Public MustOverride ReadOnly Property PasswordAttemptWindow() As Integer
'## Get user by key/ID and online activity value
Public MustOverride Function GetUser(ByVal providerUserKey As Object, ByVal userIsOnline As Boolean) As MembershipUser
'## Get user by name and online activity value
Public MustOverride Function GetUser(ByVal username As String, ByVal userIsOnline As Boolean) As MembershipUser
'## Total users online
Public MustOverride Function GetNumberOfUsersOnline() As Integer
'## Find a specific user by email address
Public MustOverride Function GetUserNameByEmail(ByVal Email As String) As String
'## All Users
Public MustOverride Function GetAllUsers(ByVal PageIndex As Integer, ByVal PageSize As Integer, ByRef TotalRecords As Integer) As MembershipUserCollection
Protected Overridable Function EncryptPassword(ByVal password As Byte()) As Byte()
'## Encryption Function
End Function
End Class
End Namespace
Anything else we need to add to this?
|
|
|
|
HuwR
Forum Admin
United Kingdom
20584 Posts |
Posted - 24 May 2006 : 06:42:55
|
you don't appear to have a LockUser, but you have an UnlockUser |
|
|
Ghostnetworks
New Member
95 Posts |
Posted - 24 May 2006 : 07:29:56
|
I was going to say the same thing!
And also...
'## Minimum allowed password length
Public MustOverride ReadOnly Property MinRequiredPasswordLength() As Integer
Ironically, there's no specific made "Lock" mechanism in Membership. We have to write that one from scratch even for 2.0. Apparently, the Unlock is there for when users exceeds the login/entry attempt count. |
|
|
|
Ghostnetworks
New Member
95 Posts |
Posted - 24 May 2006 : 10:17:32
|
..So I just sat down to write the 1.1 Membership Provider and I ran into the one thing I was affraid of. There's no direct method of emulating the MembershipUser class
Which means we'll : a) Be writing this from scratch, which means we'll have to be reeeeally careful not to break 2.0 methods b) Rewrite the GetUser methods in the Membership class
'## Get user by key/ID and update online activity value
Public Shared Function GetUser(ByVal ProviderUserKey As Object, ByVal UserIsOnline As Boolean) As MembershipUser
Dim Provider As MembershipProvider = MembershipProvider.Instance
Return Provider.GetUser(ProviderUserKey, UserIsOnline)
End Function
'## Get user by name and update online activity value
Public Shared Function GetUser(ByVal Username As String, ByVal UserIsOnline As Boolean) As MembershipUser
Dim Provider As MembershipProvider = MembershipProvider.Instance
Return Provider.GetUser(Username, UserIsOnline)
End Function
Frankly, I'd prefer the first option, since we can always edit and extend the 2.0 classes. But again, this would mean tiptoing around to avoid conflicts.
Any takers?
------------- Something tells me, I should have stuck to that little DB selector class I had in the beginning
edit_ Add to that : a MembershipCollection class. Actually that one will be easier to implement if MembershipUser is a derived NamedCollection.
..Now I need a coffee break!
edit, edit_ Make that a NameValueCollection |
|
Edited by - Ghostnetworks on 24 May 2006 11:06:15 |
|
|
kentk
Starting Member
USA
30 Posts |
Posted - 24 May 2006 : 13:32:52
|
No offense GhostNetworks but I was kinda hoping we could lay out the project a little more first. So we could be a little more specific as to what going where and why. Being a novice at web programing I can follow what your trying to do, but it seems like a little more planning could go along way on getting this thing ready to go. I would also like to help code but don't what to step on anybody elses feet if they are working on something specific. I have no problem going by your lead, its obvious you know what your doing. Just a suggestion. |
Kent
"Wakey, wakey, hands off snakey!" |
|
|
GwynneR
Starting Member
7 Posts |
Posted - 24 May 2006 : 14:18:42
|
Hi Ghostwriter, will sit down and write a more full reply a little later,but I think you may be looking at this from slightly the wrong angle. It's not necessary to write a set of providers that match those shipped with Framework 2 and the ones for 1.1. The provider model is more generic than that, Snitz will probably need it's own set of provider classes and what needs to be done at this point is to identify what providers it requires and what stub functions are needed for each one. IE it's entirely possible that there's no need for a 'membershipUser' class, but that can only be ascertained by evaluating what is needed.
|
|
|
Ghostnetworks
New Member
95 Posts |
Posted - 24 May 2006 : 14:45:09
|
That's the best news I've heard all week. You're right, I might be rushing to write code when we haven't planned this out yet.
Go ahead and discuss amongst yourselves, and I'll take a sip of my mocha and take it easy for a bit. Let me know what I can do next |
|
|
|
GwynneR
Starting Member
7 Posts |
Posted - 24 May 2006 : 15:10:47
|
Oops, Ghostnetworks, appologies, don't know where I got ghostwriter from, not paying enough attention :) |
|
|
Topic |
|