Traceback (most recent call last): File "d:\code\git\web2py\gluon\main.py", line 447, in wsgibase serve_controller(request, response, session) File "d:\code\git\web2py\gluon\main.py", line 186, in serve_controller run_models_in(environment) File "d:\code\git\web2py\gluon\compileapp.py", line 569, in run_models_in restricted(code, environment, layer=model) File "d:\code\git\web2py\gluon\restricted.py", line 227, in restricted exec ccode in environment File "d:/code/git/web2py/applications/welcome_themeable/models/db.py", line 37, in <module> response.formstyle = myconf.take('forms.formstyle') # or 'bootstrap3_stacked' or 'bootstrap2' or other File "d:\code\git\web2py\gluon\contrib\appconfig.py", line 71, in take (part, '-->'.join(walking))) BaseException: forms not in config []
________________________________________ Kiran Subbaraman http://subbaraman.wordpress.com/about/
--
-- mail from:GoogleGroups "web2py-developers" mailing list
make speech: web2py-d...@googlegroups.com
unsubscribe: web2py-develop...@googlegroups.com
details : http://groups.google.com/group/web2py-developers
the project: http://code.google.com/p/web2py/
official : http://www.web2py.com/
---
You received this message because you are subscribed to the Google Groups "web2py-developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web2py-develop...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
I don't see anything that allows to set a different set of widgets, which is kinda the main deal
If I understand this is a matter of replacing the welcome app. We can have more than one welcome app.
if we could recycle pydal, templates and validators
Personally I think we need to do a better decoupling of CSS from the frameworks, but more JS coupling.
we need to make a decision about this.we do have a 3 possible form logic:1) the current logic. SQLFORM(…) returns a helper which can be manipulated but must know in advance about the style2) the gluino logic: Form(….) returns an abstract object that can be optionally serialized. It must know the style before being serialized3) the ractive/w3 logic: From(….) return an abstract object that serialized in JSON. The conversion JSON->HTML is done client side in ractive.My guess is we could merge 2+3 and offer both options and perhaps even re-implement SQLFORM on top of that. Example:form = Form(db.table).process()if form.accepted: …if form.errors: …… form cannot be manipulated as before unless form = form.html(formtyle=request.formstyle){{=form.html(formtyle=‘bootstrap3’)}}and for backward compatibilitydef SQLFORM(*a,**b): return Form(*a,**b).html(formtyle=request.formstyle)I have lots of this done using new (better) helpers but this will require extensive testing. Shall we make this a Chr
On Oct 19, 2015, at 4:27 AM, Niphlod <nip...@gmail.com> wrote:
Form(*a,**b).html(formtyle=request.formstyle)
I agree, lets work on this. However I don't like this:Form(*a,**b).html(formtyle=request.formstyle)What I don't like is that it has an html method. It doesn't even make sense to have one since formstyle will be the one actually doing it. We should really just completely separate rendering the form from its abstract representation.A cleaner way for me would be, for instance, to have a FormRenderer class, instances of that class or its subclasses would take an abstract form in the constructor and then render it in some desired way when called.
To be clear. The html method would not generate html but the same object as sqlhtnl does today so that people can manipulate the form programmatically as the do today.