Thanks Richard. I will if I have time. I find these small fixes have a way of becoming bigger projects than I expect :)
Ian On Friday, August 14, 2015 at 10:27:53 AM UTC-4, Richard wrote: > > Ian, you may also just write your own widget for list:string that way it > should behave correctly... > > > http://web2py.com/books/default/chapter/29/07/forms-and-validators?search=widget#Widgets > > def my_string_widget(field, value): > return INPUT(_name=field.name, > _id="%s_%s" % (field._tablename, field.name), > _class=field.type, > _value=value, > requires=field.requires) > > Field('comment', 'string', widget=my_string_widget) > > > On Fri, Aug 14, 2015 at 9:50 AM, Ian W. Scott <scot...@gmail.com > <javascript:>> wrote: > >> I agree with Richard that the issue (or my issue at least) has to do with >> the widget, not with the internals of the field type or its validators. >> >> There are, I think, valid use cases in which you want to use a >> list-string field but can't know ahead-of-time what the possible values >> will be. In one of my forms I'm (using SQLFORM.factory) using a list:string >> field to enter a series of word sets that will be used to build a >> subsequent collection of quiz questions automatically. I don't want to have >> to define ahead of time all the word-sets I might choose! But I'm also not >> concerned about duplication because the entered word-sets are just being >> used temporarily for the quiz-question generation. This may seem like an >> edge case, but I've got several forms with similar legitimate uses of >> list:string without a pre-defined set of values. >> >> In fact, the widget I'm having trouble with (text input with links to add >> more inputs below) only appears with list:string fields that *don't* have >> IS_IN_SET or IS_IN_DB. So this kind of use -- entry of and arbitrary number >> of arbitrary strings -- seems to be exactly what the web2py widget was >> designed to handle. >> >> As such, I think this *is* a shortcoming of the widget that should be >> fixed. The widget is being used for its intended purpose, but it's not >> following the "keepvalues" behaviour set for the SQLFORM. I'll submit a >> ticket on github. >> >> Val K's suggestion isn't complete, partly because it's now bypassing the >> SQLFORM's own keepvalues setting entirely. But thanks for the suggestion >> and I'll think more about it. >> >> Ian >> >> On Friday, August 14, 2015 at 9:24:29 AM UTC-4, Richard wrote: >>> >>> You need to use form.vars at first... At the begining your form is >>> emptyl, so you need to get the inputed value from the form not from >>> request.vars... You take them form request.vars for field default but when >>> you redirect you need to pass the form.vars to url... >>> >>> But even then, I am not sure it will works... The problem seems more >>> about the list:string type field which doesn't know how to handel available >>> values except if you use IS_IN_SET()... >>> >>> Richard >>> >>> On Thu, Aug 13, 2015 at 4:53 PM, Val K <valq...@gmail.com> wrote: >>> >>>> Hello! >>>> Looks some terrible, but does what you want! >>>> Just paste in any controller and go to .../list_fld_keep_values_tst >>>> or you can preset list-values by URL('your_controller', ' >>>> list_fld_keep_values_tst', vars=dict(defs=['val_1','val_2','val_3'])) >>>> >>>> def list_fld_keep_values_tst(): >>>> >>>> frm=SQLFORM.factory( Field('fld_lst', 'list:srting', default = >>>> request.vars.defs) ) >>>> if frm.process().accepted: >>>> >>>> #place your code here, before redirect! >>>> >>>> session.flash='Well are you happy now? Let me know in any >>>> case!' >>>> redirect(URL('list_fld_keep_values_tst', vars=dict(defs=request >>>> .vars.fld_lst) )) >>>> elif frm.errors: >>>> #do any >>>> response.flash='there are errors!' >>>> return dict(frm=frm) >>>> >>>> >>>> >>>> >>>> On Wednesday, June 25, 2014 at 6:33:26 PM UTC+3, Ian W. Scott wrote: >>>>> >>>>> I've got a SQLFORM.factory form set to keep values after processing >>>>> with process(keepvalues=True). But it doesn't work on a list:string >>>>> field. >>>>> The (otherwise very nice) widget loses all but the first value when the >>>>> form is submitted (i.e., all but the first text inputs for the field >>>>> disappear). Is there any way to carry those other text inputs and their >>>>> values over? >>>>> >>>>> >>>>> -- >>>> Resources: >>>> - http://web2py.com >>>> - http://web2py.com/book (Documentation) >>>> - http://github.com/web2py/web2py (Source code) >>>> - https://code.google.com/p/web2py/issues/list (Report Issues) >>>> --- >>>> You received this message because you are subscribed to the Google >>>> Groups "web2py-users" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to web2py+un...@googlegroups.com. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >> Resources: >> - http://web2py.com >> - http://web2py.com/book (Documentation) >> - http://github.com/web2py/web2py (Source code) >> - https://code.google.com/p/web2py/issues/list (Report Issues) >> --- >> You received this message because you are subscribed to the Google Groups >> "web2py-users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to web2py+un...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
