You're welcome.
I am still using it, though it hasn't gone into production use yet. It
has worked normally however throughout the development phase. I don't
foresee any issues with it. I'll let you know if I come up with anything.
carlo wrote:
> Thank you Tim,
>
> are you still using your previously posted trick to have forms mostly
> in the view? Any problem with that?
>
> carlo
>
> On 28 Ott, 15:16, Timothy Farrell <[EMAIL PROTECTED]> wrote:
>
>> 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?
>>>>>
>>
>> tfarrell.vcf
>> < 1KViewDownload
>>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
