Indeed...SQLFORM.factory() doesn't take any named arguments: def
factory(*fields, **attributes):
On Sunday, August 18, 2013 5:41:32 PM UTC+2, step wrote:
>
> My bad, your answer works perfectly (tested). I hadn't noticed HOW you
> specify fields in the signature, **fields* instead of fields=
>
> On Sunday, August 18, 2013 5:33:46 PM UTC+2, step wrote:
>>
>> I'm having trouble finding the right fields= format for SQLFORM.factory.
>> When fields= is a list of gluon field objects, SQLFORM.factory bails out
>> with
>> <type 'exceptions.AttributeError'> 'Field' object has no attribute 'find'
>>
>> File "E:\web2py-trunk\web2py\gluon\sqlhtml.py", line 1001, in __init__
>> if fieldname.find('.') >= 0:
>> AttributeError: 'Field' object has no attribute 'find'
>>
>>
>> which makes me think it wants fields= as a list of 'tablename.fieldname'.
>> But when fields= is a list of 'tablename.fieldname' form factory bails out
>> with
>> <type 'exceptions.AttributeError'> 'Table' object has no attribute '
>> person.id
>>
>> which makes perfect sense because the attribute name is 'id', so
>> hopelessly I try fields= as a list of 'fieldname' and form factory bails
>> out with
>> <type 'exceptions.AttributeError'> 'Table' object has no attribute
>> 'table1_field'
>>
>> when form factory is working on t2, which makes perfect sense again since
>> table1_field is not in t2.
>>
>> On Sunday, August 18, 2013 4:12:45 PM UTC+2, step wrote:
>>>
>>> Brilliantly simple, I should have thought of it. Meanwhile I coded a
>>> jQuery version and it's simple indeed, but your solution is better. Thanks.
>>>
>>> On Sunday, August 18, 2013 3:01:17 PM UTC+2, Niphlod wrote:
>>>>
>>>> I think you'd have to rethink the whole process. SQLFORM.factory will
>>>> work only if the "original" fields are the same then the "posted" ones. If
>>>> you're planning to switch tables in the meantime, the form.process() will
>>>> likely NOT work the way you'd expect.
>>>> If you don't want to code your html form by hand (and the relative
>>>> validation logic), I'd simply reload the whole form on that particular
>>>> "first field" and then have something that orders fields the way you like
>>>> BEFORE istantiating the SQLFORM.factory object.
>>>> e.g. (not tested)
>>>> fields = [db.t1.field1, db.*t2*.field1, db.t1.field2, db.*t2*.field2
>>>> ...]
>>>> if "something" in request.get_vars: #or any other thing that "marks"
>>>> this as the request for the "newly ordered" form
>>>> fields = [db.t1.field1, db.*t3*.field1, db.t1.field2, db.*t3*.
>>>> field2...]
>>>>
>>>> form = SQLFORM.factory(*fields)
>>>> .....
>>>>
>>>>
>>>>
>>>> On Sunday, August 18, 2013 2:47:41 PM UTC+2, step wrote:
>>>>>
>>>>> Indeed. While I was waiting for replies I realized my question (and
>>>>> thinking) was somewhat flawed. What I want to achieve is an
>>>>> SQLFORM.factory
>>>>> of two tables, t1 and t2, where t2 is placed after t1.this_field instead
>>>>> of
>>>>> after t1.last_field, visually (all <tr>s)
>>>>> t1.field
>>>>> ...
>>>>> t1.this_field
>>>>> t2.field
>>>>> ...
>>>>> t2.last_field
>>>>> t1.field
>>>>> ...
>>>>> t1.last_field
>>>>> submit_record
>>>>>
>>>>> then I want for the user to be able to change to a different t2 (ajax
>>>>> load) by selecting an appropriate value of t1.this_field.
>>>>> I think it would be simple to output the default combined form - with
>>>>> the whole of t2 following the whole of t1 - and then move t2's rows in
>>>>> place with jQuery, but I got deep into this experiment of doing all the
>>>>> form manipulation using server-side DOM. Maybe I should back out and just
>>>>> do it with jQuery, though it's less visually appealing.
>>>>>
>>>>>>
>>>>>>>
--
---
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 [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
