Neil Blakey-Milner wrote: > Hey there, > > I'm doing a "technology preview" of what TurboGears may look like in the > near future - SQLAlchemy, Genshi, and Routes. So far, I like it a lot - > Routes allows me to do some stuff I couldn't easily otherwise do.
I hadn't heard anything about Routes being in the future for TG. My understanding was that the project is going to stick with CherryPy for the forseeable future. Do you have any pointers to what you saw that suggested this change? If this is just a bit of wishful thinking I agree with you. The rest of CherryPy is outstanding, but I prefer the explicit flexability of solutions like Routes. (That said CP can be very flexible, it just takes more cleverness than I like using in one place) > > One problem I'm experiencing is that the expose decorator is what ties > the templating so nicely into things in TG. But its primary purpose (at > least going by the name) is to expose the function to CherryPy - to set > the .exposed attribute on the function. You can set the template in the return value as well, just return ' tg_template="yoursite.templates.templatename" ' I don't know how firmly this is tied in to @expose, if at all. > > So, maybe this is another vote for using @view instead sometime in the > future - @expose(expose=False) looks a bit weird. Until then, I'll just > create another decorator to remove the .expose attribute on the methods. You might want to look into simply not using @expose and working with Routes directly. I don't see how changing @expose to @view is going to solve any problems for you. > > Also, maybe I'm just missing something obvious on how to deal with a > problem like this: > > Let's say I have a blogging site with multiple web logs. The base is > http://foo.bar/, and individual blogs are at > http://foo.bar/unique-name/. > > Within the blog itself, there is /archives, which uses the common > pattern /archives/2006/10/03/post-name to find a post. There is > /feed.xml, and /categories, and so forth. > > The base mechanism in TG only gets me to the default function on the > root controller, and doesn't seem to offer me a way to "restart" the > processing on the remainder of the path. So: > > http://foo.bar/unique-name/archives/2006/10/03/post-name > > I only get to RootController, method default, where I can look up the > blog name. I can't then forward the rest of the request to a controller > that handles the blog portion (say, BlogController). I've been looking at this problem too. Remember that you can always call another controller function from within one, and return the value of it if you want. This situation would be handled by having a controller function that accepts the unique name and processes the rest of the arguments accordingly and calling that from the default function on your RootController. That is unless there is a better solution. I don't really care for that one too much as it moves the routing decision from one location (@expose decorator) to multiple locations. -Adam --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" 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/turbogears -~----------~----~----~----~------~----~------~--~---
