Reply to Neil and Adam On 10/3/06, Adam Jones <[EMAIL PROTECTED]> wrote: > > > 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 believe this thread belongs in the trunk list.
> 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) > Correct here As Fumachu says below CP3 will be able to handle Routes as a "subcomponent". so if people want it can be done. but there is no milestone/proposal of moving away from CP. about SA because of flexibility and Genshi for speed. > > > > 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. > actually the decorator ends up setting tg_template but it's done in a way that if there is an explicit tg_template that one is taken. I have use this myself with expose template being the "display data template" for the result of a search and if this brings out nothing I return the tg_template with "add new entry template". > > > > 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. > why not use @expose() ? about the @view(expose=False) well that's weird too, why will a view wont be exposed that makes even less sence, but that's a dead end since @view issue is solved. > 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. > I think he was just saying that it looks weird, about using routes directly I think the best will be to add another rule to expose, but that will need you to learn how to work with the RuleDispatcher package. > > > > 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 don't see why can't you handle the full URL in the default, remenber you get a list where each component is each part of the URL. so in default you will get the nickname (i guess look it up in the db), then take the archives, etc,etc. if you don't like "all that code" in there then split it up into methods none if them has to be exposed. one method that does everything usernames, another to access the archive and another to search the archive then all will return to the default. and it will show you the results. > 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 -~----------~----~----~----~------~----~------~--~---
