Deo, welcome. It's always good to have new faces and to hear that
web2py is spreading.
Please see my answers below:
deo wrote:
> <snip/>
>
> I have a question on Tim's solution of creating a form in the view and
> replicating it in the action: how would I load values on the forms
> fields ? Would I have to go something like "<input text = 'name'
> value='{{= name}}'>" and pass the necessary values when rendering ?
>
You are correct in your assumption. Just at {{=valueVarName}} where you
need to. I don't much like this either but that's the way to do it with
web2py templates. This is not what I do, however. I use Genshi for my
templates instead of web2py templates (mostly because I prefer
validating XML templates rather than text-based templates). Genshi has
this form-filler feature where I pass it a dictionary and it will fill
an HTML form in my template without me having to templatize it as you
suggested above. If you have enough free time to learn Genshi, it would
be a good tool to add to your belt, but it is significantly more complex
than web2py templates.
> Also, I think repeating the form structure in the code could create
> problems later on, such as de-synchronizing the view and the action
> (adding a field in one of them and forgetting to add on the other one
> or even typos would cause a lot of hard to detect trouble).
>
Yah, that is an unfortunate downside and a concession I'm willing to
make. Consider that if you do even the slightest shred of testing on
such a form, you'll catch those problems very quickly.
> I could bare building the form using the helpers in the action,
> loading them with the values (like form.load(record)) and passing them
> on to the view, but the only ways I know for loading values into the
> fields are either creating the form with SQLFORM(table, record) (which
> doesn't allow me to customize it at all) or putting them into the
> _value attribute for each field (which becomes a lot of coding because
> I can't use the SQLFORM.accepts for automatically inserting and
> updating the db), is there any other way ?
>
IDK, Massimo should be able to help you there or you can go browsing
through the source code...it's a good read. =)
> <snip/>
>
Cheers,
-tim
>
> On 8 out, 21:23, billf <[EMAIL PROTECTED]> wrote:
>
>> Tim - thanks for all the info. As a Python newbie I have never heard
>> of FormEncode.
>>
>> Given what I know at this point I think I prefer to follow up your
>> first solution.
>>
>> The first thing I didn't understand was why the form.accepts() needed
>> the name of the form in your view? This got me digging and html.py
>> and sqlhtml.py (great to see all the arguments available) shed a lot
>> of light but there are still a lot of blanks as to how the whole thing
>> works.
>>
>> I have boiled all my questions down to: "Can someone please explain
>> the sequence of events embodied in the following?"
>>
>> form=SQLFORM(db.recipe)
>> if form.accepts(request.vars,session):
>> response.flash="Successful" (or something)
>> return dict(form=form)
>>
>> My version with holes is:
>> form=SQLFORM(db.recipe) > sqlhtml.py to create form from db.recipe
>>
>> form.accepts(request.vars,session) > sqlhtml.py then calls
>> FORM.accepts() in html.py; if return is true then goes on to update db
>> > html.py
>> FORM.accepts() implemented by DIV.accepts()
>>
>> Hole: I can't work out what is happening in DIV.accepts(). I'm
>> assuming there is some "first time" check - "we haven't any
>> request.vars yet" - that maybe uses the session but I can't see where
>> anything is stored in the session or how it uses the form name. Any
>> help greatly appreciated.
>>
>> Hole: I assume that if form.accepts() returns false then it does not
>> necessarily mean that there are errors - it could just be that the
>> form hasn't been output yet. Is that correct?
>>
>> Apologies if the questions are a bit vague.
>>
>> Bill
>>
>> On Oct 8, 10:12 pm, Timothy Farrell <[EMAIL PROTECTED]> wrote:
>>
>>
>>> I should also note that while this method has the advantage of using
>>> web2py's built-in data-verifiers, if you use FormEncode, you can get a
>>> bit more power and flexibility for about the same amount of code.
>>> Verifying the form I posted with FormEncode would look like:
>>>
>>> import formencode
>>>
>>> class FormValidator(formencode.Schema):
>>> name = validators.Regex(r'[A-Za-z0-9-\.\']{4,40}')
>>> county = validators.OneOf(COUNTIES)
>>> td = validators.Regex(r'on', if_missing='', if_empty='')
>>>
>>> try:
>>> data = FormValidator(allow_extra_fields =
>>> True).to_python(dict(request.vars))
>>> # Validation succeeded, continue
>>> except formencode.Invalid, e:
>>> # Validation failed, see messages in e
>>> message = e.message
>>>
>>> Bummer (for FormEncode) that form.accepts is so much cleaner than the
>>> FormEncode version. Maybe I'll wrap it into a nice pretty package.
>>>
>>> -tim
>>>
>>> Timothy Farrell wrote:
>>>
>>>> Bill,
>>>>
>>>> I crossed this bridge a few weeks ago. I, like you, don't dig the whole
>>>> presentation logic in the controller. However, it is still reasonable
>>>> to build a "form" in the controller for logical data-handling purposes.
>>>> Here's what I did:
>>>>
>>>> # Build our form
>>>> form=FORM(INPUT(_type="text", _name="name"
>>>> , requires=IS_MATCH('[A-Za-z0-9-\.\']{4,40}'))
>>>> ,SELECT(_name="county"
>>>> ,requires=IS_IN_SET(COUNTIES) )
>>>> ,INPUT(_type="checkbox", _name="td"
>>>> ,requires=IS_NULL_OR(IS_MATCH('on')))
>>>> )
>>>> # If the submit validates, act accordingly
>>>> if form.accepts(request.vars, formname="polinfo"):
>>>> # process passed data here...
>>>>
>>>> Once I made "form", I never passed it to the view, instead I used this
>>>> form:
>>>>
>>>> <form method="POST"
>>>> id="polinfo"
>>>> action="">
>>>> <div>
>>>> <label for="name">Name:</label>
>>>> <input type="text"
>>>> name="name"
>>>> id="name" />
>>>> </div>
>>>> <div>
>>>> <label for="county">County:</label>
>>>> <select name="county"
>>>> id="county">
>>>> <option></option>
>>>> <option value="Oklahoma">
>>>> Oklahoma
>>>> </option>
>>>> <option value="Other">
>>>> Other
>>>> </option>
>>>> <option value="Tulsa">
>>>> Tulsa
>>>> </option>
>>>> </select>
>>>> </div>
>>>> <div>
>>>> <label for="td">TD:</label>
>>>> <input type="checkbox"
>>>> id="TD"
>>>> name="td" />
>>>> <input type="hidden"
>>>> name="_formname" value="polinfo" />
>>>> </div>
>>>> </form>
>>>>
>>>> Notice that I included a hidden field "_formname". This is the trick
>>>> that you need to get it to work.
>>>>
>>>> There you go, a happy marriage of both the ease of web2py forms while
>>>> maintaining proper MVC separation.
>>>>
>>>> -tim
>>>>
>>>> billf wrote:
>>>>
>>>>> I am trying to get to grips with forms as part of an attempt to re-
>>>>> engineer an existing Java webapp using web2py.
>>>>>
>>>>> I like the ability to generate a form automatically. I especially
>>>>> like the benefit that accepts() gives. However, I can foresee many
>>>>> situations where the auto-generated form is not what I want in terms
>>>>> of layout. I have looked a little at widgets but I don't think that
>>>>> allows the ability to manage the overall form layout. I know that I
>>>>> can use the HTML building objects but I don't want presentation logic
>>>>> in the controller.
>>>>>
>>>>> It seems to me (at the moment) that the ideal would be the ability,
>>>>> when necessary, to design a form manually in a view using html/css but
>>>>> be able to utilise the form.accepts() logic in the controller.
>>>>>
>>>>> I'm tempted to think that this is already possible. If I code:
>>>>>
>>>>> form=SQLFORM(db.recipe)
>>>>> if form.accepts(request.vars,session):
>>>>> whatever...
>>>>>
>>>>> ...I am assuming that this creates a form based on db.recipe and
>>>>> populates the form.vars with request.vars and does the rest
>>>>> (validation, updating db). I just need to ensure that the
>>>>> request.vars names are those expected by the form?
>>>>>
>>>>> Before I spend a lot of time on this am I heading up a dead-end?
>>>>>
>>>>> Bill
>>>>>
>>> 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
