Carlo,
I haven't eaten the T2 candy yet either.
Been there, done that. I'd encourage you not to submit to a different
function. It's tempting for me because it makes for smaller functions,
but I learned the hard way that this is not the way to go. I started
out with my login form that submitted to an "auth" function. It was a
nightmare trying to get the user where they needed to be without
creating infinite loops. I eventually pulled the session validation
code out to a module while moving the authentication code into the
"login" function (which previously only displayed the login page). Now
it's clean and maintainable and the chance for infinite loops is 0.
-tim
carlo wrote:
> dear billf and Tim,
>
> you look advanced about tackling this issue and I call for your
> support.
>
> As I do not have yet much confidence with T2 plugin I am not sure I
> grasped what billf suggested.
> Billf, do you mind posting an example form with your method?
>
> My intention was always to have my forms defined entirely in the view
> (no widgets just html or sometimes html helpers) and Tim's solution
> looks addressing this issue (apart from some logic in the controller)
> though I did not test it yet extensively. My procedure was to send my
> form to a different controller where validation was accomplished by
> calling some custom functions which use the built-in validator class.
> Of course this breaks the auto submit paradigma that I agree should be
> a better practice.
>
> Your suggestions are welcome,
>
> carlo
>
> On 28 Ott, 07:31, billf <[EMAIL PROTECTED]> wrote:
>
>> Carlo
>>
>>
>>>> This reopened an old argue I have with web2py validation because if
>>>> you want to benefit of the accepts() feature you must put some form
>>>> presentation/helpers in the controller.
>>>>
>> With T2, two functions - say "create_widget" and "list_widgets" -
>> could look as follows:
>>
>> def create_widget():
>> return dict(form=t2.create(db.widget)
>>
>> def list_widgets():
>> return dict(itemize=t2.itemize(db.widget)
>>
>> The form creation is still being called by the controller but it is
>> wrapped in T2 methods. The methods also execute the accepts() method
>> giving you the validation and db updating which is so great bout
>> web2py.
>>
>> I have proposed a patch to Massimo that would allow a custom_view=True/
>> False argument to be passed to the T2 methods that would cause a dict
>> to be made available to the view. The dict would be keyed by
>> fieldname and each item would contain the current form value of the
>> fieldname and the html component that had been generated by web2py
>> e.g. an INPUT, SELECT or TEXTAREA. For example, if the dict were
>> called "latest" then the view could access the value of the field
>> called name by {{=form.latest.name.value}} or the component for a
>> dropdown list of countries by {{=form.latest.country.component}} (this
>> would return a SELECT complete with options and the appropriate option
>> selected). This allows total flexibility to customize your view in the
>> the view (except that options would be in the form of a SELECT: of
>> course, this could be overcome by allowing 'value' to hold a simple
>> value or a list of option values and which are selected).
>>
>> With the above patch, creating form html in the controller could be a
>> convenient option that could be switched off if not required.
>> Personally, I think that as web2py gains popularity it will be taken
>> up more by graphic orientated people (because of its simplicity). If
>> this is the case, the automatic html generation, whilst useful in
>> developing and testing, will be rarely used in the final application
>> generation and the primary interface between data and view should be
>> html-less.
>>
>> Perhaps there would eventually be 3 options - all controlled in the
>> view - apologies if the syntax is rubbish:
>> - take the object and output as standard web2py html (the current
>> method but controlled by the view), e.g. {{=form(default=True))}} or
>> {{=form_helper({{=form}})}}?
>> - get the value of a field and plug into hand-rolled html, e.g. <INPUT
>> name="description" value="{{=form.description}}"/>
>> - use a helper method, e.g. {{=select_helper(={{form.country}})}}
>>
>> Sorry - got a bit off the topic there.
>>
>> On Oct 28, 1:52 am, mdipierro <[EMAIL PROTECTED]> wrote:
>>
>>
>>> On Oct 27, 6:24 pm, carlo <[EMAIL PROTECTED]> wrote:
>>>
>>>> After some time spent on a Java project which kept me away from my
>>>> preferred language, I made a quick refresh of the latest posts.
>>>>
>>>> Found interesting the manual about the T2 plugin but I did not
>>>> understand what exactly the purpose of such a plugin shoul be. Someone
>>>> could recapitulate?
>>>>
>>> a plugin comprise of a set of components (modules, models, views,
>>> controllers and static files) that may be used by more than one app
>>> and act on the global variables (request, response, db, etc.) of the
>>> app that uses the plugin. Examples are CRUD and authentication.
>>>
>>>> Reading the T2 manual I also found "It used to be common to create a
>>>> <form>...</form> that submits the form variables to a different
>>>> page. This is no longer considered good practice."
>>>>
>>>> This reopened an old argue I have with web2py validation because if
>>>> you want to benefit of the accepts() feature you must put some form
>>>> presentation/helpers in the controller.
>>>>
>>> Did you look into gluon.sqlhtml.form_factory() which is described in
>>> the book?
>>>
>>>> Is the Tim Farrell solution as in the "Customizing Forms" thread still
>>>> the best? Or something new was added to the web2py cookbook in this
>>>> respect?
>>>>
>>> I think that solves a different problem, inserting hidden fields
>>> (_formkey and _formname) in custom forms. Am I wrong?
>>>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"web2py Web Framework" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---
begin:vcard
fn:Timothy Farrell
n:Farrell;Timothy
org:Statewide General Insurance Agency;IT
adr:;;4501 East 31st Street;Tulsa;OK;74135;US
email;internet:[EMAIL PROTECTED]
title:Computer Guy
tel;work:(918)492-1446
url:www.swgen.com
version:2.1
end:vcard
