I mostly agree with you, that is why some version of "custom" + your
patch will be in the next version.
Massimo
On Oct 29, 1:14 am, billf <[EMAIL PROTECTED]> wrote:
> Massimo
>
> I think there are a few issues raised by your suggestion - excuse my
> ramblings:
>
> 1) If I knew as much about web2py as you I would have thought of your
> solution and not dug around as much :-)
> 2) I'm not sure adding html to the model satisfies everyone.
> 3) Dealing with fields that have options requires a different (or just
> more complicated) approach.
> 4) For the longer term, the view really needs concise helpers aot
> referring to both form.vars and db.table.field.default all the time -
> where would they reside?
> 5) For backwards compatibility, your custom() needs to handle other
> things like additional hidden fields.
> 6) I think that my interest/requirement has moved beyond custom forms
> to custom views so what should the t2 methods search(), itemize() and
> display() be returning (if not the current html)?
> 7) Personally, I don't think that the accepts() and rec_accepts()
> methods should reside in what are basically html objects (SQLFORM,
> DIV, INPUT). There is an argument, I don't know how strong, that if
> one considers REST, there may never have been a form - the controller
> could just receive a PUT, POST or DELETE that needs to be validated
> and acted upon.
>
> To be honest, I'm not sure where I think the validation and db update
> logic should reside. A quick list of random thoughts:
> - in the model, simply add methods
> - in the model - create a base "model" class that all application
> models extend
> - should a model be tied to SQL (this could be a terrible, time-
> wasting distraction)
> - in a resource - create a resource class that would usually wrap a
> record or a list of resources but could wrap other things like a non-
> html form (e.g. the bones of a search form) - in some ways a
> replacement for the way DIV is used currently - different kinds of
> resources know how to validate and persist themselves, return their
> attributes and, if required, render themselves in html, xml or
> whatever - could fit in nicely with REST
>
> This is all just brainstorming - I'd love to read other peoples' views
> (including "not important", "leave well alone" and "shut up this is
> really boring").
>
> On Oct 28, 9:48 pm, mdipierro <[EMAIL PROTECTED]> wrote:
>
> > I am not sure why you say there is any need to change T2 to use custom
> > forms with T2.
>
> > For example:
>
> > #in model
>
> > db.define_table('dog',SQLField('name',default=''))
>
> > def custom(table):
> > import uuid
> > formkey=session['_formkey[%s]' % table]=str(uuid.uuid4())
> > return DIV(INPUT(_name='_formname',_value=str(table)),
> > INPUT(_name='_formkey',_value=formkey)))
>
> > #in controller
>
> > def index(): return dict(form=t2.create(db.dog))
>
> > #in views
>
> > <form>
> > {{=custom(db.dog)}}
> > <input name="name" value="{{=form.vars.name or
> > db.dog.name.default}}" />
> > <input type="submit">
> > </form>
>
> > I guess custom can be made a method of the form itself. Bill sent me a
> > patch to do this. But this will do for now.
>
> > Massimo
>
> > On Oct 28, 4:27 pm, carlo <[EMAIL PROTECTED]> wrote:
>
> > > 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
>
> ...
>
> read more ยป
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"web2py Web Framework" group.
To post to this group, send email to web2py@googlegroups.com
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
-~----------~----~----~----~------~----~------~--~---
