Sorry Graham. You are right I got confused. Had a long day. I will add you patch to trunk but, as you and Fran, say we should make this optional. What do you suggest as a way to make this optional?
Massimo On Sep 4, 6:49 pm, Graham Dumpleton <[email protected]> wrote: > On Sep 5, 5:55 am, mdipierro <[email protected]> wrote: > > > That is true. I am in favor of including Graham's patch for now but I > > have a feeling there has to be a better solution. > > Massimo, you have replied to the wrong discussion thread, so part of > what Fran was saying was actually pertinent to this discussion thread > and not the other one. So, bit of confusion perhaps. > > There are two suggestions I have made under separate discussion > threads. The first was about URL() and the second about > wsgi.file_wrapper. You replied about URL() on this thread for > wsgi.file_wrapper. > > As for applications using URL(app,controller,function) breaking when > mounted at a sub URL with this change, the fact is that they will > break already when mounted at a sub URL, ie., without the change. So, > you haven't necessarily changed anything or made anything worse. The > only way that use of that pattern would work at present is if in/out > routes were used, and as a I mentioned, a middle ground is perhaps > that if in/out routes defined, or used in a conflicting way, that the > SCRIPT_NAME insertion be disabled. > > Anyway, let me look more at how in/out routes work first. > > In mean time, you might check start of this thread again and look at > the wsgi.file_wrapper suggestion in case you missed it. > > Graham > > > On Sep 4, 10:12 am, Fran <[email protected]> wrote: > > > > On Sep 4, 1:49 pm, mdipierro <[email protected]> wrote: > > > > > You are correct that the solution you proposed would work. My only > > > > concern is that some existing application do URL(app,controller, > > > > function) instead of URL(r=request,function). That is valid. When they > > > > try to deploy behind WSGI in a subfolder they will find the links > > > > break. I agree with you that they can change the URL(...) arguments > > > > but they are not supposed to. I like your fix but it would be nice if > > > > we could come up with a way that does not break any existing app. > > > > If the new method is made optional (as per one of Graham's > > > suggestions) & the docs on the enabling mention clearly that the > > > r=request format needs to be used to have this work, then this still > > > doesn't break backwards compatibility whilst allowing us to move > > > forward :) > > > > F > > > > (I'm fortunate - may app always uses r=request as that's the style > > > I've seen published in examples) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
