Remember earlier, I said I would have a lot to write? Well, I do. First, though, I have to address some things which were said while I was winding my day down.
On Wed, Jul 14, 2010 at 6:27 PM, Guyren G Howe <[email protected]> wrote: > > Routes integration *does* work (well, so far as I know, having never used > it). For me, I followed the tutorials, all of which focused on Object > Dispatch as the mechanism to use. If you could point me to a page that > suggests that Routes is the right way, I'd appreciate it. I've been over the > docs, and don't recall seeing anything that suggested it. > > So it's unclear why a very simple routes file is failing for me, if it's > supposed to work. > What I did was, following the pylons docs here < > http://pylonshq.com/docs/en/0.9.7/controllers/#using-the-rest-controller-with-a-restful-api > > > Note that I did *not* say that Routes worked. I did *not* say to use Pylons documentation to work on a TurboGears project. I said that Routes Integration worked. See the following for information about how to integrate Routes with your application: http://www.turbogears.org/2.1/docs/main/RoutesIntegration.html On Wed, Jul 14, 2010 at 6:46 PM, Guyren G Howe <[email protected]> wrote: > I'll note here that "The TurboGears Way" doesn't make it clear that Pylons > isn't just part of TurboGears, but is modified, and that you shouldn't just > do things like TurboGears does it. In fact, I think it suggests the > opposite. > Thanks to that title, I managed to figure out the page you were looking at. For anybody else following along, the page is here: http://www.turbogears.org/2.1/docs/main/TG2Philosophy.html Pylons is, indeed, at the core of the system. However, that does not mean that whatever works in Pylons works in TurboGears trivially. Routes are just one example, I'm sure there are others. That's a big part of why we have 531 files in our docs repository as of right now. If TG were nothing more than Pylons, well, we wouldn't have much need of those documentation files, would we? One thing that puzzles me slightly is that the page you are looking at is towards the bottom of the documentation stack. It comes in the next to last of the main segments, and it's linked about halfway down *that* page. In other words, finding it is not terribly easy, especially in comparison to finding the tutorials we have written (which can be found here: http://www.turbogears.org/2.1/docs/tutorials.html ). Those tutorials show you how to use the TurboGears Object Dispatch method in great detail. And yet, from the way you are speaking, you have not read the tutorials and are instead attempting to dictate the way you feel TurboGears should be based on something you feel you read in one of our documentation pages (but is not, in any way I can find, actually there). Please, forget that page you're talking about exists. Go, read the tutorials. There's a lot in there, and it will explain a great deal to you. I have until now been under the impression that TurboGears is a project to > integrate Pylons with Repoze and so on, so they are easy to install, and so > there are tools available that can run across them. I believe it is > important to make clear that TurboGears is not just a superset of Pylons. > What statement could be put into that page that is not already there? This is your chance: I'm the guy who does the most work on the documentation itself right now (with the possible exception of Mike Fletcher, that guy is a real boon to the team). Tell me what should be there. On Wed, Jul 14, 2010 at 6:49 PM, Guyren G Howe <[email protected]> wrote: > In fact, I'll also suggest that if paster restcontroller is deprecated, it > should be removed or at least issue a warning when one tries to use it. If > it is not deprecated, then the comment should be removed from the top of the > generated file and replaced with whatever instructions are appropriate to > getting the generated controller to be picked up by the routing > infrastructure. > Who said that "paster restcontroller" is deprecated? That particular piece comes from Pylons. In fact, if you do "paster help", you will see it listed under pylons, not TurboGears2). Short of us telling the Pylons team "Hey, your restcontroller in paster hurts, take it out", what would you have us do? Especially since, for people doing pure Pylons, that is a helpful command to have? We have no more control over Pylons than you do. We can't remove their template for them, and we can't update it for them. Two totally separate projects. Now that I've answered those specific points, time to get back to the original issue: Object Dispatch takes the place of Routes in a TurboGears project. This results in your having setting up your URLs extremely easily. Let's assume you have a simple contacts segment of your web application. Assume you already have your model set up like so: class Contact(DeclarativeBase): id = Column(Integer, primary_key=True) name = Column(Unicode(255)) emailaddress = Column(Unicode(255)) phone = Column(Unicode(64)) website = Column(Unicode(255)) Now, assume you want to create a Rest Controller that supports CRUD. Turns out that this is *really* easy with the tools that are available. First, make sure that tgext.crud and sprox are installed: easy_install tgext.crud sprox Next, create a new controller with this as the class: from project.model import Contact from tgext.crud import CrudRestController from sprox.tablebase import TableBase from sprox.fillerbase import TableFiller, EditFormFiller from sprox.formbase import AddRecordForm, EditableForm class ContactController(CrudRestController): model = Contact title = 'Contact Management' class new_form_type(AddRecordForm): __model__ = System class edit_form_type(EditableForm): __model__ = System class edit_filler_type(EditFormFiller): __model__ = System class table_type(TableBase): __model__ = System class table_filler_type(TableFiller): __model__ = System There, the CrudRest form is now done. You can do lots more with it (check out Sprox at http://www.sprox.org/ and tgext.crud at http://www.turbogears.org/2.1/docs/main/Extensions/Crud/index.html for more information), but that's the main part right there. So, now, how to get this visible in your application itself? Open up project/controllers/root.py and add this line to your RootController class (after adding the import to import ContactController): contacts = ContactController(DBSession) You're done. You now have full CRUD on your RestController. Suppose you would like to be able to move URLs around without having to manually maintain some sort of navigation bar in some separate file? Check out http://bitbucket.org/pedersen/tgext.menu for something that will manage your navigation bar. Need to be able to provide XMLRPC in your application? Check out http://bitbucket.org/pedersen/tgext.xmlrpc for an XmlRpcController. My overall point is that, right now, it seems like you are railing against what you believe TurboGears should be, instead of looking at what it is. Try looking at what it is, and seeing what it can do. You might be pleasantly surprised. Oh, one last thing: All of the code in this email is completely untested. I don't even know that I got indentation correct. I know it *should* work, but am not positive that it *does* work. -- Michael J. Pedersen My IM IDs: Jabber/[email protected], ICQ/103345809, AIM/pedermj022171 Yahoo/pedermj2002, MSN/[email protected] -- 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?hl=en.
