Just to say I tried your code and It worked fine.
I also tried passing some data from controller and using html helpers
(that I find handy) in view like:
# in controller
rows_clients=db().select(db.clients.ALL)
....
return dict(rows_clients=rows_clients)
# in view
<form>
.......
<div>
{{ t=TABLE(TR('Client:',SELECT(*[OPTION(rows_clients[i]
['name'],_value=str(rows_clients[i]['id']))\
for i in range(len(rows_clients))]))) }}
{{=t}}
</div>
...
</form>
and everything looks ok.
To me your code is the workaround I was looking for months, thank you
carlo
On 28 Ott, 15:43, Timothy Farrell <[EMAIL PROTECTED]> wrote:
> 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
>
>
>
> 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
-~----------~----~----~----~------~----~------~--~---
