From: Matthew M. <ma...@tu...> - 2006-03-17 14:54:00
|
I have started laying down the demographics framework. Please take a sec to review the default demographic fields. http://res.stddev.appstate.edu/cvs/fallout/mod/demographics/conf/defaults.php Please suggest any others you believe may be needed by more than one module. This is just the generic list. Modules will be able to add their own fields. For example, Comments is going to add 'signature' and 'avatar'. Both of these fields are specific to Comments and I believe would not be used by other modules. I'll update you when I get it working. -- Matthew McNaney Electronic Student Services Appalachian State University http://phpwebsite.appstate.edu |
From: Verdon V. <ve...@ve...> - 2006-03-17 15:22:04
|
Hi Matt, An excellent start! Couple initial comments... /* ----- Personal information ----- */ Should you include prefix and suffix fields? /* ----- Addresses ----- */ I may be guilty of causing confusion here yesterday... I'm not sure there needs to be separate fields for state/county/province or postal code/zip code (5 total), so much as some non-hacker friendly way to change the label for these fields (2 total). Some input from a non North American user might be good here. Who knows, maybe in some places it's important to have both state and county? Maybe I'm just being to fussy, but it comes from many hours spent digging through code of many scripts, changing all instances of 'State' to 'Province' ;) /* ----- Other out-loud thinking ----- */ Initially I was thinking there should be an image field, or a privacy setting switch, but the more I think about it, these sorts of things fall into the same category as 'signature' and 'avatar' and should be handled by the individual mod as you suggest. For instance, my business/rolodex mod does not want to use the common file cabinet for member images and offers specific privacy settings of demographic info. Cool stuff Matt, verdon On 17-Mar-06, at 9:42 AM, Matthew McNaney wrote: > I have started laying down the demographics framework. Please take a > sec > to review the default demographic fields. > > http://res.stddev.appstate.edu/cvs/fallout/mod/demographics/conf/ > defaults.php > > Please suggest any others you believe may be needed by more than one > module. > > This is just the generic list. Modules will be able to add their own > fields. For example, Comments is going to add 'signature' and 'avatar'. > Both of these fields are specific to Comments and I believe would not > be > used by other modules. > > I'll update you when I get it working. > > -- > Matthew McNaney > Electronic Student Services > Appalachian State University > http://phpwebsite.appstate.edu > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting > language > that extends applications into web and mobile media. Attend the live > webcast > and join the prime developer group breaking into this new coding > territory! > http://sel.as-us.falkag.net/sel? > cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > Phpwebsite-developers mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers > > |
From: Marino P. <php...@lo...> - 2006-03-17 15:40:35
|
Vbulletin has a nice demographics module. They call it "member profile" module. It comes with a few standard fields and then it lets you create your own with options like textarea,popup,radio , required or not etc See their manual http://www.vbulletin.com/docs/html/main/profile Marino > > |
From: Shaun M. <sh...@ae...> - 2006-03-17 16:34:40
|
$fields['msm_id']['limit'] should be $fields['msn_id']['limit'] Jabber would be nice too. $fields['social_security']['limit'] = 9; Should probably be bigger. How about their preferred locale settings? eg their timezone so dates can be given in the user's local time instead of system time? and in their preferred time format also. Shaun aegis design - http://www.aegisdesign.co.uk aegis hosting - http://www.aegishosting.co.uk |
From: Matthew M. <ma...@tu...> - 2006-03-17 18:05:34
|
On Fri, 2006-03-17 at 16:34 +0000, Shaun Murray wrote: > $fields['msm_id']['limit'] > > should be > > $fields['msn_id']['limit'] Done. > Jabber would be nice too. Done. > $fields['social_security']['limit'] = 9; > > Should probably be bigger. Increased to 12. > How about their preferred locale settings? eg their timezone so dates > can be given in the user's local time instead of system time? and in > their preferred time format also. I currently have that set in the users module. Think it should be moved over? -- Matthew McNaney Electronic Student Services Appalachian State University http://phpwebsite.appstate.edu |
From: Verdon V. <ve...@ve...> - 2006-03-17 18:16:22
|
On 17-Mar-06, at 1:04 PM, Matthew McNaney wrote: >> How about their preferred locale settings? eg their timezone so dates >> can be given in the user's local time instead of system time? and in >> their preferred time format also. > > I currently have that set in the users module. Think it should be moved > over? > Probably good where it is. No need to invoke the demographics mod every time some other mod wants to respect user preferences. It seems/feels to me that one is a user setting/pref and the other is meta data. |
From: Shaun M. <sh...@ae...> - 2006-03-17 20:34:55
|
On 17 Mar 2006, at 18:16, Verdon Vaillancourt wrote: > > Probably good where it is. No need to invoke the demographics mod > every time some other mod wants to respect user preferences. It > seems/feels to me that one is a user setting/pref and the other is > meta data. > From a user's UI point of view though, I hope they can edit all this personal info from one control panel interface, be it data from the users mod (username, password, avatar?) or the demographics data. Spreading it out over a multitude of settings screens in different modules isn't friendly enough. But it's great we're storing this info in a core module though. That's the important step. Shaun aegis design - http://www.aegisdesign.co.uk aegis hosting - http://www.aegishosting.co.uk |
From: Verdon V. <ve...@ve...> - 2006-03-17 23:07:13
|
I like the my_page tab concept in the users mod... it's a good way to extend what's in the users settings area while keeping it seeming like it's all organized in one area of the control panel. It's also easy for any mod to add a screen/tab to the user cp. On 17-Mar-06, at 3:34 PM, Shaun Murray wrote: > > On 17 Mar 2006, at 18:16, Verdon Vaillancourt wrote: >> >> Probably good where it is. No need to invoke the demographics mod >> every time some other mod wants to respect user preferences. It >> seems/feels to me that one is a user setting/pref and the other is >> meta data. >> > > From a user's UI point of view though, I hope they can edit all this > personal info from one control panel interface, be it data from the > users mod (username, password, avatar?) or the demographics data. > Spreading it out over a multitude of settings screens in different > modules isn't friendly enough. > > But it's great we're storing this info in a core module though. That's > the important step. > > Shaun > aegis design - http://www.aegisdesign.co.uk > aegis hosting - http://www.aegishosting.co.uk > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting > language > that extends applications into web and mobile media. Attend the live > webcast > and join the prime developer group breaking into this new coding > territory! > http://sel.as-us.falkag.net/sel? > cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > Phpwebsite-developers mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers > > |
From: Verdon V. <ve...@ve...> - 2006-03-18 04:36:22
|
HI, In fallout CVS, these two files are conflicting on my MacOSX system when I try to run cvs update. /core/EZForm.php /coreEZform.php I get the error cvs update: move away core/EZform.php; it is in the way C core/EZform.php My file-system won't allow File.php and file.php in the same dir. |
From: Verdon V. <ve...@ve...> - 2006-03-18 14:55:15
|
FYI... these must be there for legacy support... I did a search for EZForm and EZform respectively and they are not referenced in any of the files in the current fallout CVS > In fallout CVS, these two files are conflicting on my MacOSX system > when I try to run cvs update. > /core/EZForm.php > /coreEZform.php > > I get the error > cvs update: move away core/EZform.php; it is in the way > C core/EZform.php > > My file-system won't allow File.php and file.php in the same dir. |
From: Verdon V. <ve...@ve...> - 2006-03-18 15:40:58
|
Hi :) I'm just thinking out loud and looking for opinions here. Would welcome any... I've been doing preliminary work re-writing my phpwsbusiness mod as rolodex, for fallout. While I've been doing that and asking questions here, discussion has come up about the demographics mod. I'd definitely like to hook into this, but there are usage scenarios where this would not be good, as one phpws user will be managing/owning many or all rolodex cards. So, what I've been thinking is that it would be good if the site admin using my rolodex mod could decide whether to hook into the demographics mod, or use the rolodex internal tables instead. My first thoughts being that there could be a switch in rolodex settings that would tell the card class' init() function where to look for data for all cards. I then thought, would it be better if an individual card record could somehow be flagged to use demographics data or rolodex data. That would allow the real world scenarios I currently have where one user is owning/managing 700 or so phpwsbusiness records on a site while the other 200 or so records are owned/managed by individual phpws users. Now, I'm only thinking in the broadest terms here and haven't worked out any of the logistics involved. I am curious as to what others might think would be useful. I'm also unsure of (and concerned about) what kind of performance hit / overhead I might introduce. If you remember phpwslistings, it used extended user_vars to store demographic info for agents for listings. I always wondered if that had anything to do with some of it's performance issues. Anywise, any thoughts? Thanks, verdon |
From: Matthew M. <ma...@tu...> - 2006-03-17 18:34:07
|
On Fri, 2006-03-17 at 10:22 -0500, Verdon Vaillancourt wrote: > /* ----- Personal information ----- */ > Should you include prefix and suffix fields? Damn how'd I miss that? Added it. > > /* ----- Addresses ----- */ > I may be guilty of causing confusion here yesterday... > > I'm not sure there needs to be separate fields for > state/county/province or postal code/zip code (5 total), so much as > some non-hacker friendly way to change the label for these fields (2 > total). Some input from a non North American user might be good here. > Who knows, maybe in some places it's important to have both state and > county? Maybe I'm just being to fussy, but it comes from many hours > spent digging through code of many scripts, changing all instances of > 'State' to 'Province' ;) First, I added Province (couldn't remember that one). Whether or not province, county, etc are used will be up to the module developer. Talking with Shaun about it this morning, we figured that having three address fields would allow for any international address. You could then ignore the other fields. Or if you are getting information from locals, then you could use the state, province, county, or whatever. > > /* ----- Other out-loud thinking ----- */ > Initially I was thinking there should be an image field, or a privacy > setting switch, but the more I think about it, these sorts of things > fall into the same category as 'signature' and 'avatar' and should be > handled by the individual mod as you suggest. For instance, my > business/rolodex mod does not want to use the common file cabinet for > member images and offers specific privacy settings of demographic info. Agreed :) I got backed up with some university stuff today but I will have some more work on this soon. -- Matthew McNaney Electronic Student Services Appalachian State University http://phpwebsite.appstate.edu |