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 throughYou 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 profileHi 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 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]----------------------------------------------------------
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]
