New datatypes: select and combo boxes that get options from seperate table

Tuesday 27 July 2004 11:53:26 am

My goal is to produce two new datatypes which will provide a user with a combo box (i.e. a select list as well as a text field for new entries, and yes, I know this will be using javascript), as well as a list box, that store possible options in a seperate table. We want to do this to facilitate easy manipulation of the option values, and possibly even integrate the option table with an external database (though that certainly doesn't have to happen now... but we could go that way pretty easily, if we do it this way).

My thinking is that I can use very similar code for both datatypes. I will be storing the final string value in the normal content object way, so we're looking at building both of these datatypes off of the string datatype. In both datatypes, we're really only talking about tweaks to the content edit templates, and the validation/storage functions.

Anyway, I'm posting this message to see if a) anyone's already done something similar and/or b) this sounds like I'm barking up the right tree and/or c) this sounds like I'm barking mad! :-)

Thanks for any help you can provide.

Wednesday 28 July 2004 7:18:26 am

You're correct, they are too similar, and I'll only be coding one datatype. It *is* very similar to the selection datatype, but my goal is to come up with a combo box--a term which is often used to mean select box, but really means a *combination* between a select box and a text field. There's no such thing in HTML's specs, but you can code something very similar by presenting a select box and a text field, and tying together their behavior with javascript (and server-side scripting, as a backup, in case the client browser does not provide javascript capabilities). Here's a good write-up of how the HTML code will work: http://www.cs.tut.fi/~jkorpela/forms/combo.html.

I'm still planning to start with the string datatype, because it will make accessing the data simpler (and will also facilitate importing of legacy data). But I'll be borrowing code from the selection datatype (in particular, the classAttributeContent function).

I really like the idea of using just one datatype for this, because it will give us some freedom with the interface. If suddenly our client declares "No, I don't want the users to be able to enter their own data, they're crazy and are making too many duplicates!" We'll be able to just uncheck a box in the class, and the combo box will revert to a select box.

As long as we're talking about datatypes, we had a need to code up some strings fields with various simple validation rules. Instead of making individual datatypes for this, since the rules were simple enough to code into a single regexp per field, I came up with a datatype that lets you define the regexp validation as part of the class attribute definition in the admin interface. As soon as I'm sure that's working as intended, I'll contribute it to the community.