I like the idea of a slimmed down equivalent of SQLFORM. However, I think
it should be written to permit client side rendering via js scripts, or
server side rendering in views; as such the output as json or python
object/array would be ideal.
Personally I prefer python to javascript so would render server side
myself. I do think SQLFORM offers useful features but I sometimes end up
discarding all the generated html to use my own custom view, which means
wasted processing time on the server. Being able to use the JForm output in
my own web2py view would be useful.
This is a shift in emphasis which is needed to support the trend for more
client side ui processing, so I am in favour. I think the way it works
should be clear and well documented, for those wishing to use it and those
wishing to remove it from the client side libraries loaded by default. I
sometimes find it hard enough as it is to figure out what happens when and
where in the existing web2py client side javascript, so adding more may add
to the confusion.
What are the implications for component forms interactively loaded and
posted, how would the client side javascript handle these cases?
Will code end up being duplicated in the bootstrap version and the
non-bootstrap version? If so will this increase the chances of
inconsistencies slipping in?
On Friday, September 5, 2014 6:56:23 AM UTC+1, Massimo Di Pierro wrote:
>
> Please find attached a welcome4.zip with contains the following files:
>
> controllers/default.py
> views/layout.html
> vides/default/index.html
> modules/jform.py
> static/js/jform.js
> static/js/jform-bootstrap2.js
> static/js/jform-bootstrap3.js
>
> My proposal is the following:
> 1) deprecate SQLFORM (but keep it for backward compatibility)
> 2) replace
>
> form = SQLFORM(table).process()
> ...
> {{=form}}
>
> with
>
> form = JForm(table)
> ...
> {{=form}}
>
> what is the difference? SQLFORM generates html. JForm generates JSON
> metadata which is then converted into the form client-side by the js in
> jform.js.
> why?
> - it is much faster because all rendering is done client-side
> - it can "optionally" submit the form via Ajax without having to change
> your code.
> - it is much easier to style and create widgets for different css
> frameworks.
> For example include the right one:
> static/js/jform-bootstrap2.js
> static/js/jform-bootstrap3.js (I only provide a layout for bs2 and not bs3)
> - it is much more powerful because you can customize widgets in JS.
>
> We could also add a JTable, a JMenu and a JLogin and keep all the styling
> info in JS files as opposed to Python files.
> This would make web2py leaner and cleaner.
>
> Thoughts?
>
> Massimo
>
>
>
>
>
>
--
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
---
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
