If you need an end user to adminster the fields within a profile, and
the system needs to support multiple profiles, then I don't think
you'd approach the problem with sub-classed CFCs (unless you end-users
are also CF developers).
I would have a Profile class which really models *any* profile, and
then API would have a couple methods like:
getAttributes() - returns an array of the available attributes
getAttribute('attributeName') - returns the actual value of the
attribute within the profile
setAttribute('attributeName',attributeValue) - sets an attribute
within the profile.
a single instance of Profile is a property of a User, and when a User
is fetched the available attributes for the given type of profile are
determined and set. The whole architecture is relatively simple - but
easy to overthink. As others have mentioned your view code can simply
loop over the attributes within the profile. Your requirements may
dictate things like validation, lookups, etc - but they usually can be
implemented behind that simple API.
HTH
Dave Ross
On 6/30/06, Matt Williams <[EMAIL PROTECTED]> wrote:
Hal Helms has a BaseComponent.cfc that has a generic getter and setter. I
can't seem to get to his site at the moment though (halhelms.com), but it
should be there somewhere.
On 6/29/06, Peter Bell <[EMAIL PROTECTED]> wrote:
>
>
>
> Hi Jeff,
>
>
> I wrote:
> > 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.
>
>
> A simpler/quicker approach would just be to write a generic getProperty
for your user bean that would be called like:
> myUser.getProperty("FirstName");
> That would be pretty easy to loop through
>
> You can write dynamic code to generate the form fields as long as you have
sufficient metadata for each field (data type, length, field type, any field
specific properties, default value, whether it is required, and any other
transformations, validations and/or calculations should be a good starting
point). Depending upon load and complexity you may still find a generated
solution outperforms a dynamic one, but if you're more comfortable with
writing dynamic code than generators it may be easier to at least prototype
the app - you can always refactor out the dynamic pieces to be replaced by
generated cfc's later.
>
> Best Wishes,
> Peter
>
>
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] On
Behalf Of Peter Bell
> Sent: Thursday, June 29, 2006 9:10 PM
> To: [email protected]
>
> Subject: RE: [CFCDev] Modeling a user and its profile
>
>
>
>
> 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
>
>
>
> -----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 profile
>
>
> I 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]
>
>
----------------------------------------------------------
> 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]
--
Matt Williams
"It's the question that drives us."
----------------------------------------------------------
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]
