Carlo The T2 methods like create() and update() bundle the SQLFORM and accepts() and add some nice things like automatically updating stamp columns, e.g. created_by, modified_on, making nice short controller actions. However, on the downside, html related code is now in the T2 methods as well as SQLFORM and FORM.
I have proposed an approach in another thread and, for space reasons, written up an example at http://www.wellbehavedsystems.co.uk/web2py/examples/custom_forms.html. Basically, this approach adds methods and overrides a method on FORM and DIV to get the FORM to give access to form values and components by fieldname (as mentioned in my first post above). This example was a first attempt that concentrated on the create and update forms. I have got a bit bolder now and I am looking develop html-less T2 methods, and html-less versions of SQLFORM and FORM. This is still a work in progress and when working will be humbly submitted to y'all and Mr M for consideration. On Oct 28, 3:43 pm, carlo <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
