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.
