problem changing version 1.95.1 to version 1.98.2

[juanduke]

Hi all:

I think this topic is related with backward compatibilty discussed in another thread, but anyway.

The situation: 

I've developed an app using web2py src version 1.95.1, in this app I load a form, from the view calling web2py_component using extension ".load"

Something like this:

#View:

web2py_component( '{{=URL(r=request, f="myControllerFunction",extension="load")}}','id_of_some_div');

I read somewhere in the book, that if web2py cant find a .load file, will use "generic.load" file (i.e. if theres not exist myform.load, web2py use generic.load)

and this behavior/magic, is what happend in v.1.95.1

The app is working perfectly on 1.95.1 And I repeat, I dont have .load file in my app, except generic.load.

But...,

When  I move my app to Version 1.98.2 (2011-08-04 00:47:09) (last stable version), I do some basic testing using my app, and when I access to the components, appears: Invalid view default/myform.load error message. I think this is right, because I dont created .load file, but WHY web2py dont use generic.load file in this case, like in v1.95.1.

Finally, my quick fix was: create the corresponding .load files (one for each component I call), and paste inside the new files the same content of generic.load

What I want to ask is:

- if this is new restriction/behavior of 1.98.2, or some minor bug in 1.95.1, or what?

- Is there another solution? 

- I'm missing something that need to know? 

- Someone can explain to me?

Thanks in advance!!

Bye.

PD: sorry for my bad english.

[juanduke]

I've found the paragraph of the book, that I readed when I'm saying: "...I read somewhere in the book..."

[http://www.web2py.com/book/default/chapter/13#Components]

If no .load view is specified, there is a generic.load that renders the dictionary returned by the action without layout. It works best if the dictionary contains a single item.

HTH.

Bye 

[Anthony]

This was changed due to a security risk. You now have to explicitly enable generic views by specifying response.generic_patterns somewhere -- it is a list of globs matching controller/function.extension.

To enable all generic views, add this in a model file:

response.generic_patterns = ['*']  # security risk

To enable the generic.load view only:

response.generic_patterns = ['load']  # still a security risk

To enable generic.load for particular functions:

response.generic_patterns = ['load'] if request.function in ['func1', 'func2', etc.] else []

or, inside the particular function itself, just do:

response.generic_patterns = ['load']

Anthony

[pbreit]

The "generic views" are now disabled by default for security reasons. The "welcome" scaffolding enables them on automatically on local page requests only. If you want them available in production (bad idea) you need to add a line of code.

Here are the options:

Enabled all the time:

response.generic_patterns=['*'] 

Enable specific generics:

response.generic_patterns=['myactions.json', '.html']

Enabled on localhost only (preferred):

response.generic_patterns = ['*'] if request.is_local else []

[juanduke]

Thanks for the reply! 

Very clear explanation!

So, I'll keep my .load files, for future customization of each components.

Thanks a lot!

[nick name]

As this issue keeps popping up every week, how about a mechanism to cope with this kind of change in the future:

In the wizard generated code, add a first line that calls

UpdatedForWeb2PyVersion('1.97.1', true)

(Where the 1.97.1 is the version that the wizard was run in, and 'true' means raise an exception)

Then, if there are non-backward-compatible changes such as the generic views thing, this will raise an error, with a link to the book page describing needed changes. That guarantees attention of whoever is upgrading. After they know it's working, they can update the version number.

Also, if the models/* code does not contain a call to UpdatedForWeb2PyVersion .. at all, we can assume e.g. 1.65.1, and call UpdatedForWeb2Py('1.65.1', false) before calling the client() code; the 'false' here would put the warning in response.flash but would not raise an exception.

How does that sound as a future-proofing mechanism?

[pbreit]

Do any other frameworks (that break compatibility frequently) do anything like that? This is the only compatibility issue I can recall and it should not have had much of an impact on production systems (generics are typically used primarily for development).

[nick name]

Python does, in a way ... if you use a depcreated feature, you get a deprecation warning when running the code.

And, the purpose of such a change is to optimize support/googlegroup traffic -- this specific issue comes up every single week since it was introduced.

[Phyo Arkar]

I already ran into this problem and i beleive theres a need for
announcement section on web2py.com site showing that generic is
disabled by default Starting at ... Version.

I already suggested to massimo i believe he will add an announcement
section when hes free.

[Willoughby]

+1

I'm trying to upgrade a production system I inherited from v1.61.1 to stable and having SQL problems.  I'd love a laundry list of things of known items instead of relying solely on a 'hunt and peck' method.  I'm sure the problem I'm running into is a security update of some sort...

[pbreit]

In theory, the upgrade should be OK and there's not really a "laundry list" of possible problems. It might help if you post whatever error messages you are getting and some code.

[Willoughby]

Thanks prbriet, I fully intend to do that once *I* understand just what the original programmer has setup here!  I'm too new to web2py to understand what he's done - lots of custom SQL instead of using CRUD.  But it's a great way to learn...

[Phyo Arkar]

after about 3 time i have experienced total breakdowns with blind
update, i no longer do blind update in production server. Always test
in test server first and update on production server only if
everything is working correctly.