On Sep 5, 5:55 am, mdipierro <mdipie...@cs.depaul.edu> 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 <francisb...@googlemail.com> wrote:
>
>
>
> > On Sep 4, 1:49 pm, mdipierro <mdipie...@cs.depaul.edu> 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 web2py@googlegroups.com
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---
