Good points. I think this is roughly the approach taken in web3py:
https://github.com/mdipierro/web3py/blob/master/web3py/forms.py.
Anthony
On Friday, April 19, 2013 4:49:57 PM UTC-4, RHC wrote:
>
> 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 [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
