When you build a form object in the controller, although you may make some
specifications that control its display, you are primarily defining a data
model for the form. The form object itself is not merely an HTML DOM
representation but also encapsulates the default and submitted values,
validators, CSRF token, etc. The form itself is ultimately serialized in
the view, and if you want something other than the default serialization,
you would handle that in the view as well (via form.custom or manually
created HTML markup). So, for the most part, true display-related aspects
of the form are generally handled in the view, and the controller (and
model for SQLFORMs) takes care of the data modeling and validation.
Anthony
On Wednesday, September 26, 2012 1:55:32 PM UTC-4, MichaelF wrote:
>
> I'm still struggling with the lines of control/authority/info-sharing
> between displaying/processing the data/form. (I realize not everyone agrees
> where these lines should be drawn, and even when drawn they're not
> necessarily "sharp, bright lines.") I like the idea of having the
> controller simply (!) get appropriate data and send it (say in a dict of
> lists of rows) to the view, which displays the data appropriately (in a
> form) and lets the controller process the form results
> (adding/updating/deleting records, etc.). The controller neither knows nor
> cares about the display of the data (but *does* need to know some of the
> form structure, so it will be able to know what to do with the data). The
> view needs to know what the data is, etc.
>
> But much of the code I see in the manual has the controller
> create/populate/process the form...and so then I wonder what the view is
> for. (I realize a page is usually more than just a form, and *that* is what
> the view is for.) I'd like for the controller not to have to create the
> form with all its fields. (This isn't a huge problem for me, but I *would*
> like to have the controller not create the form, if possible.)
>
> If I have a SQLFORM or CRUD, then the processing part is 'inside' the form
> processing, which is fine. But if I have a 'manual' form (meaning still
> using FORM and other helpers, but a non-SQLFORM, non-CRUD form), then the
> controller should process the posted data.
>
> As things exist now (by convention, I think), the controller creates the
> form and processes the results. Is there a prescribed way (convention, I
> guess) that would allow me to have the controller simply gather the data
> needed by a form (other than SQLFORM and CRUD), and yet be able to process
> the form but not build it?
>
> As the controller needs to process the form it needs to have a ref to the
> form object. I assume there's no easy way for the view to actually create
> the form and somehow tell the controller about it. So I'd have to do
> something like create a form object in the controller, then return that
> object (and related data). The form object would have NO items (input,
> checkbox, etc.). The view would add those items, essentially creating the
> 'stuff' that goes inside the form object. With this division of labor the
> controller still can process the form, and the view would essentially build
> it (really, update the form object the controller created). So, something
> like:
>
> #in controller file
> def my_stuff():
> form = FORM() #note: pretty much an empty form
> if form.accepts(request, session):
> ...
> elif form.errors:
> ...
> else:
> data = db...
>
> # my_stuff.html VIEW
> {{# build the form, using the form obj created by the controller}}
> {{form.append(INPUT...)}}
> {{form.append(_type=SUBMIT...))}}
> {{=form}}
>
> 1. Is this possible? I suspect not, as the 'recreation' of the form in
> the controller on submission won't match what was submitted.
> 2. Is this recommended?
> 3. Am I just making things too involved (and should just create the
> form in the controller)?
>
> Thanks.
>
> On Wednesday, June 27, 2012 10:39:03 AM UTC-6, Anthony wrote:
>>
>> Follow the examples in the book. Most of the form handling (including
>> creation of the FORM/SQLFORM) object should be handled in the controller.
>> In the view, you can handle the display of the form, but web2py will give
>> you a default display if you just do:
>>
>> {{=form}}
>>
>> Anthony
>>
>> On Wednesday, June 27, 2012 7:08:19 AM UTC-4, Pedro Casalinho wrote:
>>>
>>> This may be a dumb question but, should forms be created in controllers
>>> and passed to the view or should they be created in the view, taking into
>>> consideration the MVC model
>>
>>
--
