much clearer now thank you. Definitely T2 methods like create() and update() can become interesting to me only if your efforts to code a html-less version of them will get to success.
carlo On 28 Ott, 18:42, billf <[EMAIL PROTECTED]> wrote: > 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 > athttp://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 -~----------~----~----~----~------~----~------~--~---
