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
>
>
--
