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