That makes sense; thanks. I guess I never looked at it that way.
On Wednesday, September 26, 2012 2:02:41 PM UTC-6, Anthony wrote:
>
> 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
>>>
>>>
--
