IMPORTANT: web2py 2.6.0-development

[Massimo DiPierro]

There is a major change upcoming in web2py 2.6 (which can be tested in trunk).

The change involves a better rewrite of web2py.js agreed upon the developers and implemented by Niphlod.

Because of this change applications which use components will break unless you upgrade the old web2py.js with the new one.

Anyway, try the latest trunk, check it out, and send us comments.

Massimo

[Ovidio Marinho]

I'm testing

      

         Ovidio Marinho Falcao Neto

                  ITJP.NET.BR
             ovid...@gmail.com 

               83   8826 9088 - Oi

               83   9336 3782 - Claro
                        Brasil

              

2013/6/26 Massimo DiPierro <mdip...@cs.depaul.edu>

Massimo


--

---
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.
For more options, visit https://groups.google.com/groups/opt_out.

[Vinicius Assef]

I think this is a note that must be highlighted before releasing as
stable, right?

[Niphlod]

ETA is more or less 1 year on this :-P

However, yes, it will be promply highlighted (and maybe in the far distant future web2py.js will be overwritten automatically ).

[Anthony]

More generally, we should probably make it more clear that web2py.js is properly a part of the framework and must be upgraded whenever the framework is upgraded (this could be mentioned here, and maybe a reminder message could be shown in admin when its upgrade button is used).

Anthony

[Massimo Di Pierro]

That is dangerous. What if people rely on an older version of have edited it? I think it is part of the specs that web2py upgrades do not touch the apps. Moreover, what if an old app is installed after an upgrade? 

[Niphlod]

On Wednesday, June 26, 2013 3:19:23 PM UTC+2, Massimo Di Pierro wrote:

 Moreover, what if an old app is installed after an upgrade? 

 

it won't work, plain and simple.

[Anthony]

On Wednesday, June 26, 2013 9:19:23 AM UTC-4, Massimo Di Pierro wrote:

That is dangerous. What if people rely on an older version of have edited it?

That's the point. web2py.js is not like the rest of the scaffold (i.e., optional and customizable) -- it interacts with the core framework, so it really belongs to the framework. You shouldn't edit it or rely on an older version of it any more than you should edit or rely on an older version of one of the gluon modules.

My understanding is that the changes to web2py.js in 2.6.0 will preserve backward compatibility of the API for older apps that call ajax(), web2py_component(), etc., so apps should only break if they have customized web2py.js or if they use some of its non-public functions (behaviors that we should discourage going forward).

Anyway, we're already requiring the web2py.js upgrade with 2.6.0 -- why not take the opportunity to explicitly make this a general requirement going forward rather than being locked in to a frozen version of web2py.js?

 

I think it is part of the specs that web2py upgrades do not touch the apps.

I think this one file has to be an exception. It doesn't seem feasible to have Javascript/ajax integrated with the core framework and yet not require that the Javascript be updated along with the framework.

Moreover, what if an old app is installed after an upgrade?

They'll break, but such apps will already break with the planned changes in 2.6.0.

Anthony

[villas]

+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. 

[Massimo Di Pierro]

Are you suggested web2py.js should be served by a spacial action and not being part of the applications?

[Anthony]

On Wednesday, June 26, 2013 11:33:59 AM UTC-4, Massimo Di Pierro wrote:

Are you suggested web2py.js should be served by a spacial action and not being part of the applications?

Interesting idea.

[Vinicius Assef]

+1

[LightDot]

+1 for considering web2py.js as a part of web2py framework, so users should be requested to update it along with the framework.

How about extending this definition and requirement to appadmin..?

Also - what happens with old apps that have ancient jquery.js? Will new web2py.js cause a chain of upgrades for such users, ie. requires new jquery.js -> requires new 3rd party js libs -> requires code adjustments in the application?

I guess now would be a good time to try out old vanilla welcome apps with new web2py/web2py.js... I really hate suggesting such things rather than doing them, but I'm up to ears in a project that's on the deadline so I have very little free time right now :/

Regards,
Ales

[Anthony]

How about extending this definition and requirement to appadmin..?

I don't think any framework functionality depends on appadmin, so you should be able to keep an old appadmin if you like, but in both the documentation and the admin interface, we should include a reminder to update appadmin on upgrade.

Anthony

[villas]

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.

[Vinicius Assef]

It sounds good.

[Niphlod]

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.

[Massimo Di Pierro]

The problem is that an old app can be installed after an upgrade and it would not work because it would still come with the old web2py.js. I do not think web2py.js can be update automatically nor it should.

[Jason (spot) Brower]

I wonder if we should have a comment in the file that they shouldn't change this file as it will be overwritten.

[Jason (spot) Brower]

We could also minify it so people would be nuts to try to change it. :)

[Richard Vézina]

Maybe just a check sum on file that should be update after an upgrade could allow to display a message in admin and maybe if the files to be updated have the sum of one of the precedent file mean that the user has didn't change anything those file could be overwritten whitout issue... I would prefer updating them manually even if they had not be modify and only be inform that they should be update...

Richard 

[Michele Comitini]

I  "web2py_framework.js"  part of the framework is a good idea.

We could have a way to access it like this in a view

{{=web2py_js(version='1.0', embed=True)}} -> expanded inline

{{=web2py_js(version='1.0', embed=False)}} -> a proper url is generated so that it's content can be fetched in parallel and cached by the browser 

mic

2013/6/27 Richard Vézina <ml.richa...@gmail.com>

[Niphlod]

@testers, please upgrade to trunk. A few changes went in that needs to be tested as well.