Note, web2py will have the same limitations as any framework in this case. Most things should work fine, except of course anything Ajax related (including Ajax components). Most of what you'll lose can be discerned by inspecting web2py.js. Javascript is used for the following:
- Date/time picker for date and time fields (those fields will still work, but you won't get the special JS-based widget to enter dates/times). - Client-side validation of numeric fields (not a big deal -- can still do server side validation, which should be done anyway). - Flash message slidedown and fadeout upon click (so you'll have to display a fixed flash message on the page if you want one). - Slidedown of form errors (instead they will just show immediately when the page is rendered). - Pop-up dialog confirming record deletion on update forms. - Ajax, including Ajax components and the autocomplete widget. - The Superfish menu (though I think the new "welcome" app may be moving to a CSS-only menu, and there are obviously lots of other choices for displaying menus). - The search widget in SQLFORM.grid. So, overall, you don't lose anything major, and there are easy alternatives in most cases. By the way, why is client-side scripting forbidden? Anthony On Friday, June 15, 2012 4:45:49 PM UTC-4, Doug Philips wrote: > > Hey all, > I'm looking at deploying a web2py app in an environment where any > client side scripting is forbidden. Is web2py usable in that case? > There seems to be a lot of scripting going on in the default > layout.html. As a systems programmer with no web experience, I have no > idea what will stop working if I clients can't use Javascript, etc. > The Book isn't very clear on that either. SQLFORM, SQLFORM.grid, > SQLFORM.smartgrid, and Crud seem very much intertwined with scripting, > but I don't really know. I don't even know where to look. > Thanks, > --Doug >
