For the longest time, I have needed to create web-based interface to
allow mailing list administrators to control their mailing lists.
Currently, they must email me all of their changes. I'm tired of that.
I now want to create an admin site using CFCs, but not go all the way
with a framework yet.
Our mailing list software is ListCaster. It's long-unsupported, but it
still runs with nary a problem. ListCaster stores its information in a
SQL Server database.
The basic DB structure is:
Table: Users
------------
User_id autonumber (PK)
Email_addr varchar
Table: ListName
---------------
List_id autonumber (PK)
Name varchar
Admin_email varchar
Moderator_email varchar
(other misc columns...)
Table: Subscrib (Yes, I knows it's missing an 'e'.)
---------------
List_id int (PK)
User_id int (PK)
(other misc columns...)
Users is joined to Subscrib which is joined to ListName.
I'm trying to think in terms of objects. Right now, I see two objects:
1. List
2. User
This is how I have my CFCs laid out.
List.cfc
--------
Void init(list_id) -- Loads all info about list including
subscribers, etc.
Query getSubscribers() -- Returns User_ID and email
Void addSubscriber(email|id)
Void removeSubscriber(email|id)
Date getDateLastUsed()
Bool isModerated()
Void transferAdmin(email)
Bool isListSubscriber(email)
Bool isListAdmin(email)
Bool isListModerator(email)
Void sendMessage()
? getAdmin()
? getModerator()
User.cfc
--------
Void init(email)
Bool existsUser() -- Tests if the email exists in the Users table.
Numeric getUserID()
Query getSubscribedLists()
Query getAdministeredLists()
Query getModeratedLists()
Bool isListSubscriber()
Bool isListAdmin()
Bool isListModerator()
Void unsubscribe(list_id) -- users can only unscribe. Only admins
can add users.
If you note in the List.cfc, I do not have a return type for the
getAdmin() and getModerator() methods. I am unsure of what to return.
Do I return the ID number or the email address?
Also, it looks like I have a bit of overlap in my CFCs. My thinking is
that it depends on the context of what information I may have at the
time.
In the User.cfc, I have three "is" methods. This may just be a matter
of symantecs, but I want to know if the user is a member of any list.
However, I may want to know if the user is a member of a particular
list. This is where an overloaded method would be great. I could use
either isListAdmin() or isListAdmin("[EMAIL PROTECTED]"). I supposed
I could still do that with an optional argument, right?
Overall, does anyone see anything terribly bad with this? Am I
duplicating the methods unnecessarily? Should I have a Subscriber.cfc?
The more I think about it, "user IS A subscriber" and "list HAS A
subscriber". Is that right?
I'm running around in circles.
Thanks!
Mike
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev'
in the message of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported
by Mindtool, Corporation (www.mindtool.com).
An archive of the CFCDev list is available at
[EMAIL PROTECTED]
