Massimo, that gave me a ticket with this:
Traceback (most recent call last):
File "C:\repo\anima\gluon\restricted.py", line 186, in restricted
exec ccode in environment
File "C:/repo/anima/applications/welcome/controllers/default.py",
line 754, in <module>
File "C:\repo\anima\gluon\globals.py", line 96, in <lambda>
self._caller = lambda f: f()
File "C:/repo/anima/applications/welcome/controllers/default.py",
line 553, in editar_diag_beta
form =
crud.update(db.diagnostico_beta,request.args(0),deletable=False)
File "C:\repo\anima\gluon\tools.py", line 2756, in update
hideerror=self.settings.hideerror):
File "C:\repo\anima\gluon\sqlhtml.py", line 906, in accepts
hideerror=hideerror,
File "C:\repo\anima\gluon\html.py", line 1512, in accepts
status = self._traverse(status,hideerror)
File "C:\repo\anima\gluon\html.py", line 522, in _traverse
newstatus = c._traverse(status,hideerror) and newstatus
File "C:\repo\anima\gluon\html.py", line 522, in _traverse
newstatus = c._traverse(status,hideerror) and newstatus
File "C:\repo\anima\gluon\html.py", line 522, in _traverse
newstatus = c._traverse(status,hideerror) and newstatus
File "C:\repo\anima\gluon\html.py", line 522, in _traverse
newstatus = c._traverse(status,hideerror) and newstatus
File "C:\repo\anima\gluon\html.py", line 529, in _traverse
newstatus = self._validate()
File "C:\repo\anima\gluon\html.py", line 1300, in _validate
(value, errors) = validator(value)
ValueError: too many values to unpack
But I had already succeed with this:
class TAGS_LIST:
def __init__(self, separator=',', error_message='This is not a
valid list!'):
self.separator = separator
self.e = error_message
def __call__(self,value):
try:
list = value.split(self.separator)
return (list, None)
except:
return (value, self.e)
def formatter(self, value):
tags = ''
for tag in value:
tags += '%(tag)s%(sep)s ' %
{'tag':tag,'sep':self.separator}
return tags
I have two question:
Could this be general relating different DBs?
Is there a way to define a default widget for a custom validator?
On Aug 26, 7:28 pm, mdipierro <[email protected]> wrote:
> try define
>
> class IS_LIST_OF_STRINGS:
> def __call__(self,value):
> return [str(x) for x in value.split(',')]
> def formatter(self,value):
> return ', '.join(value)
>
> and use
>
> Field(...,'list:string',requires=IS_LIST_OF_STRINGS())
>
> On Aug 26, 4:27 pm, yamandu <[email protected]> wrote:
>
> > Yes, I wish I could let the user input strings that don´t belong to
> > predetermined set.
> > A type of list that can add new itens does not make much sense for me.
> > This is just a multi select, not properly a list in its most
> > meaningful sense.
>
> > On Aug 26, 5:36 pm, mdipierro <[email protected]> wrote:
>
> > > This is not wrong.
>
> > > The problem is that your field has type='list:string' but you did not
> > > set requires=IS_IN_SET(('aaa','bbb','ccc')) or requires=IS_IN_DB(...)
> > > Without the validator web2py does not know which options are valid and
> > > which ones are not and does not know how to make a dropbox.
>
> > > You have a valid point though. There should be a default validator
> > > that allows to write strings separated by a comma or something like
> > > plugin tagging. Such validator has not yet been created.
>
> > > On Aug 26, 3:27 pm, yamandu <[email protected]> wrote:> I possibly
> > > found a problem with list:string field.
> > > > I´ve searched for a widget and I could found one for it.
> > > > So I starte to make my own based on
> > > > thishttp://blog.crazybeavers.se/wp-content/demos/jquery.tag.editor/
> > > > I could be like that tag editor in plugin_wiki too but I found it
> > > > harder to base on it.
>
> > > > The problem is when you update a field of type list:string using the
> > > > item1|item2|... syntax it parses correctly and saves like array
> > > > ['item1','item2']
> > > > But if you update the record it shows like ['item1','item2'] and if
> > > > you simply save it without editing it saves as ['['item1','item2']']
>
> > > > I think the correct would it to reverse parse it to the | syntax, via
> > > > widget maybe.
> > > > If it was like this it would be simpler to adpat the above mentioned
> > > > jQuery plugin.
> > > > But the way it is it´s need to do two types of parses.
>
> > > > Is this really wrong or not?
>
>
