On Sep 4, 4:26 pm, mdipierro <mdipie...@cs.depaul.edu> wrote:
> I think we can modify your patch so that it does not require r=request
> (which would break some apps)
Why would requiting r=request for URL calls break some applications?
The code for URL is:
application = controller = function = None
if r:
application = r.application
controller = r.controller
function = r.function
if a:
application = a
if c:
controller = c
if f:
if isinstance(f, str):
function = f
else:
function = f.__name__
if not (application and controller and function):
raise SyntaxError, 'not enough information to build the url'
So supplying it where it wasn't previously shouldn't matter that I can
see as previously for it to work the called would have had to provide
a, c and f. If they are doing that they would still override what is
specified by the request object.
I could understand it breaking an overall application if an
application defined in or out routes which were conflicting and one
approach is perhaps to disable the automatic insertion of SCRIPT_NAME
if in/out routes, or routes detectable as conflicting, were defined.
At the moment the way I see it is if r=request not used everywhere, it
just means an appliance is relocatable as far as mount point goes. It
doesn't really mean that backward compatibility has been broken as the
application would still work when web2py at root of site.
Thus, using r=request becomes a guideline rather than a requirement.
If people want relocatable applications, they should use it. If they
don't care, don't have to. If they use in/out routes wrongly, they
could break relocatable applications.
> I think request.env..script_name is the same for all applicaitons
> within one web2py installation (correct?)
Technically no. Apache/mod_wsgi, and possibly any WSGI stack where you
use external routing to web2py, allow you to do a lot of odd things.
Take for example the Apache configuration:
WSGIScriptAliasMatch ^/u([0-9][0-9]*)/myapp(/.*)?$ \
/Users/grahamd/Testing/web2py/wsgihandler.py/myapp$2
<LocationMatch ^/u([0-9][0-9]*)/examples(/.*)?$>
WSGIApplicationGroup users
</LocationMatch>
What we have hear is many sub URLs of the site mapping to the web2py
application instance. Because we have used WSGIApplicationGroup,
rather than an instance for each sub URL, all requests still get
routed through to a single web2py instance. The application can change
its behaviour dependent on the apparent URL at which is was mounted.
In the example I gave above, I used a sub URL of the form 'u([0-9][0-9]
*)' as sort of indicative of a student number, but more practical case
where people have specifically asked how to do it in the past, is
where the qualifier may be a business name or company section.
In other words, they want to give prominence to distinguisher, be it a
student name, company name or section, as if each had its own
application instance where they don't actually and instead the single
application internally just shows different data based on mount point,
ie., SCRIPT_NAME.
So, URL of:
http://web2py.example.com/u1234/myapp
yields SCRIPT_NAME of:
/u1234
but URL of:
http://web2py.example.com/u1235/myapp
yields:
/u1235
It is quite possible that your in/out routes can perform the same
purpose, but that sort of defeats the idea that WSGI applications can
acts as components as well. Thus, a web2py instance could be composed
with other WSGI components within a Pylons stack where the Pylons
stack would deal with the external routing and the web2py application
should work without special configuration whatever the value of
SCRIPT_NAME.
> In this case we can store it in settings and retrieve it from inside
> URL.
>
> What do you think?
There are two issues around using gluon.settings.settings that I can
see.
The first is that you don't know the value of SCRIPT_NAME until the
first request is received so setting it would need to be atomic enough
that if multiple initial requests come in at same time that one
doesn't see a half set state for the dictionary. I am not too keen on
per request settings in a global configuration. Django when using
mod_python does stupid stuff like that, setting os.environ based on
per request information.
The second is that the whole idea of a global dictionary like
gluon.settings.settings means that you can only have one web2py
instance running within a Python sub interpreter. This limits the
ability to compose multiple distinct instances of web2py together
using something like Pylons. But then the structure of your site
instance with gluon contained within it, sort of precludes that
anyway.
Some frameworks such as Pylons and Werkzeug get around this sort of
issue by using thread local storage to stash references to per request
information. It can get a bit weird when talking about multiple nested
WSGI components, an example being the StackedObjectProxy from Paste
that Pylons uses.
Anyway, web2py isn't the first web framework to have this limitation.
You can't have multiple instance of Django applications either. It is
just the design model which has been chosen and nothing particularly
wrong with.
Supporting multiple instances where each uses a different data area is
applied quite successfully with Trac, which allows one Trac instance
to handle request against multiple projects, where project data
location is dictate by variables passed in through the WSGI
environment dictionary.
BTW, I am only up to start of chapter 4 at this point, so my
understand of web2py is still very limited. At the moment only looking
at it from perspective of how well a behaved WSGI application/
component it is. Later I will though bring up some issues I can see
with large scale deployment and distribution of individual appliances
to many sites.
Graham
> Massimo
>
> On Sep 4, 1:21 am, Graham Dumpleton <graham.dumple...@gmail.com>
> wrote:
>
>
>
> > On Sep 4, 4:11 pm, mdipierro <mdipie...@cs.depaul.edu> wrote:
>
> > > Hi Graham,
>
> > > I do not think this is necessary. You can just create a routes.py file
> > > in the web2py folder and write in it
>
> > > routes_in=(('/grahamd/(?P<any>.*)','/\g<any>'),)
> > > routes_out=(('/(?P<any>.*)','/grahamd/\g<any>'),)
>
> > > we have been using this for pycon registration for example.
>
> > That would go against the WSGI way of doing things, in that the WSGI
> > application shouldn't within its routing have the mount point
> > hardwired into the application code.
>
> > Graham
>
> > > On Sep 3, 11:19 pm, Graham Dumpleton <graham.dumple...@gmail.com>
> > > wrote:
>
> > > > At the moment, web2py will only work if mounted at root of the web
> > > > site. Thus, using Apache/mod_wsgi you can only say:
>
> > > > WSGIScriptAlias / /Users/grahamd/Testing/web2py/wsgihandler.py
>
> > > > You cannot say:
>
> > > > WSGIScriptAlias /subdir /Users/grahamd/Testing/web2py/wsgihandler.py
>
> > > > Since web2py seems to perform all URL construction for purposes of
> > > > links using URL, only one code change appears to be required in web2py
> > > > core to allow this to work. This is to the gluon.html.URL().
>
> > > > *** html.py.dist 2009-09-04 14:05:02.000000000 +1000
> > > > --- html.py 2009-09-04 14:06:48.000000000 +1000
> > > > ***************
> > > > *** 182,188 ****
> > > > if vars:
> > > > other += '?%s' % urllib.urlencode(vars)
>
> > > > ! url = '/%s/%s/%s%s' % (application, controller, function, other)
>
> > > > if regex_crlf.search(url):
> > > > raise SyntaxError, 'CRLF Injection Detected'
> > > > --- 182,192 ----
> > > > if vars:
> > > > other += '?%s' % urllib.urlencode(vars)
>
> > > > ! if r and r.env.script_name:
> > > > ! url = '%s/%s/%s/%s%s' % (r.env.script_name, application,
> > > > ! controller, function, other)
> > > > ! else:
> > > > ! url = '/%s/%s/%s%s' % (application, controller, function,
> > > > other)
>
> > > > if regex_crlf.search(url):
> > > > raise SyntaxError, 'CRLF Injection Detected'
>
> > > > Alas, because this is needing to access SCRIPT_NAME from original WSGI
> > > > environment, for this to work properly will require that 'request'
> > > > also be supplied in all cases where URL is used for URL
> > > > reconstruction.
>
> > > > For example, currently the 'welcome/views/default/index.html' page
> > > > says:
>
> > > > {{extend 'layout.html'}}
>
> > > > {{try:}}{{=H2(message)}}{{except:}}{{=BEAUTIFY(response._vars)}}
> > > > {{pass}}
>
> > > > {{=P(A(T("click here for the administrative interface"), _href=URL
> > > > ('admin','default','index')),_style="padding-top:1em;")}}
> > > > {{=P(A(T("click here for online examples"), _href=URL
> > > > ('examples','default','index')))}}
>
> > > > This needs to be changed to:
>
> > > > {{extend 'layout.html'}}
>
> > > > {{try:}}{{=H2(message)}}{{except:}}{{=BEAUTIFY(response._vars)}}
> > > > {{pass}}
>
> > > > {{=P(A(T("click here for the administrative interface"), _href=URL
> > > > ('admin','default','index', r=request)),_style="padding-top:1em;")}}
> > > > {{=P(A(T("click here for online examples"), _href=URL
> > > > ('examples','default','index', r=request)))}}
>
> > > > This will ensure that URL() has access to request object and so is
> > > > able to insert into the URL the value of SCRIPT_NAME, representing the
> > > > mount point of the WSGI application.
>
> > > > I don't know enough about web2py to know if there are other situations
> > > > where it would also be required to pass request object to ensure this
> > > > is all done correctly. Internally I think the core code always passes
> > > > through request object, so problem is more likely to be HTML templates
> > > > for views.
>
> > > > Graham
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
