Thinking about this some more, what I would like would be for a controller
to generate this json:
{ form:
{ fields:
[ {name: 'id', type: 'int', value: 234, error: '', comment: ''},
{name: 'title', type: 'string', length: 100, value: 'My Test
Record', error: '', comment: ''},
{name: 'start_date', type: 'date', value: '2013-11-15', error:
'', comment: ''},
{name: 'end_date', type: 'date'}, value: '2013-12-20', error: '',
comment: ''}
{name: 'type', type: int, value: 2, error: '', comment: '',
select: [{id: 1, string: 'Type One'},{id: 2, string: 'Type
Two'}]}
]},
meta:
{ _formkey: '4237yad87fw75398yt39y',
_formname: 'myform',
... }
}
Then the client side framework (be it Angular or whatever else) could use
this to generate the form interface however it wishes. When the end user
then submits the data the client side framework POSTs the same JSON data
back to the controller which will validate the record and return the JSON
back reporting whether the submit was successful and populating the error
parameter if any fields failed the validation.
plugin-clientapi is a bit different from what I am aiming to do as far as I
can tell. I stand corrected in that it does not just use web2py as a
database back end. It seems it basically allows you to do some stuff, such
as creating a form from javascript on the client side, which would normally
be done in a web2py controller. My aims are different; I would like the
web2py controller to keep control over what forms and data are presented to
the client, but give the client side framework control over how that form
and data is presented.
Looking at the SQLFORM, FORM and the process/validate methods it seems to
me that the HTML generation and form generation and validation are bound
too closely together for the MVC approach. As a result it is difficult to
customise the way a form gets presented on the client, as the DOM structure
is already generated by the SQLFORM class within the controller. I find
myself using {{=form.custom.widget.blahblah}} a lot in my views to take
back control of the forms appearance and function. Exploring the idea of
generating the view using a client side framework has highlighted for me
that with SQLFORM the controller is doing stuff that the view should be
doing.
I would have thought a better approach would be for SQLFORM to create an
object with the structure similar to what I outlined above (plus a lot of
stuff I have probably missed out) and then in the view you use a method to
generate the HTML (e.g. {{=form.asHTML()}}). The object would have all the
details needed to generate HTML, XML, or JSON along with the clever methods
to validate, insert, or update the form and CSRF prevention which would
remain in the controller as I would expect in a MVC approach. We could then
create our own custom methods to generate the HTML as we wish or even use
the view templates to generate the HTML in a more long winded but
customisable fashion.
--
---
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/groups/opt_out.
