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.
