Forum OpenACS Improvement Proposals (TIPs): TIP #133: Change "bio" from being generic storage in "person" to type-specific storage in "user".
Why change this? Generic storage, with the potential of many values for an attribute for each object, is a bit difficult to handle when auto-generating forms and the like, such as is done with the dynamic types package.
xotcl-core, for instance, specifically excludes bio and bio_mime_type from attributes it will deal with.
I'm proposing moving it from "person" to "user" because the code only supports bios for actual users, and it makes sense to me that it should be this way.
This also simplifies the code dealing with bios a bit, though in order to ease upgrade problems I'm not changing the structure of the Tcl API (you have to be able to log in to upgrade...).
I've already implemented this for PG complete with an upgrade script which copies over the existing biographies, deletes the old copy, drops the attribute, etc. I'll do it for Oracle after approval (most of the queries aren't RDBMS-specific anyway).
Also I propose dropping the "bio_mime_type" column as it is unused.
How would the mime type of "bio" be handled then?
Note: Regarding dynamic types, that reminds me association between attributes for a more complex semantic but that goes beyond what we want to get initially.
Goshawk:~ acs$ cd openacs-4-complete/packages
gGoshawk:packages acs$ grep -r -l bio_mime_type .
xotcl-core is Gustaf's kludge to ignore the attributes "bio" and "bio_mime_type" because his code doesn't handle attributes defined to use generic rather than type-specific storage.
acs-subsite/sql/postgresql/attribute.sql creates the bio_mime_type attribute.
Note: it isn't created for oracle so if it is really used somewhere in .LRN, it is somewhere that only supports PG, and is not in cvs.openacs.org:/cvsroot (unless it is in contrib, which I didn't check).
Are you guys using it locally?
bio should really use the rich text stuff regardless, I thought about making that change but it's more than I'm prepared to do right now.
It was rather a kludge at the first place to define bio this way. Don's suggestion to move it from persons to users and to turn it into a regular attribute makes perfectly sense.
Emma, the mime-type for the bio could be stored in the bio field together with the content (as two element list) by using the rich-text widget for editing. This is also a kind of a kludge, but used all over OpenACS.
So, yeah, dropping bio_mime_type won't hurt.
I grep'd to find all the uses of bio_mime_type, which is the right thing to do before removing it, no?
When I saw the xotcl-core reference, well, of course I wanted to look to see what you were doing with it.
And I stated above that you're kludging around the use of it.
Since that is all xotcl-core is doing with it, it is safe to get rid of it, i.e. I won't break xotcl-core by doing so.
Surely you don't prefer that I just remove stuff without first checking to make sure I won't break stuff like xotcl-core???
Yes, sounds like (more than) a bit of kludge to me. Having a proper datatype created in the DB for it would be much better.
Yes, exactly. The behavior is totally bizarre and probably confusing to users.
I think we all agree that rich text is the right way to go, but I don't have time to do it right now.
If I leave it in person, less code needs changing, in fact the Tcl API needn't change a bit.
I'll leave it there for now and if some day people want to have a global argument about the person vs. user abstraction I'll sit and watch :)
Don and I chatted about this offline and yes, there are multiple instances of developers adding columns in the wrong place (it appears 'users' has become the dumping ground for *anything* related to parties, even for data that relates to columns stored at other levels in the type hierarchy like, say, email). Don clarified one misconception I had about the person type per Lars' (author) intent, which was apparently for it to be a place to hold minimal amount of data on parties that are not yet full-blown users. With portrait and bio hanging off that type, it seemed to me that it was more like the place to hang non-account related attributes. I kind of liked that way of looking at it but, well, as Don pointed out, the whole situation is a little messy and has been muddied by developers over the years.
Anybody have strong (uh... or any) feelings on the matter?
Oh yeah, approved :)