Thanks for the links. I'm still trying to figure out how much to look for the framework to do and how much to look for client-side solutions. This helps.
Ian On Sep 7, 5:48 pm, Anthony <[email protected]> wrote: > Since developers will have different preferences for multiselect widgets and > it is so easy to plug something in on the client side, I'm not sure the > framework needs to commit to a particular widget. Here are a few good > options: > > http://www.erichynds.com/examples/jquery-ui-multiselect-widget/demos/...http://www.quasipartikel.at/multiselect/http://jqueryui.com/demos/autocomplete/#multiple > > > > > > > > On Wednesday, September 7, 2011 5:12:55 PM UTC-4, monotasker wrote: > > > OK. That description confused me in the book (I'm not used to > > describing multi-select boxes as a 'drop-box' so I assumed it meant > > drop-down). Thanks. I think it would be more usable if the default > > widget were something like the one used in the app-creation wizard for > > table and field creation: > > > 1) present a single text field with autocomplete based on the > > referenced table, then > > > 2) when the user fills that field (or on <enter>?) another field > > appears below it. > > > A multi-select field doesn't seem to me very user-friendly if we're > > trying to select multiple options from a long pre-populated set of > > choices. The user has to use CTRL-LMB just to select a second option, > > and has to scroll manually through the list. Do you think this is > > something worth changing? > > > Ian > > > On Sep 7, 4:02 pm, Anthony <[email protected]> wrote: > > > No, you should not get a series of select boxes, just a single > > multi-select > > > box, like > > > this: > >http://www.w3schools.com/tags/tryit.asp?filename=tryhtml_select_multiple. > > > > The book states that a list:reference field "produces a > > SELECT/OPTIONmultiple drop-box". > > > > Anthony > > > > On Wednesday, September 7, 2011 3:43:11 PM UTC-4, monotasker wrote: > > > > > In a form generated by SQLFORM I'm finding that a list:reference field > > > > is represented with a single list-box. What I expected based on the > > > > section on list:<type> in the manual was a series of select boxes. Was > > > > I reading the manual wrong? If not, does anyone know why I might be > > > > getting the wrong widget presented? > > > > > Here is the relevant part of my model: > > > > > db.define_table('tags', > > > > Field('tag', 'string'), format='%(tag)s') > > > > > db.tags.tag.requires = IS_NOT_IN_DB(db, db.tags.tag) > > > > > db.define_table('questions', > > > > Field('question', 'text', required=True), > > > > Field('answer', 'string', required=True), > > > > Field('score', default=1, required=True), > > > > Field('answer2', 'string', default='null'), > > > > Field('score2', 'double', default=0.5), > > > > Field('answer3', 'string', default='null'), > > > > Field('score3', 'double', default=0.3), > > > > Field('readable_answer', 'string', default='null'), > > > > Field('tags', 'list:reference tags'), > > > > Field('nt_frequency', 'double')) > > > > > db.questions.tags.requires = IS_IN_DB(db, 'tags.id', db.tags._format, > > > > multiple=True) > > > > > And here is the controller that creates the form: > > > > > def create_question(): > > > > form = SQLFORM(db.questions) > > > > if form.accepts(request.vars, session): > > > > response.flash = 'form accepted' > > > > elif form.errors: > > > > response.flash = 'form has errors' > > > > else: > > > > response.flash = 'please fill out the form' > > > > return dict(form=form)
