The fact that auth is so tightly coupled with the view is very frustrating;
It would be better if auth return an object that was wrappable; in
FORM(); rather than the rendered form
This way you can do things like addfield() to the form before it is
rendered or just render it as it is;
I asked before "what is the easiest way to add a non-database field to
the registration form"
Right now I dont see an easy way to do this;
On 1/27/11 11:55 AM, Anthony wrote:
On Thursday, January 27, 2011 11:00:45 AM UTC-5, viniciusban wrote:
On Thu, Jan 27, 2011 at 3:27 AM, Bruno Rocha <[email protected]>
wrote:
> Thinking a bit more, taking the Vinicius comment and some
examples of
> another O.O frameworks.
> I was wondering about...
> #2
> auth.settings.formstyle = 'divs'
> form = auth()
> print form # return the HTML with divs
OK, but formstyle isn't related to auth in anyway, but it is to
form, right?
If auth wouldn't be showed (rendered) as a form, this property never
needed to be used.
Auth does a number of things, one of which is to generate various
forms related to authentication (e.g., registration, login, recover
password, etc.), so it seems relevant for it to have settings telling
it how to render the forms it generates.
> ...
> form.formstyle = 'divs' # sets the self.formstyle to 'divs'
> and immediately raises a redraw method
> #alternatively call explicitly the form.redraw() method
> print form # should now return HTML with 'divs'
>
> I think Vinicius are talking about the case #3, which I think it
is possible
> to implement, but I don't know the caveats,
Yes Bruno. You catched my mind.
Actually, formstyle='divs' is a SQLFORM form property. It is the way
print will show the generated HTML for this form instance.
When you create a SQLFORM form, it actually generates the HTML for the
form, which is then passed to the view. There isn't a separate
HTML-generation step at "print" time. So any properties that affect
the HTML have to be set before the form is created (so, 'formstyle' is
passed as an argument to the SQLFORM __init__ method).
So, conceptually it is a form property.
Your 3rd example show an intuitive method do implement this feature.
I didn't have time to see the source code yet (I plan to do this
tonight), but I see no reason to generate HTML code before the print
call.
At what point would you prefer to generate the HTML? Would you
prefer an explicit extra step to call a render method on the form
sometime after it is initially created (either before or after passing
it to the view)? What are the benefits of that approach?
Best,
Anthony
