forms are made of widgets and widgets are made of HTML and JS. We can "force" it and continue to code these things in Python as we do now but we up with Python code that has the only purpose that of generating HTML and including JS code. This is why it will be cleaner if we move this client-side completely.
One problem I see is that if we go that way for the Auth form we may break any serverside manipulation that people are doing right now. For example the logic to add captcha to the login form. Massimo On Monday, 8 September 2014 19:44:51 UTC-5, viniciusban wrote: > > With this thinking, we should not generate any HTML tag server side. > > The DOM exists when there's a HTML page, not only a form. > > I may missed something, but, what's the problem with server side > generated DOM? Almost every web page is generated server side. > > Again, I don't see DOM generated server side as a problem. The > problem, in my point of view, is coupling FORM object declaration with > HTML FORM tag generation. The latter must be done in view, while the > former, in controller. > > > > On Mon, Sep 8, 2014 at 6:47 PM, Michele Comitini > <michele.comit...@gmail.com> wrote: > > The approach is correct IMHO, not only for forms. DOM is client's matter > and > > by the way gives a nice level of abstraction over everchanging DOM > > implementations of clients. > > What eventually will be extended is the JSON dialect. > > There is a little overhead in the JS machinery on the clients that needs > to > > be adapted and mantained, but it is a smaller issue than that of server > side > > generated DOM. > > I suspect that the approach will be successful even on non-html devices. > > > > mic > > > > > > > > 2014-09-08 21:09 GMT+02:00 Leonel Câmara <leonelcam...@gmail.com>: > >> > >> My experience is that it's faster on the client side too unless you > have a > >> pretty good 3G connection (or even better 4G). > >> > >> That said, the scalability and hardware savings advantage on the server > >> side is unquestionable. You don't have to cache pre-rendered HTML and > you > >> finish requests quicker. > >> > >> -- > >> 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 web2py+unsubscr...@googlegroups.com. > >> For more options, visit https://groups.google.com/d/optout. > > > > > > -- > > 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 web2py+unsubscr...@googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > -- 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 web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
