just to confirm, ANY javascript piece of code relying on web2py.js functions will still work as intended. At the end of the new web2py.js there is a "compatibility layer" that remaps old function names to the new ones.
If someone added his own function, e.g. at the end of "old" web2py.js just to avoid creating a new js file, he/she can as well append those functions to the new web2py.js, after the "compatibility layer". However, this (editing web2py.js directly) is NOT encouraged, as Anthony explained very well in the previous posts. Problems will only arise if someone modified e.g. web2py_component() altering the default behaviour. This is of course not encouraged/supported in any way. BTW, shouldn't take that long to adjust everyone owns "customizations" to the new "style". There are also lots of comments. As for what jquery version is required, I can't really say anything in regards to the "old" web2py.js. The new one should be fine with query > 1.7, so ~ anything from november 2011 onwards **should work**. it's true that there's a theoretical break in this, but people relying on jquery <= 1.6 should be encouraged (or at least feel a little bit of pressure) to move forward (for speedups/optimizations at the very least). I'm not aware of any jquery plugin that requires such an ancient version of jquery. On Thursday, June 27, 2013 12:25:35 AM UTC+2, viniciusban wrote: > > It sounds good. > > On Wed, Jun 26, 2013 at 6:04 PM, villas <vill...@gmail.com <javascript:>> > wrote: > > I was just thinking that some users might have their own functions mixed > > together with web2py functions in web2py.js and might not wish to > extricate > > their work and save it elsewhere. > > > > To overcome that, make a completely different file to be the framework > > file. I suggested web2py_framework.js but could be any name. We could > then > > load that new file directly after web2py.js and override the original > > framework functions with the new versions. At least users would then > > hopefuilly get a working version of their own functions and a working > > version of web2py_framework.js without any effort. We specify exactly > which > > functions can be safely removed from web2py.js at the users' leisure. > > > > And yes, we could also do this by overriding the functions > conditionally > > and then leave users the choice as to whether they want the original > version > > of the web2py.js or the new framework one, but there's not much point > in > > over-complicating it. Users that care will review their js code. > > > > The thing I like about web2py_framework.js is that it would be a > completely > > new file, without any user code, so we could then ask everyone never > to > > touch that file. > > > > > > > > > > On Wednesday, 26 June 2013 16:21:58 UTC+1, villas wrote: > >> > >> +1 Anthony > >> > >> These days any sophisticated web framework must surely include some JS. > >> The framework must be able to guarantee which functions will be > available > >> client-side. > >> > >> If we accept that at least one JS must be part of the framework, then > we > >> can choose whether this should be web2py.js. > >> Perhaps alternatively we announce "web2py_framework.js" and overload > all > >> essential functions from that new file. > > > > -- > > > > --- > > 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+un...@googlegroups.com <javascript:>. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > -- --- 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/groups/opt_out.
