Hi
Jeff,
If I
understand this right, you have one base application but multiple versions. Each
version can be customized in terms of either selecting from a set of possible
fields and/or creating custom fields. The fields for a given application will
only change if an admin changes them - they won't be a function of the user
within thatr app or the page request, but the fields will probably be different
between different versions of the application.
What
you are describing is a very simple software product line (or software
factory if you're a Microsoftie). One where the primary variability are the
attributes of the user object.
First
thing you have to do is to think about how display issues will be handled.
You're either going to need custom "profile view", "profile list" (if you list
the custom attributes) and/or "profile form" views. You can avoid custom views
by looping through a field name list, but then there needs to be a consistency
to the layouts and you need to be able to render a range of different form
controls.
Next
thing, how important is the additional data? Might you ever want to search or
filter or order by it (or report on it)? If so, you're going to have to write a
little code to generate additional table fields on the fly (Steve Bryant has a
component that should do this out of the box although I haven't had a chance to
play with it). Of course, this assumes a seperate data table for users in each
version of the application unless you're just selecting from a modest set of
possible fields and can live with a bunch of blank fields in your database. You
could also join a base users table to an extended user properties table - one
extended properties table per application version.
If
you're serious about this, you want to consider creating a simple generator that
customizes your DAO's, gateways, and the rendering of your form controls on a
version by version basis. You'd then use an abstract factory to all the
appropriate components for a given application version (or use ColdSpring with a
different XML file per version and a variablized XML path in the ColdSpring
creator. If you wanted to run off a single code base you could also load all of
the various DAO's, Gateways and renderers - either on application load or when
required, and you could use some kind of version ID based upon the URL to drive
the components returned dynamically by putting just a little more intelligence
into your abstract factory (I don't know if ColdSpring would do this or whether
it'd be better just to roll your own).
Hope
that gives you a starting point for thinking about this? This is almost exactly
what I'll be blogging about in my "building the framework" when I get away fro
the craziness that is CF United. Probably too late for this project, but keep an
eye out and let me know if you have any questions.
Best
Wishes,
Peter
Peter
---------------------------------------------------------------Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Chastain
Sent: Thursday, June 29, 2006 3:54 PM
To: [email protected]
Subject: [CFCDev] Modeling a user and its profileI am working on a portal type application where a "user" will really only be made up of a username and a password. That user will then have a profile which would contain other standard details like the user's name, address, email, etc. The question I am faced with is that for different instances of this application, the application admin needs to be able to customize the contents of the user profile. For example, via a web interface, admin A can set his user profile to contain the user's first name, middle initial, last name, and email address. Admin B however would be able to set his user profile to also contain the user's home address, work address, and phone number.So, I can see a user profile type object here, but how do you dynamically assign properties to that user profile without having any idea what those properties might be at design time? Anybody modeled or seen anything like this before?Thanks-- Jeff----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).
An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).
An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
