Thank you for the reply! That's quite an interesting mechanism you build. The FindAndCall handler hides the routing complexity in code. That certainly makes the app.py small and clean :-) When the number of my URL handlers goes out of control I could use that idea.
Meanwhile, I'm still hoping to see some good practice of organizing the URL handlers and various variables in web.py's each class a handler pattern. It looks like every time I start a project I have to go through some hoops to get the imports, class reloading, session, and module references right. Jack On Fri, Dec 7, 2012 at 1:38 PM, Shannon Cruey < [email protected]> wrote: > My project has four web.py servers running - a UI, and admin UI, a > reporting server and a rest api. The admin ui is pure ajax, so I have > about 20 "pages" with traditional urls, but each page is capable of making > dozens of ajax calls, each also a url, totalling several hundred urls. > > Rather than explicitly define all the urls in my root module, I've done > this: > > * I have code split into modules by functional groupings (user management > in one, reports in one, etc) > * I have a common.py module that has references to web, app and session, > plus anything else I'd want to share across my two dozen modules. > * my "pages" are served from templates, just like the template examples, > "return render(home)"... etc. > * my app.py main program, rather than having the hundreds of ajax > endpoints explicitly defined, instead has one primary handler function - > wmHandler. Looks like this (scrubbed of course): > > urls = ( > '/home', 'home', > '/(.*)', 'wmHandler' > ) > > My handler: > > class wmHandler: > #the GET and POST methods here are hooked by web.py. > #whatever method is requested, that function is called. > def GET(self, method): > return common.FindAndCall(method) > > def POST(self, method): > return common.FindAndCall(method) > > The FindAndCall method in a nutshell does python magic to find the right > module, import it, and exec the right function. It's pretty complex, and > not really relevant to your original question. > > Hope this helps! > S > > > > > On Fri, Dec 7, 2012 at 4:11 PM, JList <[email protected]> wrote: > >> Anyone? >> >> >> On Saturday, November 24, 2012 11:16:37 AM UTC-8, JList wrote: >>> >>> Hi all, >>> >>> I've been using web.py for some small projects that only involve less >>> than a >>> dozen URLs. A lot of times I put all URL handlers in the same .py file >>> (with >>> utility classes in separate files.) Everything works great. >>> >>> In other cases I put the URL handlers in separate .py files in the same >>> directory as the main app.py file which contains the start up code and >>> session initialization. In order for the URL handlers to access the >>> session >>> variable, they import the app.py as well. Because app.py also import all >>> the URL handlers for hot reloading to work, this sometimes creates a >>> circular reference if I'm not careful. I wonder how you initialize and >>> reference the session global variable in your web.py projects? >>> >>> When a project continues to grow I am thinking about putting URL handlers >>> in a directory (say, urlhandlers directory), and put all utility classes >>> in another >>> directory called utils. To access them, I can put a __init__.py in each >>> directory >>> and access them by modules. Do you think this is a good idea? >>> >>> More generally, is there a recommended way of organizing files and >>> directories >>> for web.py projects so that file hot loading and global variables such >>> as session >>> work and with the minimum possibility of issues such as circular imports? >>> >>> Thanks, >>> Jack >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "web.py" group. >> To view this discussion on the web visit >> https://groups.google.com/d/msg/webpy/-/QMgGEuc209YJ. >> >> 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/webpy?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "web.py" 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/webpy?hl=en. > -- You received this message because you are subscribed to the Google Groups "web.py" 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/webpy?hl=en.
