Re: [tg-trunk] Sprints for the fall
I should be able to offer up the ShootQ offices for sprint space. We're located in Decatur next door to a tavern with great beer. Score! -- Jonathan LaCour http://cleverdevil.org On Aug 26, 2010, at 2:44 PM, Mark Ramm wrote: So, now that the summer is over, and my new TG project for sourceforge is released and available at sf.net/p/ I want to schedule some more TG developers sprints. Right now we have three main areas of focus: 1) Getting a solid release candidate out for 2.1 2) Updating our servers/project infrastructure 3) Updating our docs and site for better marketing I'd like to propose a sprint for the weekend of September 25th, with a co-located team of sprinters in Atlanta somewhere, and global sprinters around the world. If you're able to get a couple of people together and sprint in a particular location, let me know and I can help out with snacks or other sprint related incidentals. Then I'd like to get back on the monthly sprint schedule, so that we can keep the pace of development up in preparation for a big sprint at PyCon 2011. -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-tr...@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en. -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-tr...@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
Re: [TurboGears] Re: New to turbogears
sathya r wrote: Hii sorry to bug all of you and thanks for your replies. I have been told that there is something called pyjamas which enable you to convert your python code to javascript, so can i just use that and get away without having to work witj Javascript JavaScript is a fantastic language, and you'll almost always be better off learning it, rather than generating it from another language. By writing the code yourself, using a good JavaScript library like JQuery, ExtJS, or MooTools, you'll be able to debug your application more effectively. The easy route isn't always the smart route! -- Jonathan LaCour http://cleverdevil.org -- You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turboge...@googlegroups.com. To unsubscribe from this group, send email to turbogears+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears?hl=en.
Re: [TurboGears] Custom jsonifiers in TG2
Jesper, How is custom jsonifying handled in TG2? From the docs I can understand that TurboJSON is deprecated. For my application I prefer to use something like the jsonify.when decorator and not to add the __json__ method to my objects. In TG 2.1, we added this back using simplegeneric. You'll need to easy_install simplegeneric from PyPI and then you can see an example of using custom jsonifiers in the test suite here: http://bitbucket.org/turbogears/tg-dev/src/tip/tg/tests/test_generic_json.py Hope this helps! -- Jonathan LaCour http://cleverdevil.org -- You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turboge...@googlegroups.com. To unsubscribe from this group, send email to turbogears+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears?hl=en.
[tg-trunk] Re: a quick check on b1
Replying to myself here. Any updates on TG 2.1? The silence on this has been pretty deafening :) Also, we've discovered another bug with the new routing, and will be posting a ticket, test case, and patch shortly. -- Jonathan LaCour http://cleverdevil.org Jonathan LaCour wrote: Greetings! Things have been quiet in the TG world of late (at least on the mailing lists), and I wanted to check in and see what the status is on TurboGears 2.1b1. Specifically, I'd like to know what the release timeline looks like, and if the following tickets will be closed as part of the release: http://trac.turbogears.org/ticket/2409 http://trac.turbogears.org/ticket/2428 My team created both of these tickets, and provided patches for both problems, so I'd love to see them included in the release. We're working on our schedule for pushing out the next few versions of our software, and it'd be great to have some rough timelines to base things off of. Thanks for all of your hard work! I'll be at PyCon this year (speaking about TG and ShootQ), and would love to buy a round of drinks for any TurboGears developers :) -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-tr...@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
Re: [tg-trunk] Re: a quick check on b1
I totally understand how that goes! Chris has done a wonderful job on 2.1, and we're mostly very very happy with it. Especially the speed improvements! We've updated our previous ticket on routing issues with this latest problem, and a patch we think should resolve it (including a test case and a sample app): http://trac.turbogears.org/ticket/2428 I still would love to hear from someone about a rough time estimate for another 2.1 release. Also, anything I can do to help drive this process forward, I am happy to do. -- Jonathan LaCour http://cleverdevil.org Michael Pedersen wrote: Chris Perkins has been the primary driver for 2.1. He's also been having some real life issues holding him up in many ways, so hasn't been very active on IRC or on the ML. I'm just hoping that RL stops smacking him around soon, so we can get him back. I'd offer to take over for him for now, but have my own RL issues hitting me. I've got ear surgery tomorrow, followed by the recuperation time from that. By the end of the month, I'm hoping to have RL back in order, so I can contribute and maybe take some of the load off him. Between now and then, hopefully I'll complete enough of my own TG extension that it can be useful for others. I'll be releasing the first version of that during the beginning of next week. On Thu, Jan 14, 2010 at 11:33 AM, Jonathan LaCour jonathan-li...@cleverdevil.org mailto:jonathan-li...@cleverdevil.org wrote: Replying to myself here. Any updates on TG 2.1? The silence on this has been pretty deafening :) Also, we've discovered another bug with the new routing, and will be posting a ticket, test case, and patch shortly. -- Jonathan LaCour http://cleverdevil.org Jonathan LaCour wrote: Greetings! Things have been quiet in the TG world of late (at least on the mailing lists), and I wanted to check in and see what the status is on TurboGears 2.1b1. Specifically, I'd like to know what the release timeline looks like, and if the following tickets will be closed as part of the release: http://trac.turbogears.org/ticket/2409 http://trac.turbogears.org/ticket/2428 My team created both of these tickets, and provided patches for both problems, so I'd love to see them included in the release. We're working on our schedule for pushing out the next few versions of our software, and it'd be great to have some rough timelines to base things off of. Thanks for all of your hard work! I'll be at PyCon this year (speaking about TG and ShootQ), and would love to buy a round of drinks for any TurboGears developers :) -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com mailto:turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com mailto:turbogears-trunk%2bunsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en. -- Michael J. Pedersen My IM IDs: Jabber/peder...@icelus.tzo.com mailto:peder...@icelus.tzo.com, ICQ/103345809, AIM/pedermj022171 Yahoo/pedermj2002, MSN/pedermj022...@hotmail.com mailto:pedermj022...@hotmail.com -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-tr...@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en. -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-tr...@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
[tg-trunk] a quick check on b1
Greetings! Things have been quiet in the TG world of late (at least on the mailing lists), and I wanted to check in and see what the status is on TurboGears 2.1b1. Specifically, I'd like to know what the release timeline looks like, and if the following tickets will be closed as part of the release: http://trac.turbogears.org/ticket/2409 http://trac.turbogears.org/ticket/2428 My team created both of these tickets, and provided patches for both problems, so I'd love to see them included in the release. We're working on our schedule for pushing out the next few versions of our software, and it'd be great to have some rough timelines to base things off of. Thanks for all of your hard work! I'll be at PyCon this year (speaking about TG and ShootQ), and would love to buy a round of drinks for any TurboGears developers :) -- Jonathan LaCour http://cleverdevil.org -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-tr...@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
Re: [tg-trunk] Re: [TurboGears] observations about TG 2.1
As promised: http://trac.turbogears.org/ticket/2409 Ticket now includes unit tests. Can we get this merged in? -- Jonathan LaCour http://cleverdevil.org -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-tr...@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=.
Re: [tg-trunk] Re: [TurboGears] observations about TG 2.1
Jonathan LaCour wrote: If you wrapped the import in a try/except and only added the generic function stuff if simplegeneric is present on the system I think everybody would be 100% happy, even jorge ;) Of course, and that would be pretty easy to do. I'll work on a patch for this tomorrow. I'll submit a ticket with the patch when its ready, and reply to this thread with a link to the ticket. As promised: http://trac.turbogears.org/ticket/2409 Let me know what you think! -- Jonathan LaCour http://cleverdevil.org -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-tr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=.
Re: [tg-trunk] Re: [TurboGears] observations about TG 2.1
Mark Ramm wrote: If you wrapped the import in a try/except and only added the generic function stuff if simplegeneric is present on the system I think everybody would be 100% happy, even jorge ;) Of course, and that would be pretty easy to do. I'll work on a patch for this tomorrow. I'll submit a ticket with the patch when its ready, and reply to this thread with a link to the ticket. Thanks, -- Jonathan LaCour http://cleverdevil.org -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-tr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=.
[TurboGears] observations about TG 2.1
I've been working this week on moving an application from an ancient TurboGears 2.0 pre-release version, to TurboGears 2.1a2. First off, let me say great work to all the people who have been contributing and pushing TG forward. I salute you for all your hard work, and for doing such a great job! In the process of porting, there were a few little things that bothered me and made updating my application a bit more difficult: 1. As much as I did not like Buffet, the new render function madness has made it very difficult to set configuration options on our template engines. In order to set Genshi to use lenient variable lookup, and to output HTML rather than XHTML, I had to jump through a lot of hoops. 2. My application made heavy use of the json.py module, and defined jsonification functions using PEAK-Rules. I am super happy to get rid of PEAK-Rules as a dependency, but the existing replacement is completely inadequate. I think that there is real value in being able to define global JSON-ification rules in a separate module. In order to get this functionality back, I wrote this decorator: def when(typ): def deco(func): typ.__json__ = func return func return deco This works fine for my model objects, but doesn't allow me to define custom JSON rules for builtin types, so I am having to monkeypatch the TG jsonifier. All a bit hackish for my taste :) Apart from these two issues, upgrading went very smoothly, and I am noticing a bit of a speed bump throughout my application. Here are some suggestions for addressing these two issues: 1. Make it possible to set Genshi's options using either my application's configuration file, or easily in app_cfg. This isn't that difficult to implement, and if this is the type of thing that would be accepted, I'd be happy to create a patch. 2. Rather than ignoring users that were using PEAK-Rules, add the ability to register custom JSON-ification functions using something much simpler like simplegeneric (available on PyPI, and pure Python). The problem with PEAK-Rules was that it was crazy and poorly maintained. The simplegeneric module has neither of these problems and would restore a very nice capability back into TG. Again, I'd be happy to contribute patches for either of these issues if they are likely to be accepted. I'm curious to hear other people's feedback on these ideas. All the best -- -- Jonathan LaCour CTO, ShootQ - http://shootq.com Training - http://cleverdevil.org/train Blog - http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to turbogears+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~--~~~~--~~--~--~---
[TurboGears] Re: Production sites running TurboGears 2.0
Florent Aide wrote: chameleon.genshi is an implementation of genshi that has speeds in the range of mako. The only thing is that it is missing i18n support ATM. We should concentrate on helping chameleon people to get the hooks in place to support i18n... I spent several infuriating hours attempting to get this to install once, and completely gave up on it. I think it had to do with the fact that lxml is one of the most preposterously difficult to build libraries in the world. But, I could be misremembering. Also, IIRC, the documentation was totally non-existent on how one might actually use it with TG. -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to turbogears+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~--~~~~--~~--~--~---
[TurboGears] Re: Production sites running TurboGears 2.0
Florent Aide wrote: Well... I installed it on dev machines for Windows, Linux and MacosX so I don't share your POV. Even if I concede it is not the easiest lib to install. Of course, not 30 seconds after I posted this, I tried to easy_install it on my Mac, and it worked like a champ. So it looks like things have changed since I last tried it out, at least on the Mac. I'll have to try Solaris at some point soon as well. As for the TG2 support it is in the core of the renderers... and I could provide more info and even real directions if you transformed that into some helpful docs for us :) deal? We're still using a slightly old version of TG 2.0, and are using legacy buffet support to render templates. One of these days we'll upgrade to TG 2.0 final, and I'll definitely take you up on it :) Any ideas on how we might be able to try chameleon.genshi through the buffet support would be helpful, of course :) -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to turbogears+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~--~~~~--~~--~--~---
[TurboGears] Re: Production sites running TurboGears 2.0
What are some sites using TurboGears 2.0 in a production setting? We have been using TG 2.0 at ShootQ (shootq.com). The marketing website is PHP based, but the application is all TG 2.0. Its a very large and sophisticated application that we still think is very easy to use :) Is the site Forward Facing or a backend? Forward facing with thousands of users. How is the site deployed? (mod_wsgi, mod_python, apache2, proxy, paster, etc) We use paste behind nginx on our application servers, which are then behind a hardware load balancer which also provides SSL acceleration. What templating engine is used? (Genshi, Mako, Jijna, etc) Genshi for most of the application with Mako for performance sensitive areas. How have web designers reacted to the constraints placed with the templating engine you used? We love Genshi, and wouldn't use anything else if it performed faster. I would like to see this become a big focus of TG in the future. A faster version of Genshi! Are static files served by TG2? No, they are served by nginx. How much daily traffic are you seeing? (hundreds, thousands, tens of thousands) Tens of thousands of requests. What type of hardware/hosting? (virtual, virtual machine, dedicated, cluster, etc) We are hosted on Joyent accelerators, which are essentially highly optimized Solaris Zones. What implementation issues have you run into? At the time we started, there was no transaction manager in TG 2.0. In addition, we use MySQL master-slave replication for redundancy and load balancing. We ended up rolling our own WSGI middleware which: 1. Wraps all POST and DELETE requests in a transaction automatically, and routes all SQL to the MySQL master. 2. Routes all non-transactional (read) requests to a MySQL slave. 3. Allows us to flag certain requests as requiring the next request to certain URIs to read from the MySQL master. This is implemented as a decorator and a utility function. This is so that writes quickly followed by reads don't suffer from replication delay. This is all possible thanks to WSGI and Elixir/SQLAlchemy making it very easy to do. In addition, we ran into issues early on with static resources being served up too frequently and how to deal with this. We ended up rolling our own little helper functions to generate URIs for our static resources that include a revision stamp from our source control repository. We then utilize nginx to force this content to be cached by the browser. This makes it so that most of our static content is requested only once by the browser until we manually force it to be fetched again by changing the stamp. What steps have been taken to plan for the thundering herd? We make use of memcached, have a highly redundant infrastructure, and have multiple instances of the application on each application server, plus multiple application servers behind a hardware load balancer. We can scale horizontally by adding application servers and MySQL slaves, and vertically by turning up the resources available to our virtualized servers. In addition, most services run on their own server (we have over 9 servers we currently run on). We make use of memcached to cache intensive data like reports, and have written a monitoring system that alerts us when resource usage on our servers exceed a certain threshold. In addition, this system has an OS X dashboard widget we implemented that allows us to see the current status of all processes and resource usage across our servers at a glance. We also make use of Amazon S3 to keep user-generated content out of our systems and our database, which allows us to scale up to many hundreds of thousands of users without any concern. In particular, I notice shootq as a TG2 production site, but, they appear to run cakephp on the forward facing site and I assume they are using TG2 for the backend. Any input as to why the application development uses two frameworks? We do this exact thing because, honestly, a marketing website is very content driven, and its really not a great use case for TurboGears in my opinion. There's a great deal of immediacy to PHP, and being able to quickly push an update to the website without having to restart the paste processes is a big win. I have seen some input regarding using TG2 for facebook and I am wondering what sort of hardware and environment I'm going to have to deploy to run the application based on some real-world experience. I don't need to know the url of the sites, but, would like to get a little real-world data so that I can plan accordingly. Take a look at Joyent. They offer free accelerators for Facebook applications, last I checked. They are nice, as long as you aren't doing heavy I/O. Best of luck to you! -- Jonathan LaCour http://cleverdevil.org http://shootq.com --~--~-~--~~~---~--~~ You received this message because you are subscribed
[tg-trunk] Re: TurboGears 2.0 final announced
Mark Ramm wrote: The long wait is finally over! I am happy to announce the release of TurboGears 2.0 final. Congratulations to all involved! I truly appreciate all the hard work that went into TurboGears 2.0, and not just because it was born in my dining room ;) TG 2.0 has enabled us to develop a truly amazing application ridiculously quickly (http://shootq.com). I have no doubt that TG 2.0 is one of the driving reasons behind our success. Thanks, Mark, Florent, et al! -- Jonathan LaCour http://cleverdevil.org http://shootq.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[TurboGears] Re: [tg-trunk] TurboGears 2.0 final announced
Mark Ramm wrote: The long wait is finally over! I am happy to announce the release of TurboGears 2.0 final. Congratulations to all involved! I truly appreciate all the hard work that went into TurboGears 2.0, and not just because it was born in my dining room ;) TG 2.0 has enabled us to develop a truly amazing application ridiculously quickly (http://shootq.com). I have no doubt that TG 2.0 is one of the driving reasons behind our success. Thanks, Mark, Florent, et al! -- Jonathan LaCour http://cleverdevil.org http://shootq.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to turbogears+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TG2 and Elixir support
Helio Pereira wrote: Why do you remove elixir from the turbogears 2? Elixir and SqlAlchemy must walk together in TG2 :-P As I stated in an earlier email, its just a matter of someone having the time and putting in the effort to write the needed code for the new TG2 authorization/identity system. And as I also stated, nothing is preventing you from using Elixir with TG2. Support hasn't been removed, really, as Elixir is just SQLAlchemy under the hood. I am using Elixir with my TG2 project, and it works great. -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TG2 and Elixir support
Mark Ramm wrote: Exactly, and not claiming support is not equal to it not working as jonathan says, he's using it extensively. But he's not using the default auth mechanisms, and he's not able to provide that level of support to turbogears users. If someone is, we can easily add the elixir command back to quickstart. But we were shipping it, and it was broken, and nobody offered to help fix it. And while we could have done a one time fix, we would still be in this situation on every future release where we'd have to do that work without help from anybody in the elixir community. +1 on all accounts. I really wish I could be the one to offer this support, but I just can't commit to that at the level I'd like right now, at least until things settle down with the release of my application. Working for a startup sucks the life out of you! I do try and respond to Elixir-related questions on the mailing list when I have a chance, and I will continue to do that as much as time allows. Keep up the great work on TG2, folks! -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TG2
Helio MC Pereira wrote: quickstart don't have parameter '-e': Elixir support was removed from the project templates for TurboGears 2 until someone writes an Elixir model for the new auth/identity (whatever its called these days). I tried to keep up early on, but it seemed to be in such a state of flux/change that I just couldn't keep up! That being said, my application uses Elixir and TurboGears 2, and it works fantastically, so there's nothing preventing you from using Elixir in your project. I am doing something very similar to my article here: http://www.cleverdevil.org/computing/68/using-elixir-with-pylons If you need help getting it rolling, let me know and I'll see what I can do. I think its a real shame that Elixir support has been taken out of the templates in TG2, but working for a startup has sucked up all of my time that I can spend in front of a computer. Maybe someone else will step up before I can finally come up for air. Best of luck - -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[TurboGears] Re: [TG2] Persisting Data between Web Requests
BluePoint wrote: This all seems to work OK, at least in my development installation. My question is this; Is saving to module level variables a legitimate technique for making data persistent across HTTP requests? Will this work? Certainly. Is it a good idea? That's questionable at best. One of the biggest lessons I've learned about developing efficient and scalable web applications is that state must be pushed out of the application whenever possible. An HTTP request from the browser should be able to be handled by any instance of the application, so that you can horizontally scale across multiple processes and multiple machines. For this reason, keeping the state in-process is a particularly bad idea. Other, more safe options include: 1. Putting the state into the database. This is where long-term state belongs, if you are using a database. 2. Store the state in the user session. This is where very small amounts of state belong that are generally required frequently. Be careful not to rely too much on the session, and use a storage backend for your session that will allow you to horizontally scale. My favorite backend for this currently is cookie-based sessions. 3. Place the state in memcached. This is a great option for transient data that you need to keep around, but is too large to put into the session. 4. Push the state to the browser using JavaScript, and send it all over at once when the data is ready to be handled. This is nice because all of the transient state can live in the browser. In your case, it sounds like option #3 or #4 are the best for you. Personally, I'd lean toward #4. One of my larger applications that I've been working on for some time uses this technique frequently. We store large bundles of transient data in the browser's memory as JavaScript data structures, and then send them over to the application encoded as JSON, which is decoded by the TG2 app, and then persisted into the database. Best of luck. -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to turbogears+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: Auth in the quickstart - Elixir support
Gustavo Narea wrote: Is there any ETA to have Elixir working in TG2 with the new authority ? I really like Elixir :-P Unfortunately, I can't fix it myself because I don't use Elixir. It should be relatively easy and quick to fix it; somebody just has to find out why the code of this file is apparently specific to SQLAlchemy and doesn't work with Elixir. I am really really busy right now, and haven't had time to do much work on projects outside of my day job, but I will be at PyWorks, and I'll try and see if I can make it to the sprint and take a look at this. Note, this won't be for a few weeks, and I can't make any guarantees! -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[TurboGears] Re: ErrorDocument
GustaV wrote: So it looks like the class ErrorController is actually not used at all, does not override any default (Pylons?) error manager. You can check yourself: raise an exception in ErrorController.document() : nothing special happen. This is a bug in the default template. The ErrorController should not inherit from BaseController, which is a special TurboGears controller and screws up routing. You want it to inherit from WSGIController: from pylons.controllers import WSGIController class ErrorController(WSGIController): ... I had this very problem just yesterday, but this fixed it, and now I am getting my customized error document when problems arise. -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com 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 -~--~~~~--~~--~--~---
[TurboGears] Re: ErrorDocument
GustaV wrote: Another silly question : how can I know the exception that was raised while in the 'document' method? It would be useful to write my error message... In the environ variable, except 'paste.evalexception' (which doesn't seems to be what I want) nothing looks like an exception report! I don't have an answer to that particular question. You might want to ask that on the Pylons list. However, I can tell you what I do, which is to configure the error handler to send an email to a special address with the full error message, trace back, WSGI environment, etc. I also configure the error handler to write all this information to a log file on the servers: You can do the same using the following configuration parameters: from_address = [EMAIL PROTECTED] email_to = [EMAIL PROTECTED] smtp_server = localhost error_subject_prefix = Application Error: error_log = /tmp/error.log Best of luck to you. -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Basic questions
Michael Hipp wrote: I want to use: SQLAlchemy and Elixir jQuery (I think) Appears I would be targeting TG 1.1 or 2. Are they stable enough for use? TG 1.1 is likely more stable than TG 2.0, but TG 2.0 is built on top of some pretty rock-solid tools. I'd call it a push. What you'll be dealing with in 2.0 is a moving target, so I'd probably encourage you to go with 1.1, unless you are starving for some of the things in 2.0 (which you probably aren't). How do I learn TG2? I wanted to buy the book but fear much would be N/A due to the big changes in components. Most all the docs seem to be for the 1.0 version. You dig into the code and play :) Ask questions here on the mailing list. There is no comprehensive documentation, as far as I know, just yet. If you feel that documentation is a huge need, I'd encourage you to go with TG 1.1 or Pylons. I like Django's simple templating system. And it looks like Jinga might be its closest relative. (I just can't get warm to the heavy XMLish and Python-code-in-the-markup style of Genshi and Kid. No offense.) How hard would it be to use Jinga instead of Genshi? Its easy to use alternate template systems. I'd encourage you to take a close look at Mako, which is blazing fast, and has lots of great features. How about using jQuery instead of Mochikit. This is a matter of taste. I use ExtJS, but have used both JQuery and MochiKit in the past. You can't really lose, as they all are excellent, but I've moved away from MochiKit, since it hasn't really seen much progress in ages. Good luck. -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com 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 -~--~~~~--~~--~--~---
[tg-trunk] Re: TurboJSON and PEAK-Rules
Alberto Valverde wrote: http://paste.turbogears.org/paste/3141 I had already discovered this and attempted it myself, and it didn't fix my problem. I put it at the top of my `json.py` module, and it doesn't seem to get rid of the default rules, resulting in an AmbiguousMethods exception. Nice try, though :) -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TurboJSON and PEAK-Rules
Alberto Valverde wrote: Just a FYI, I've released prioritized_methods at pypi: http://pypi.python.org/pypi/prioritized_methods/ Any interest around here in me getting my dirty hands on TurboJson to integrate it? Since I'm the squeaky wheel, I'll give this a shot today. I'll let you know how it goes :) -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TurboJSON and PEAK-Rules
Jonathan LaCour wrote: Since I'm the squeaky wheel, I'll give this a shot today. I'll let you know how it goes :) Well, I tried, and failed :) Looks like there is a bug somewhere in prioritized_methods. When I replace the peak.rules `when` with the `prioritized_when`, all sorts of things go boom. Specifically, all of the default rules in TurboJSON raise exceptions about not being able to find imported modules. I can get a little further by replacing the `isinstance` checks with concrete type checking, but anything that passes a string-based rule that depends on something in the local namespace (imported modules like `datetime`, or helper functions like `is_saobject`), things blow up... Any ideas, Alberto? -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TurboJSON and PEAK-Rules
Alberto Valverde wrote: If this works for you I'll release a fixed prioritized_methods to pypi and if no one objects I'll merge this TJ branch with the trunk too. Works great for me. -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TurboJSON and PEAK-Rules
Alberto Valverde wrote: I think this could be solved in two ways which would allow default rules to be bundled (after all, TG2 is all about providing sane defaults to make simple things simple, right?) TG2 is about making simple things simple, but its not about doing it at the expense of complex things. Bottom line: both of your options make it much more difficult to write a simple custom jsonifier, and don't really solve the problem in a simple way. I want to have this at the top of my `json.py`: @jsonify.when((Person,)) def jsonify_person(obj): ... This is much simpler to write, and is way easier to explain to a new user than something like this: @jsonify.when(isinstance(obj, Person) and crazy_disambiguator(1001)) def jsonify_person(obj): ... Imagine having to write this 50-60 times (in my case)! New users don't want to think about things like generic function disambiguation. I think your ideas are both fine ideas, but they don't eliminate the need to be able to turn the defaults off. I think the simplest approach here is the best: put the defaults in a separate module, and have them be imported by default in the TG2 json.py template in your project. If you want to remove the defaults, you can simply delete that line from your `json.py` and you're set! The simplest solution is the best, IMO :) -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TurboJSON and PEAK-Rules
Alberto Valverde wrote:
Option 2 involves subclassing TJs encoder, in what way isn't that
simple? (and it might solve another bug for free as Chris Z has
pointed out)
Maybe I misunderstood, would rules still be able to be functions,
rather than methods? I was under the impression that this method
would involve changing the way that jsonification rules are
written. If that isn't the case, then my objections to this method
are completely withdrawn :)
Option 1 involves *no* change in user code since TJ's
implementations can have a lower priority than the default so any
extension made by the user automatically overrides the built ins
(I thought I had emphasized this point...).
Yeah, in my exhausted stupor, I must have missed that detail :) As
long as the user's rules *always* override the defaults, I am a
happy man! Objection withdrawn to this solution.
The following command could save you some time ;)
$ find . -name '*.py' -exec sed -e -i 's/\(@jsonify.*\))$/\1,
1)/g' {} ';'
Ah, sed! Incidentally, this is exactly what I would have done :)
So if you only need to override how Person is jsonified you
suddenly need to copy and paste (or re-implement for the fun of
it) the rule to jsonify all other SA mapped objects from tg since
you turned it turned it off en masse.
Well, this is what I was doing, because I actually don't want every
single field of my SQLAlchemy objects to be serialized. I want to be
able to explicitly control it, which is why I don't like there being
no way to turn off the defaults! Having complete control over the
JSONification of my objects is extremely important to me.
Both solutions I proposed allow to *selectively* extend the
encoder while preserving rules any extension might have added or
might need to add.
Sure, but I still want to be able to turn them off, even if it
does break some future extension. The bottom line for me is that
I totally understand (and agree with) your arguments, but I still
think that there needs to be a mechanism for clearing out the
default rules to give the user complete control over them.
Thanks for your hard work, Alberto!
--
Jonathan LaCour
http://cleverdevil.org
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
TurboGears Trunk group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---
[tg-trunk] wrap_app in tg/middleware.py
As I stated in my earlier email, I am performing an upgrade on my application, and I have some custom WSGI middleware which requires the use of beaker sessions, and placing my middleware on the outside of the TurboGears WSGI stack isn't going to work for me. I noticed that in `tg/middleware.py`, there is a `wrap_app` keyword argument that is in place, however it doesn't actually appear to let you wrap the application. It needs to be changed to this: if wrap_app: app = wrap_app(app) Once I make this change, I am able to do what I want, and my middleware works perfectly. Thanks to everyone for their hard work on 2.0! -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TurboJSON and PEAK-Rules
Mark Ramm wrote: I am +1 on moving those rules into a function that could be called once by the developer. (to maintain compatibility). This sounds like a good plan, and we can call that rule in json.py in the quickstart template. But this would be a breaking change for some folks, so we should document it. Great idea. I'd love to see this included in another alpha release really soon now (along with the `wrap_app` change discussed earlier). With these two changes, I am pretty sure my app will run 100% under TG 2.0. -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[TurboGears] Re: Best practice query - storing layout in db
MOD Films wrote: I'm using TG 1.0 / Genshi / Sqlalchemy and wondering what best practice is for storing markup in db and passing this through to a template. Is there a simple way to tell Genshi - don't escape template variable value when rendering? In my project, I have an area where users can type into a rich text component, which generates HTML, which I subsequently store in the database. If you want to insert this into a Genshi template, you have to tell Genshi that you are inserting potentially nasty HTML data so it will effectively not hold that portion of the document to the stringent standards it holds for the rest of the template. You do that like so: div py:content=HTML(my_content) / As for storage, I tend to put these things into SQLAlchemy Text columns. Good luck. -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com 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 -~--~~~~--~~--~--~---
[tg-trunk] Re: Site Components - Requirements
Mark Ramm wrote: This is fine when you want super simple things. But take a look at django contrib for a whole list of things that would be absolutely impossible if apps couldn't change the model. (A simple example, a comments app, which allows you to add comments to various content.) I actually agree with both of you here. Components must be able to add tables / model objects to your database. That being said, I don't think that the only way to do this is to hardcode those model definitions into the components themselves, for several reasons: 1. Its difficult to figure out what the component is creating without either digging through the source or the documentation. This creates a disconnect between how you interact with your model typically, by simply looking at or editing your model source. 2. Its difficult to change the data definition or plug in existing model objects that provide the needed behavior without doing weird things in some configuration file or monkey patching. I'm tempted to suggest code generation as a solution for this, but I think that also provides issues when you want to upgrade a component for example. Perhaps there could be a balance here, where if you just want the default behavior of the component, and don't care about making any tweaks to its behavior, you don't have to have much of the component's code injected into your project, but once you start to override things, you can have the code for that particular aspect of the component copied into your project tree, where you can override the behavior directly? -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: Site Components - Requirements
Patrick Lewis wrote: Other than upgrading, are there other issues with injection / templating? Is reuse in other projects / apps a concern? Are there other issues? From the standpoint of seeing what's going on and making changes though, injection is attractive (IMO). Not really. The big issue is that it adds a lot of code to your project that you didn't write, and makes it difficult to perform upgrades to the component itself. How would a hybrid approach work? I'm guessing the end developer would issue a command to spit the component into the project, but what then? Is it totally in the end-developer's hands? From a component writer's perspective, it seems like there would be more overhead, but maybe you could make tools to help out. Well, it seems to me that you'd issue a command the very first time that you wanted to use a component, and you could tell it whether you wanted the entire component's source spit into your project, or if you'd prefer to use the defaults. Either way, I think code should be added to your project, but the default would be placeholders that import from the component, aliasing the classes/functions from the component itself into your project's namespace. If you wanted to later tweak things, you could issue another command, which could selectively start replacing those placeholders (model, templates, API, etc) with the actual generated code/templates, which you could then edit to your heart's content. This is what I meant by a hybrid approach. -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: Genshi, Mako, and search paths
Mark Ramm wrote:
I would like to depricate the dotted notation on template lookups,
and just use search paths.
I've been wanting this for quite some time. It looks nicer, and
its the same as Pylons. As long as I can still put templates into
subdirectories, and use slashes to specify the relevant part of the
path [EMAIL PROTECTED]('people/index')] I'll be very happy.
--
Jonathan LaCour
http://cleverdevil.org
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
TurboGears Trunk group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---
[tg-trunk] Re: tgrepozewho
Mark Ramm wrote: And we might be able to tweek the dispatch mechanism a bit to eliminate the need for some of this stuff. This works, but it's not particularly efficient at object instantiation time... We should definitely push some of this into the dispatch mechanism, just to make the code simpler. However, since its using a metaclass, its actually quite efficient at object instantiation time, since all of the work occurs when the class is loaded (at import). -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: MicroTG2 anyone?
Mark Ramm wrote: I think we can make a much smaller version of TG, with fewer dependencies. The particular reason for wanting this is the Google App Engine which restricts users to 1000 files. We might just be able to fit TG into the environment, but we wouldn't be leaving much room for add-on libraries or user code. :( I love the idea of a Micro TG2, but not for the same reasons as you. What I'd love to see is the core of TurboGears 2.0 broken down into the smallest possible kernel of code and functionality. I'd love to see a `TurboGears2-Core` egg that included nothing but: * Base Pylons Dependency * Genshi * Object-Dispatch That tiny core of functionality is all you really need to get started with TurboGears, in my opinion. This is just a good idea in general, to keep the core as small as possible, and build in additional functionality (SQLAlchemy support, transaction middleware, auth/auth, etc) as additional eggs that can be installed. For people who want just the basics, they can install just the core. Others, who want more of the full stack can install an egg that pulls all the other features (which are eggs) as dependencies. This is all motivated by a somewhat selfish desire to have such a thing, since I am actively developing an application on top of TurboGears 2.0, and am finding myself to be very happy rolling my own for things like transactions and authentication/authorization. It'd be a shame to have to install all of these extra dependencies if I don't need them :) -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: MicroTG2 anyone?
Mark Ramm wrote: But that's kind of opposed the full stack or batteries included approach that TurboGears was founded on. I'm all for a minimal alternative with a TG2 like API, but I don't think it should be the default. Cool, I agree with you here. I think the default should be to install everything. I am just saying that I think that the core of TurboGears itself should be installable separately, and that it should *be* this micro framework at some level. In my opinion, its just a nice way to keep ourselves from getting to cluttered with stuff in the core. IIRC, our plan was to to release a tg-server or something egg which has exactly enough to run the simplest possible hello world app. This will definitely not include genshi or turboJSON, or mako, or sqlalchemy, but MAY include FormEncode. Making this a separate egg should not be too hard. Cool, I'm into that. Determining what to call the eggs, and how to put them together, wiithout making things complicated for new users isn't as easy. I don't want to make people do: from tg-server import expose, redirect from tg import validate and have to keep track of which thing is where... at least without some very clear, very obvious devision between the two. Sure, and I don't want that either. Eggs allow you to get over this pretty easily, ensuring that everything can still live under the tg namespace, even though they may live in separate eggs. Yea, that extra 2 meg of disk space is a real killer. ;) I just want to point out that installing extra stuff does not mean that it will be run, or take up memory in TG2 it just means that the eggs live somewhere on disk. Everything's imported from the template, so if you don't use them, don't import them and you should be good to go. Hah, good point ;) I agree that its really not that important since all of the dependencies are pulled automatically anyway, but I still like the idea of having an extremely minimal core. -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: Template rendering
Mark Ramm wrote: We're thinking about dropping the buffet plugin from TG2. Pylons is definitely in process of depricating it in 0.9.7. The reason behind this is mainly that buffet restricts the ability of users to use the more advanced features of Mako and Genshi, and requires a huge amount of code to do something really simple. After talking with Ben about this a few weeks ago, I am definitely +1 on the idea. So, my proposal is that we create a default render method that takes an engine as an optional parameter. [snip, snip] The main benifit of this theory is that it would allow us to keep the current expose style, and allow users to create non-default renderers just by creating a new render function and setting it up in the config. It would also allow users to have several renderers installed -- but not imported or used in a particular project. This seems simple, and sane. I heavily depend on the stacked expose style of TurboGears 2.0, and have found it to be a largely great way to get things done, and would be even happier if it supported extensions as a way to determine the requested content type and thus engine (GET /people/200.json vs GET /people/200.html). I am also very excited by the prospect of creatin simple callables that define custom render functions. -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: tg2 and Unicode params
Mark Ramm wrote: I think the easy way out of that is to provide a switch that allows a user to specify that they don't want the params passed into their function at all. They should still be able to get at the validated params from the request object. Love it, and I think a project-wide switch is good enough. -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: tg2 and Unicode params
Mark Ramm wrote: The fact that TurboGears turns incoming request prams into controller function params seems intuitive and smart to me. But there are some limitations: * Function params must have asci string names * Function params can have only one value I actually think the first problem is irrelevant. As Diez suggests later, this can be controlled by the developer, and I believe that if the developer really needs non-ascii parameter names, they can just take in `**params` rather than explicitly defining them in the method. The second problem is a genuine issue, and one that bit me just today. I think that we should solve this at a higher level, and parameters that have multiple values should just come through as a list of the values. I am working around this right now by using `request.params` and it works fine for me for the time being. -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[TurboGears] Re: Sessions with Elixir both in and outside of TurboGears
Tunmer, Luke wrote: The problem I'm getting seems to hinge on the fact that I need to grab from my Entity the auto-incrementing primary key Field that is generated from the database. I use this as a publicly-visible identifier. I have tried a whole slew of combinations of stuff, and none of them seems satisfactory. If these problems are happening within TurboGears, then its almost certainly because you are not using TurboGears's session. Like I said, I am pretty sure TurboGears 1.x supports SQLAlchemy by creating its own transactional/autoflushing session, which you'll need to make sure to use with your Elixir model. In your model.py, you should be able to do: import turbogears import elixir elixir.session = turbogears.database.session See if that helps. -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Sessions with Elixir both in and outside of TurboGears
The problem I'm getting seems to hinge on the fact that I need to grab from my Entity the auto-incrementing primary key Field that is generated from the database. I use this as a publicly-visible identifier. I have tried a whole slew of combinations of stuff, and none of them seems satisfactory. Oh, and one more thing. Since the TurboGears default session is transactional, you'll likely need to do a flush() manually on the instance itself to get the generated primary key. Good luck. -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Sessions with Elixir both in and outside of TurboGears
Tunmer, Luke wrote: What is the best way of changing the session that is made available to Elixir by default? I've plowed through the documentation and source and it's not clear to me what the intended way is. The relevant section of the docs: http://elixir.ematia.de/apidocs/elixir.options.html Read the part under `using_options` regarding `session`. You can specify a session through `using_options`, by creating your own and assigning it to `elixir.session`, or by setting `__session__` at the top of the module containing your entities. I believe that TurboGears implements automatic-transactions by creating its own session, and expecting you to use it. You'll likely want to use this session when using your model from within TurboGears, and creating your own when you are using your model outside of TurboGears. Good luck. -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com 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 -~--~~~~--~~--~--~---
[tg-trunk] Re: TG2 Validate
Mark Ramm wrote: I think there was a notion to make validate into a real decorator with no particular hooks in the TurboGears controller's __call__ method. That would make it easy enough to replace the TG validator with custom validators from tosca, or wherever. Count me as a huge -1 on this idea. Real decorators are often real difficult to debug. I'd greatly prefer it if we could just make the existing validate decorator more extensible by allowing you to pass in callables. All of the gain, with none of the hassle! We specifically did it this way, because we didn't like how the previous TurboGears 1.x decorators ended up nesting your controller methods tons of times, producing insane stack traces. -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TG2 Validate
Mark Ramm wrote: I agree with that on some basic level, but I also think it's important to differentiate @validate from @expose. Okay, I sort of agree, and sort of disagree with you here... @validate is designed to change the method signature, whereas @expose should not. This should read @validate *was* designed to change the method signature, but that doesn't mean that it *has* to be done this way. Personally, I find decorators that change the method signature to be a little bit difficult to understand, and if its hard for me to understand, then its probably going to be really hard for beginners to understand. I believe that we can get all the functionality that we need in @validate, without having to do crazy things, or create nutty stack traces. @validate is a reasonable candidate for somebody to switch out with a new implementation, and @expose is not. I agree with you here, but there are two ways we could do this that are far less insane than creating a wrapping decorator: 1. Allow our @validate decorator to take in callables to perform generic validation, and error handling code that someone defines on their own. This way, people can do whatever they like. 2. If someone wants to replace the implementation of @validate, then they should create their own decorator, not monkeypatch TurboGears to use their implementation. So, I don't see this as a good argument, personally. I'm not so worried about @validate as I was about expose, the decorator version of @validate wouldn't require extra work to maintaint the method signature, and would have a very well-understood scope. I haven't done it, but I think the actual wrapper version of validate wouldn't be much more code, or much more difficult to read. It'll still mangle stack traces, though, which is a big deal to me. Also, decorators that perform real wrapping instantly become significantly more complex, as they have to make sure to migrate all of the function attributes from the old function to the newly wrapped function. Alberto particularly wanted to be able to supply his own validate in ToscaWidgets, and if there's signficant benifit in letting people tweek validate, it makes sense to decouple it from the controller so that people could much more reasonably do that. I can certainly understand that, but again, I think we can accomplish this without having to sacrifice the elegance of the current solution, or making the decorator more complex than it needs to be. I'd rather see us design @validate to be extensible by passing in callables. Just my two cents... -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: Fwd: [turbogears-commits] r4026 - trunk/tg
Mark Ramm wrote: What kind of errors were you getting when we didn't re-instantiate on each request? When making several requests in a very short period of time, we were having issues where one request's data would end up getting appended to the next request's data. In our case, this was resulting in corrupted JSON on some of our AJAX requests, and occasionally we'd see our entire app go haywire, and entire pages would show up with the *previous* request's page embedded within it. Nasty, nasty stuff :) Ben and I discussed this a bit, and it seems like Pylons is designed from the ground up to expect *fresh* controller instances on every request. I think this is a reasonable approach, that just happens to break down on object dispatch the way we've implemented it right now. I'd like to be able to keep the root controller object around, but I agree it's not worth it at this point. (However, if we're doing this, I'm tempted to go back to the *route way and just re-use the pylons app entirely). That way people with large projects could mitigate the impact of this by using routes to break up their object trees into much smaller entities. Sure, this is a totally valid way to go, and I don't really have an issue with it if we want to go this direction. That being said, I also think its possible for us to fix this problem by doing something like this: class RootController(tg.TurboGearsController): sub_one = tg.SubControllerProxy(MySubControllerOne) sub_two = tg.SubControllerProxy(MySubControllerTwo) The tg.SubControllerProxy could act as a proxy to the passed subcontroller class, only instantiating it if required by the request itself. This should be relatively easy to implement, and would act as a nice optimization for people who care about speed, without requiring people to understand Routes, or break their hierarchy up into a bunch of chunks. -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] quick note...
All, I just committed a quick change to TurboGears 2.0 that has an effect on the way you all probably expect your applications to work, but is an important bug fix: http://trac.turbogears.org/changeset/4025. The summary is this: Pylons expects all requests to occur in fresh controller instances, and `TurboGearsApplication` was keeping around a cached version of the root controller, and re-using it in order to not have to re-construct the entire object tree on every request. However, since Pylons expects fresh instances, this was causing response data to leak into subsequent responses. For the time being, I have updated TG2 to always return a freshly constructed instance of the root controller and use that to process requests. This introduces some overhead, but actually produces correctness, which is much more important at this stage in the game :) At some point, we should start considering how we can optimize this a bit, to prevent having to re-construct the entire tree on every request. -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: quick note...
Christoph Zwerschke wrote: One suggestions to those working on the trunk: Please add comments to the code explaining why you do such non-obvious things, so that other developers some months later don't start to cache controllers again, believing this is a good idea that nobody had so far. Great suggestion, Christoph. I know better than this, but was in a rush. I have added some comments to the relevant section of code to make sure that its absolutely clear why I am re-instantiating the controller. Thanks! -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: any chance mochikit gets replaced by ext.js?
Mark Ramm wrote: TurboGears2 itself will minimize depencecies, and there will be a seprate tg-dev package which will have a standard set of development tools that we recomend for use in TurboGears projects. We should document these extras as best we can. But quickstarted projects will not depend on them by default (though you are free to add them as dependencies inside your project when you use them. Great, I am glad we're on the same page. The discussion therefore is about what JavaScript libraries ought to be used in the extras packages. We will not enforce a hard and fast rule, but I'd like to propose that jquery be used whenever appropriate (it's small, fast, and well developed) and that ext.js be used wherever grids, trees, and other rich UI type widgets are needed. And that this be done in a way that makes it as easy as possible to use multiple extras together in one project without javascript namespace collisions. It sounds sort of good, and sort of not. I have heard issues with using both JQuery and ExtJS in the same app, and I am not too excited about having to explain to users two completely different JS frameworks on the mailing list. One thing that occurred to me is that it might be possible to create a really small version of ExtJS that includes only the basic AJAX stuff and maybe some utility functions (or even animation) using the ExtJS builder, and make that the core default. Then we can include the extra stuff only when needed. But, I think we're on a good path here... -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: [TurboGears] Re: any chance mochikit gets replaced by ext.js?
Mark Ramm wrote: I think we probably have 2 different use cases that need to be covered: snip, snip a bunch of insightful stuff... What do you all think? Honestly, I think MochiKit should go. But, I don't think that ExtJS should replace it. ExtJS is absolutely amazing, and I use it a lot, but its really huge. Absolutely massive, actually! I would actually push for us being JS framework agnostic in TurboGears 2.0, not including any framework at all, and encouraging people to use whichever framework they like. There's hardly any code crossover between TurboGears and the JavaScript library that won't be handled by ToscaWidgets at this point anyway. The only benefits to including a JavaScript library is to reduce the number of choices that someone needs to make to get rolling immediately, and to be able to produce a really cohesive set of documentation that covers the full-stack of writing web applications. The problem is that there really aren't any JavaScript libraries out there that will handle the majority of use cases. Some people just want a simple and fast loading framework that makes AJAX and fairly straightforward. Other people want to do animation and add lots of bling to their app. Still others will want rich widgets and form validation. So, I am +1 for removing MochiKit as a dependancy, and +1 on replacing it with a nice big empty hole for users to plug in on their own ;) For TG2 only, of course. -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: any chance mochikit gets replaced by ext.js?
Mark Ramm wrote: I would actually push for us being JS framework agnostic in TurboGears 2.0, not including any framework at all, and encouraging people to use whichever framework they like. Well, what do we do when we want to provide a large set of toscawidgets that work well together? Thats a toscawidgets problem, not a turbogears problem, IMO. I actually choose not to use toscawidgets at all (although its a very cool project), so I don't really care :) I'd really like to see TurboGears shrink down to the tiniest possible set of things in the *core*. This will make it easier to document, maintain, and keep current. I have no issue with additional eggs being available to install like: TurboGears-ExtJS TurboGears-ToscaWidgets TurboGears-JQuery ... and even having a TurboGears-Extras egg that installs all of this good stuff to make it easy for people. I just think that the *core* of TurboGears should have no JS library included. There's already a set of ext.js based set of toscawidgets, and we ought to encourage that as much as possible, because these things demo extraordinarily well in a screencast. And marketing does matter. But I agree that ext.js is just too big to be useful to everybody. Agreed on this point. I still think it belongs well outside of the core though. My biggest issue with TurboGears 1.0 is all of the poorly maintained cruft that got thrown in (CatWalk, Model Designer, Toolbox) that made for great screencasts, but was mostly useless in practice because it wasn't maintained, documented, or well supported. This is a lesson we should learn from, IMO. I am all about people making cool things on top of TurboGears, but they can do it in separate projects and separate eggs. We get all the benefits, with none of the baggage. Its a win-win in my mind. But I think if we developed a core with jquery and an extended set with ext.js we could reasonably cover the full set of widget use-cases, and we should encourage development of ToscaWidgets along those lines. However, I don't think we need to try to control things, and I'll be super happy as moo tools and other things get widgets that people can use. But we should not tie anything inside of the TG core to any javascript library beyond whatever is used in the default toscawidgets. This is my exact point. There are *so* many JS libraries out there, and there isn't really a clear winner. Each one has its strengths and weaknesses, and to really handle everyone's use case, we would have to bundle all of them. I'd prefer to just punt on the issue, and allow other people to create support for their pet library in a separate egg. We don't really need anything in the core, since the core of TurboGears has nothing to do with JavaScript. The extras have all sorts of nifty things they need to do with JavaScript, so they're a different story. ...right now we are mostly documentation writer constrained, and if that doesn't change I think we're better off not picking something than picking something and not documenting it :( 100% agree. I repeat: we need to learn from 1.0. We don't have the bodies to document ExtJS for sure. We might be able to document a smaller library like JQuery or Moo, but then we'd miss out on all the rich stuff that Dojo and ExtJS provide. TG itself need not pick a javascript library, but turbogears extension projects (like the admin interface generator DBMechanic or a user registration system, or the toolbox) may need to pick a library, and we should encourage these people to standardize on something so that an app which uses all of them doesn't depend on a dozen different javascript libraries. This is the first good argument I've heard. However, as I understand it, all of these things will be in the extras space, not a part of the core of TurboGears. I don't have a problem blessing a library for the development of tools for the TurboGears-extras egg, and I think ExtJS is a great choice for that, since its a very specific set of problems that are being solved. In summary, I favor: * The core of TurboGears having no JavaScript library dependency. * A TurboGears-extras egg that may bless a single JavaScript library. - DBMechanic can live here. - ToscaWidgets can live here. - Other JavaScript libraries as eggs can live here. -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: [WARN] Possible breaking changes [WAS] Re: TG2, session vars not working out of the box
Ian Bicking wrote: ... it doesn't seem like AuthKit is on track to becoming the canonical solution. There's just too much griping and misunderstanding around it. Of course, one option is to fix/improve AuthKit. I get the impression (I just have impressions of all this stuff, no experience) that the code is complex, and it doesn't feel like it has to be that complex. So it's not so much an issue of features as the code design. Revamping AuthKit may be just as much work as writing it from scratch, though it would have the benefit of creating less confusion going forward. FWIW, this is basically the same as my position. It just seems to me that authentication is a straightforward problem that requires a very small amount of code to solve, for most projects. Authorization, however, is a highly subjective problem, that has varied wildly in every project I have ever worked on, and is usually best solved mostly outside of any framework. Any authorization framework that tries to be general purpose enough to solve everyone's problems is going to end up being confusing, and difficult to use. A very simple system that requires the user to write a callable to validate permissions would be simple to implement, and would be easy to extend to handle any use case imaginable. I just want to see something that can be pointed to without any reservations, and currently when AuthKit comes up people often have reservations. Also a very good point. Something very simple with adequate hooks for extending outside of the framework would fit the bill, in my opinion. Off to the beach... -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: [WARN] Possible breaking changes [WAS] Re: TG2, session vars not working out of the box
Alberto Valverde wrote: I've used AuthKit a lot and authentication is the part I specially like about it. I haven't used it's authorization part so I can't really comment on it except from a brief overview of the documentation and I agree that it's API is not very friendly. I think it would be a terrible idea to rewrite all James' work from scratch to re-implement a watered-down version of what AuthKit, IMHO, does pretty well. I totally understand your argument, Alberto, and AuthKit certainly is _featureful_. I agree that we shouldn't re-implement AuthKit, and I am not arguing that we should prevent people from using it. I just think that AuthKit is a poor match for TurboGears, in that its fairly complex, and doesn't provide a really simple solution for the 95% use-case in a small amount of code. AuthKit would be a great option for someone who needs some of its more esoteric features, like HTTP basic and digest authentication. However, I suspect most TurboGears users will just want a simple form-based username/password authentication mechanism, and we can provide them something in less than 100 lines of code, rather than building in a fairly large dependency on a complex auth framework. Authentication is one of those things where its really convenient to keep it simple, so that users understand what's going on, and its easy to trace. Its not something like an ORM or a cacheing framework that requires a lot of complex internals. Its like 100 lines of really easy to understand code. Thats a lot nicer than a dependency, in my mind. Plus, authentication is the *easy* part. Authorization is the rough one, and I think AuthKit's API for that is really gross. That being said, its been a little while since I have played with AuthKit, and it may have improved immensely since then. I'll clean up my own code and post it, as promised, and let other people provide their own opinions. I can completely understand your point of view, and would like to hear some other opinions too. -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: [WARN] Possible breaking changes [WAS] Re: TG2, session vars not working out of the box
Ian Bicking wrote: Yeah, writing middleware with WebOb is much simpler in terms of code flow. Ben redid paste.errordocument that way and was happy with it (I'm not sure where the code landed, though). I haven't used AuthKit myself, and don't have a particularly strong opinion. Except that identifying a user has a pretty clear scope, but permissions are a bit harder. I can imagine loading the user data into, say, environ['webauth.user_info'] (a dictionary, with at least a few defined keys), and then permission checks are entirely separate code that raises HTTPForbidden (or HTTPAuthenticationRequired), maybe based on environ['webauth.user_info']['groups'], or... well, whatever. Writing permission-checking code should be very easy. FWIW, I'd be happy to polish up my code that I am using in my own TG 2 project, and contribute it as a starting point. It provides two things: 1. A simple WSGI middleware for authentication, which depends on beaker, and places a validation that the user is authenticated into the session. Right now, its directly tied to my SQLAlchemy/Elixir model, but it could easily be made more pluggable. 2. A base object-dispatching controller class called `SecuredController` that provides a class method called `validate_permissions` that you can override which returns `True` if the user has permissions to view this part of the subtree, and `False` if they do not. Its not much, but thats what I like about it. Keep it simple, and put the hooks in as code. -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: [WARN] Possible breaking changes [WAS] Re: TG2, session vars not working out of the box
iain duncan wrote:
You're using SA0.4 right? ( elixir based I assume ... )
Yep, right on both counts.
What about using SA;s Association Proxy on the identity handling
object to add permissions in a dead simple to use manner but clear
manner, ie something vaugely like:
if Identity.Role.get('admin') in Identity.user.groups:
Actually, I think we should keep any sort of model-related
code or expectations out of the authentication/authorization
framework entirely. In my mind, this is one of the worst things
about identity in TurboGears 1.0, is that it makes all sorts of
assumptions about your model objects, and their associated API.
I'd prefer it if the authentication mechanism was a user-supplied
callable, which would allow the user to perform their authentication
in any way that they like.
To keep the Hit-The-Ground-Running (HTGR) experience as positive
as possible, it might be wise to include a simple authentication
function in the generated code within the template. It could
include a simple `User` model, including encryption, in either
SQLAlchemy or Elixir depending on the template, and a super-simple
callable that performs authentication using the generated model.
People who wanted to swap it out for something different, could very
easily do so, without worrying about digging into the framework, or
working around it. This is a huge positive, in my opinion.
Could you post your code up somewhere Jonathan?
Sure. It currently has some very application-specific code within
it, but it would be trivial for me to perform a little refactoring
to make it more general purpose. It might be good enough as an
identity replacement once I make the changes.
I am currently on vacation, so will be spending lots of time on the
beach, but I might find some time to do this before I get back ;)
I'll let you (and the rest of the list) know as soon as I get this
done, and post it somewhere for people to review.
--
Jonathan LaCour
http://cleverdevil.org
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
TurboGears Trunk group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---
[tg-trunk] Re: [WARN] Possible breaking changes [WAS] Re: TG2, session vars not working out of the box
a customizable `validate_permissions` method. I am happy to share any code if you want to take a look. The entire code base for both of these tools is about 150 lines of code, making it extremely simple to understand, debug, and maintain. Also, its my opinion that identity was the weakest part of TurboGears 1.0, simply because it tried to do too much. I honestly think we'd be better off shipping something simple, that was under 200 lines of total code. This is just my opinion, and I'll be likely to continue using my middleware unless the new `identity` is a heck of a lot simpler than TG1's and isn't based upon AuthKit. Thanks for all your hard work Alberto! Its much appreciated. -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TG2, session vars not working out of the box
Alberto Valverde wrote: I'm just reading some discussion right now in pylons-devel regarding this same issue. They seem to be considering to lengthen those names to be more readable too. I saw that too. I think this can best be solved in Pylons. But, if they don't solve it, I don't think that should let us off the hook for making it clear for our users by adding in aliases where necessary. In my book, its a lot harder to understand what `pylons.c` is than to understand namespace aliasing. TG 1 never did it (eg: cherrypy.request) If it was called `cherrypy.r`, I'll bet you a dozen pints of beer we would have ;) I don't buy the its only a documentation issue point since the less documentation we need to write/maintain the better IMO. Better spend those energies in documenting what we actually need to document. A single paragraph of documentation is no hurdle. I'll volunteer to write it if we need it, although I am betting that Pylons changes to more logical variable names. So, my proposed plan for action is: a) Wait until Pylons makes the change (crossing fingers so they do ;) b) remove the current aliases so we don't encourage anyone to use them Sounds reasonable? -1 No, we don't even have an alpha release yet, and I actually have a product written in TurboGears 2.0 that has 'from tg import session, request, context' all over the place. I'd really personally appreciate it if we could leave the aliases in until we see what Pylons decides to do. I see no reason for my code to break over this issue. Single character variables names are totally unacceptable, and while I believe that Pylons will make the right choice in moving away from them, I firmly believe that if they make the *wrong* choice, we should correct it here. There is simply no harm in having the aliases there, and it actually hurts me to have the aliases removed. -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: Mako vs Genshi?
Kevin Horn wrote: I don't think TG was envisioned as the Framework for making fast apps. IMO it was designed to reduce grunt-work and repetitiveness for the developer. Let's stick to that philosophy. This 100% summarizes my opinion. Lets stick with the plan thats been in place for some time now, and focus on developer productivity, not shaving a few milliseconds off rendering our templates. -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TurboGears2 status update
Ian Bicking wrote: Personally, I think that the new `tg` package should import and alias `pylons.c` to something called `context` in order to be a little more explicit, and `pylons.g` should be aliased as well to something less confusing (although `global` is a keyword and `globals` is a built-in). app_globals? Good idea. I have done both of these in trunk, and also aliased request into the tg namespace. So, now you can do: from tg import expose, validate, request, context, app_globals from tg import TurboGearsApplication, TurboGearsController This should make things a bit simpler to use for turbogears users. -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: ORM Default: Elixir or Plain SA
Paul Johnston wrote: One decision we need to make for TG1.1 is whether the default ORM should be plain SA or Elixir. (I'm sure I don't need to explain what these are on this list!) This is your chance to have your voice heard so, speak up :-) Oh dear, lets keep it civil people! :) It's generally agreed that we should pick an option that is easy for beginners to grasp, and deals with 90% of use cases. Well, if those are really the concerns, then I would argue the following: * Plain SQLAlchemy is not easy for beginners to grasp, even with the wealth of documentation that it has. Its designed for people who are experienced with relational databases, and many beginners are not. * Elixir is only easier for beginners to grasp for the first week or so until they get to the point where they have to start consulting the SQLAlchemy documentation to learn how to perform complex queries. We aren't going to find something out there today that satisfies the stated goal of being easy for beginners *and* solving 90% of use cases, except for maybe SQLObject or Storm. I think thats just the current state of things. Elixir lets you define your model more concisely, and more in line with other ORMs like SQLObject. The big question is whether Elixir is actually simpler, or if it's just shorthand for people who already know SA. Elixir is SQLAlchemy. Thats the bottom line. In order to really use Elixir effectively, you are going to have to understand SQLAlchemy and its core concepts. What Elixir provides is an alternative syntax for defining your tables, objects, and mappers in one step. Once you have defined your model, the usage patterns are very similar, with the exception of Elixir's shortcut for getting a Query object: `MyEntity.query` rather than `session.query(MyEntity)`. There are also practical concerns, e.g. that Elixir classes cannot fully mix with plain SA classes, and that Elixir is not as well documented as SA. These are fixable; perhaps we should wait until they are fixed before making Elixir the default. This is a valid concern. Elixir is a younger project than SQLAlchemy, and thus its documentation is a bit behind. Having bi-directional integration with plain SQLAlchemy is definitely one of Elixir's goals, but we just haven't gotten there yet. Now, as for what the default should be in TurboGears 1.1 and 2.0. I am of the opinion that TurboGears has been moving away from being a beginner-driven framework for some time. Therefore, I don't think the original goal is a valid one any more. For people who want something super-easy to jump into that will solve the majority of their use cases without being complex, they should likely go with something like Django or Ruby on Rails, which are all about sacrifice and convention for the sake of development speed. TurboGears is about sane defaults that you can escape from, in my opinion. My recommendation would be that TurboGears 1.1 and 2.0's default templates generate a model.py that instantiates an SQLAlchemy session and metadata, and then provides two commented out sections that show you how to either get started with plain SQLAlchemy, or use the provided session and metadata to define your model with Elixir. The nice thing about an approach like this is that it doesn't really matter if the user is doing plain SA or Elixir, the framework knows about the metadata and session, and can use that knowledge to provide things like integrated automatic transactions. If people think that we absolutely must pick one default, then I'd say that going with plain SQLAlchemy would probably be the wiser decision at this point, simply because I think that there are more current TurboGears users using plain SQLAlchemy than Elixir. Either way, I think TurboGears 1.1 and 2.0 should allow users to make their own choice. -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[TurboGears] Re: jsonify and sqlalchemy support
Raphael Slinckx wrote: Now, with the upgrade the rule in turbojson is becoming ambiguous with the two previously mentioned rules, meaning i just can't customize sqlalchemy mapped object's jsonification, because either i add a __json__ and dispatch doesn't know whether to use __json__ or the builtin jsonify_saobject (AmbiguousMethod), or I add an explicit rule, but the same error appears. I have been having the same problem. I solved it by doing this before I defined my own custom jsonify rules: jsonify.clear() This will clear out all of the existing jsonification functions, and yours will take precedence. However, this isn't ideal. What we really need is a way to resolve the AmbiguousMethod issue by somehow making our constraints more specific. I don't know how to do that, however. -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Turbogears Backwards compatibility
Michel Albert wrote: Currently I am writing an application using TG 1.0 (don't have the minor version at hand right now). I started the application with TG 0.9 when everybody was still talking about SQLObject. As I read on a few places that SQLObject will be dropped in upcoming versions I decided to migrate to SA. And everything is fine. Now I read more and more about Elixir (I know I can still use plain old SA even with Elixir). If you are using SQLObject still, you will have no problem being supported in 1.0 or 1.1, which will have a long lifetime still. If you have already pulled the trigger to move to SQLAlchemy, thats fine too, as it is well supported by both TurboGears 1.0 and 1.1, and will be supported in 2.0. Elixir is simply another option for you, which will also be supported by all versions TurboGears that support SQLAlchemy, but you are not required to migrate to Elixir, as the default ORM in TurboGears 1.1+ will be plain SQLAlchemy. But there's also the Kid -- Genshi migration in the talks (if I'm not mistaken) and the abandonment of Identity. And then the next big thing: TG -- Pylons... or was it paste? I'm a bit confused with this. Okay, let me break this down for you: * Kid will still be supported, but Genshi will be the new default. Genshi is really easy to migrate to, as it is basically 90% the same as Kid, just faster, and with some cool new features. * Identity is still up in the air for 2.0, but as far as I know, it will be supported in 1.0 and 1.1 for a long, long time. You are safe here until you decide to move to TurboGears 2.0, which doesn't really have anything like Identity right now, and isn't even released in alpha form yet anyway. * TurboGears 2.0 is currently planned to be basically built on top of Pylons, which is another web framework. Paste is a WSGI toolkit that is used by Pylons under the hood, and you don't really need to worry about it right now. Its there, and it basically just works for what you need it to do. I hope I cleared some things up for you :) So my question is: How likely is it, that future versions of TG will break my current application? I rely strongly on Identity, and Kid. The odds are very low that your application will break in TurboGears 1.1. It is highly likely that TurboGears 2.0 will break your application, but the porting effort should be well-documented and maybe even partially automated once TurboGears 2.0 hits the streets, I would imagine. You should be fine for the foreseeable future, especially once TurboGears 1.1 comes out. I can see TurboGears 1.1 and 2.0 co-existing for several years before 2.0 takes over completely. You'll have plenty of time to migrate if you like. How backwards compatible will future version be? Can I still use Identity even with newer versions of TG? I suppose the move from Kid to Genshi should be smooth as genshi builds on top of Kid. Right? I think I answered these questions well enough above. At some point I would like to freeze my framework. I went through an awful cycle already that slowed development to a painful speed. Nothing stopping you from doing that today. Just because TurboGears is changing doesn't mean that you can't rely upon the older ORM and template engine. They are not being removed entirely, just won't be the defaults anymore in 1.1 or 2.0. Best of luck -- -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com 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 -~--~~~~--~~--~--~---
[TurboGears] Re: How to choose between Elixir and plain SQLAlchemy
Ben Sizer wrote: Unfortunately the naive approach seems to yield errors like AttributeError: type object 'User' has no attribute '_descriptor', where User is a plain SA class and I've referred to it with a 'belongs_to' relation from an Elixir class. There are no hits for this error on either this or the SQLElixir group. I'm sure someone's documented how I get around this, somewhere. I'm guessing '_descriptor' is part of the private interface that Elixir Entities have, but beyond that, I dunno. Gaetan just added a test to show what is currently possible, and a commented out test to show what we'd like to have working when we get a chance: http://elixir.ematia.de/trac/browser/elixir/trunk/tests/ test_sa_integeration.py?rev=241 Essentially, plain SQLAlchemy objects can refer to Elixir objects with no problem right now. You can't do the same in the other direction (yet) without workarounds. ... this sort of hints at all that is bad about Turbogears, in my (apparently minority) opinion. Everybody seems to think that it's great that all the parts are interchangeable. I totally understand what you are saying. You aren't really in the minority, as I think we've been migrating to new defaults for a looong time. There has also been a lot of debate about what the new defaults will be: CherryPy 3 or Paste, SQLAlchemy or Elixir, Genshi, etc. TurboGears is about having sane defaults though, meaning that if you don't know enough to make your own decisions, you can just let TurboGears choose for you. The main reason TurboGears makes it possible to swap things out so that the maintainers can make sure that the default is always the best-of-breed selection. If something better comes along, its possible for us to flip a switch. I also like that the parts are interchangable because sometimes the defaults don't make sense for a particular project. For example, sometimes Genshi is totally the wrong choice for an application, because it can be very slow when rendering very large and complex templates. In those cases, I like the fact that I can use Mako, for raw speed. This is just one example of why choice and flexibility are good. Of course, choice needs to be balanced with sane defaults, so that newbies can get rolling without having to make any decisions on their own :) Possibly the best thing for me to do at this stage is just strip out Identity and all the associated objects, and write all the login stuff myself with Elixir. I expect it'll be poor compared to using Identity or Authkit or whatever the authentication flavour of the month module is, but at least I won't be chasing round the web and mailing lists trying to find out how to get it to comply. Trust me, it won't take you a long time to build something like identity that meets your needs much better. Identity is easy to use, but kind of weird in its implementation, and too closely tied to your model. AuthKit is much better, but is really young, poorly documented, and difficult to use at this stage. So, I just created something that doesn't aim to be general purpose, but just meets my own needs in the project I am working on. It took about 2 days. That being said, if identity works for you, and you like it, go for it. Which example? I typed easy_install elixir, and got an .egg installed, and that's all I know. The 'examples' page on the Elixir Wiki is blank. You can find it in subversion by looking through the source, or you can take another look at the examples page on the wiki, which now links directly into the example :) Well, it doesn't work yet, that's the thing. I have a model.py that doesn't work due to the exception I noted earlier, and I can't go much further until I know what I'm supposed to do to make it work. I asked how to mix the 2 models and maybe when someone has an answer for me, I can proceed. Or maybe I'll just have to remove the plain SA stuff. I don't know. Ask on the Elixir list (again if you already have), you'll get a much better response I think. All I know at this stage is that it gets really demoralising to spend 20 minutes coding and then hours waiting for support, but that's been my Turbogears experience from day one. I apologise for the frustrated tone! It is just difficult when the language and tools become the barrier rather than the solution. I totally understand. If documentation and a large, responsive user base are extremely important to you, then TurboGears may actually not be the right choice for you. That might change in the future, of course, if more people get involved and help improve the current situation. -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group
[TurboGears] Re: How to choose between Elixir and plain SQLAlchemy
something that works for you today, and you like it, stick with it. If you encounter problems down the road, let us know on the Elixir list, and we'll do our best to fix the problems or add the features you request. Some really cool stuff has been put into Elixir because users have given us great ideas. If you have questions, ask them on the list as well, and we'll do our best to answer them, and put the answers in the documentation. It may be that I'm worrying for nothing and that changing from one to the other later is simple, but then that would be useful information to have as well. Hopefully there are answers to this and the other questions. Personally, I think you are worrying for nothing. TurboGears doesn't tell you *not* to use Elixir, it just doesn't use it as the default for a variety of reasons. But, in the end, Elixir is just SQLAlchemy under the covers, and you can always drop down to the raw table objects if you need to. Good luck! I am hoping to have more inquisitive users like you pick up Elixir, in the hopes that we can really improve due to your feedback and contributions! -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Updated SQLAlchemy documentation
Ben Sizer wrote: Please move this discussion to the elixir mailing list, if you don't mind, as it doesn't really have anything to do with TurboGears :) I understand why you said that, but really this just came off the back of the TG stuff. I'm firmly of the belief that the TurboGears project can't just abdicate all documentation responsibility for their default model system to the Elixir project... I agree, however, Elixir won't be the default for TurboGears 1.1 or 2.0. Plain SQLAlchemy will be, and I think thats the right choice. Elixir will of course be supported, since its basically just SQLAlchemy under the hood, and I'll likely provide some templates or docs on the Elixir wiki for using Elixir in Pylons, TurboGears 2.0, etc. As one of the Elixir authors, I can gladly admit that Elixir won't always be the right choice for every project out there, and that we currently have some warts, especially when it comes to documentation. Elixir will continue to get better, but its not designed to solve every single case and design decision like plain SQLAlchemy is. I also suspect that a large number of users will elect to utilize Elixir, even though it isn't going to be the default, since it will be a good choice for a large number of projects that are comfortable with Elixir's limitations. Thanks for the feedback! I'd love it if we had more smart folks like yourself contributing to the documentation for elixir via the wiki we have set up, as it will help us improve the weakest part of our project! -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Updated SQLAlchemy documentation
Ben Sizer wrote: Actually, I quite like the Elixir API docs, having had a chance to read through them. It's just that you have to dig 3 or 4 pages deep from the index before you see details on mapping your objects, etc. If there can just be some enhanced visibility of these pages, it might be enough. Agreed, to a point. I think that API docs should be like this: nested. We really just need additional higher-level docs and improved tutorials that will give users an idea of how to get started, and then they can use the API docs more as a reference, rather than as the only way to figure out how to get things done :) Just a suggestion though: I think there's a slight overreliance on referring to other technology, like model objects following the Active Record design pattern, and using a DSL syntax. It's speaking to experts rather than beginners. I think that these terms will mean nothing to many people who are just getting started and may make them think that using Elixir is a complicated and jargon-filled task, when in fact it's very simple. And it tells you what it is, as opposed to what it does. Agreed, again. Please move this discussion to the elixir mailing list, if you don't mind, as it doesn't really have anything to do with TurboGears :) Thanks! -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Elixir: No auto-commit
Florent Aide wrote: This coupling with ActiveMapper was one of the gripes I had with the 1.0 database layer of TurboGears, it made things difficult to evolve. Agreed, even as the person who made ActiveMapper! The problem isn't so much that ActiveMapper support was there, it was that the particular method of building SQLAlchemy / ActiveMapper support into TurboGears was fragile, and part of the core, which should stay as simple and stable as possible. You can't have flexible and stable core if you hardcode database support into the core in a *very* specific way. Which brings me to my next point... For stability and evolutivity reasons I would prefer to not include extensions like this one (Elixir) in the core of the TG database layer. I am really happy that a simple line in the model.py file will make things work. I had a discussion with Mark yesterday about this, and I actually recommended that in the future, starting with TurboGears 2.0, that *no* database integration would exist inside the *core* of TurboGears itself. I have been using Pylons (via TurboGears 2.0) a lot lately, and have come to truly appreciate their approach to database integration, where none is included, but they provide nice tutorials on how to integrate your favorite database package. I think TurboGears should go a step further by providing SQLAlchemy and Elixir (and even SQLObject for backwards compatibility purposes) support eggs available. The SQLAlchemy support egg should probably be installed with the base TurboGears package, while the Elixir one should only be installed if you explicitly ask for it, or if you install the TurboGears-Extras metapackage. I don't want people to get the impression that I am encouraging them to not use Elixir though, as I think its really beginning to come into its own, and is a lot of fun to use! I just want TurboGears to become a leaner project, that is easier to maintain in the future, and bursting these things out into separate eggs will make life a lot easier. -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Elixir/SA Object JSON Fix
jfr jr wrote:
I am not sure this is the best way to fix my issue with serializing
elixir objects as JSON but it appears to be working. Any input or
comments??
Wouldn't it be easier just to simply take advantage of the TurboJSON
jsonify generic function? In your json.py module in your project:
from turbojson.jsonify import jsonify
from elixir import Entity
@jsonify.when('isinstance(obj, Entity)')
def jsonify_entity(obj):
result = {}
for name in obj.c.keys():
result[name] = getattr(obj, name)
return result
Thats what TurboJSON is there for :)
--
Jonathan LaCour
http://cleverdevil.org
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
TurboGears group.
To post to this group, send email to turbogears@googlegroups.com
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
-~--~~~~--~~--~--~---
[TurboGears] Re: How will Turbogears improve Pylons?
walterbyrd wrote: I wonder if the development of TurboGears will reach the point where they don't swap out components as frequently? TurboGears started as a set of best of breed tools. It stagnated a bit and now we're returning to that original vision. You'll still be able to use the previous tools (SQLObject, Kid), but now that there are better tools out there, it makes sense to make the switch (SQLAlchemy, Genshi). Writing great software is often not about preventing change, its about embracing it! -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Moving to tg2?
Roger Demetrescu wrote: Why will TG2 instantiate controllers on each request ? What are the pros and cons of the actual model of TG 1 (one instance of each controller in the entire lifetime of the application process) ? Well, the short answer is because that is how Pylons controllers work and TurboGears 2.0 controllers are Pylons controllers now. The long answer gets into how Pylons is implemented to take advantage of WSGI, and would be a much longer email :) The difference is very minor, as long as you make sure that you aren't doing any sort of expensive initialization at controller instantiation time, and store any global state somewhere other than controller classes. -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com 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 -~--~~~~--~~--~--~---
[tg-trunk] Re: 1.0.3 is coming
Florent Aide wrote: A special thought goes out to Jonathan Lacour, who will be happy to know ticket 1090 is now closed! You are my personal hero! -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TurboGears 2 sample app()s
Christoph Zwerschke wrote: I'm looking for a couple of open source applications that we can port to TurboGears 2. WhatWhat and Docudo are good candidates... I am knee deep in other work right now, but I would be more than happy to provide help on getting WhatWhat ported over to TurboGears 2.0, with Genshi, SQLAlchemy, and AuthKit. Having a real world application out there for the framework is an excellent resource. -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: Toolbox on TG2
Mark Ramm wrote: Should we make the TurboGears 2 toolbox a separate project itself? We can ship with it but keep it outside the core. I have always found the toolbox to be more of a neat toy than something very useful. In addition, I don't like the fact that it installs with my production applications, since I really don't want something like CatWalk available from my production application. Personally, I think ToolBox 2 should start off as a separate project that TurboGears 2.0 does *not* include as a dependancy. To me, its not much to ask people who want to use it to type a single easy_install command. At the very least, it should be part of a extras TurboGears distribution so that you can install in production without including the toolbox. Just my two cents -- -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: SQLAlchemy or Elixir, which should be the default quickstart template in 1.1 and 2.0?
Christopher Arndt wrote: Oops I crossed my words, I though assign_mapper and wrote active_mapper sorry :) What do people mean when they say plain SA? With or without assign mapper? Are there really people that like to manage session contexts on their own? ;-) Or does plain SA even mean using only the database abstraction features of SA? I have seen Mike Bayer talk a lot about getting rid of or changing the meaning of assign_mapper at some point down the road, so I have switched to this instead in my plain SQLAlchemy projects: from sqlalchemy import MetaData, create_session from sqlalchemy.ext.sessioncontext import SessionContext from sqlalchemy.orm.mapper import global_extensions # create a session context and add the mapper extension globally # so I don't have to use assign_mapper anymore context = SessionContext(create_session) global_extensions.append(context.mapper_extension) # a base class for all my model objects that gives me a `query` # attribute that I can use to get a Query() object on the class class ModelBase(object): class __metaclass__(type): @property def query(cls): return Query(cls) def __init__(self, **kwargs): for key, value in kwargs.items(): setattr(self, key, value) This way, I get the benefits of the session context mapper extension, and my base class for my model objects gives me a `query` property which gives me my convenience methods: customer = Customer.query.get(1) customers = Customer.query.select() ... etc. -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TG2 progress and bugs
[EMAIL PROTECTED] wrote: 2. pylons 'c', 'g' params need to be returned implicitly (return dict(c=c, g=g)) Yes, we decided to explicitly filter these out, because they were causing big problems with JSON serialization. Explicit is better than implicit in this case :) 3. need implement tg_flash Indeed! 4. model related support are vague We're working this out still, because Pylons is also a bit in flux on how to properly do this. I am in the midst of looking into ripping the Zope transaction manager out into a separate package that we can use to make some things simpler, and I should have news on that by the middle of next week if all goes as planned. -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: API generation is ready for tg2
Noah Gift wrote: The generated docs look gorgeous, and it would be nice if we could fit into the general look and feel of the Python standard library documentation. That does look good...what tool did he use to do that? From what I can tell, its a tool of his own creation. I might send him and email and find out if I can get access to the code somehow, and if it might be usable for TurboGears. In my opinion, Python is really lacking a good documentation system, and Georg's work looks like it might be the thing to solve that problem. If we can find a way to use it, maybe we can blaze a trail for other projects. -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: API generation is ready for tg2
[EMAIL PROTECTED] wrote: I made a doc/ folder on tg2/ to handle the API generation stuff, and make some modification on module doc strings. Cool, this is a good start, but epydoc produces some narsty looking docs. I wonder if we might be able to take advantage of Georg Brandl's work on enhancing the Python standard library documentation: http://mail.python.org/pipermail/python-dev/2007-May/073232.html The generated docs look gorgeous, and it would be nice if we could fit into the general look and feel of the Python standard library documentation. -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: New tenant at http://svn.turbogears.org/trunk
M.Gehling wrote: in INSTALL.txt and setup.py you write, that tg2 need pylons 0.9.5. Does this mean, i need the svn-version from pylons ? Yes, we actually require the current svn version, as we had to fix a bug in the Buffet template API handling in Pylons. -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[TurboGears] Re: Post about TG
Sylvain Hellegouarch wrote: Indeed and I was very happy to learn about the integration but I found that a bit randomly, it's too bad that there hasn't been a clearer and wider announcement about it. It's really hard to understand where the project stands currently :( Yes, we didn't really do a very good job of publicizing the sprint this past weekend, or explaining what it was about. This is largely because it was designed as an experiment to see if it would be possible to write TurboGears 2.0 on top of Pylons, and was put together so quickly. TurboGears on top of Pylons is appealing for a lot of the reasons given in the original message. TurboGears and Pylons are extremely similar projects with extremely similar goals, and it makes little sense to me for both of them to duplicate so much effort. For a while, TurboGears was moving at breakneck speed from both a development and a marketing perspective, but the project has slowed down quite a bit in both aspects. I think this has a lot to do with the weight of so much code on the shoulders of very few people, a lot of which doesn't really belong in the core of a web framework. If we reduce this burden by taking advantage of what is available elsewhere, we can focus on keeping the core small, and encouraging people to build on top of it with separate projects that can take advantage of all the WSGI-goodness that we will have access to. As for where the project is headed, who knows? The experiment this past weekend was a resounding success in the eyes of all that were present, but there is still a lot to do. A frank discussion about how to move forward is probably in order, and I think that will happen very soon. -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com 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 -~--~~~~--~~--~--~---
[tg-trunk] Re: tg_format usage question
Elvelind Grandin wrote: How do you plan to implement this. have a filter/tool that strips of the extension before the cp dispatching is done? We aren't using CherryPy in the current TurboGears 2.0 code. We implemented a custom Pylons controller that provides CherryPy-like object dispatch, plus some other goodies. It will be relatively easy to modify the controller we have written to implement the extension stripping for content negotiation. -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: tg_format usage question
Jorge Vargas wrote:
that seems nice. It will be interesting I'll like to see how this will
be configure, to handle the multiple templating engines for the
different file types.
It will basically work like this:
class PersonController(TurboGearsController):
@expose('json', content_type='application/json')
@expose('templates.person', content_type='text/html')
def person(self, id):
person = Person.get(id)
return dict(
name=person.name,
age=person.age,
address=person.address
)
Now, when you want to fetch an HTML representation of the person with ID
number 1, you could do it in two ways:
1. Fetch '/person/1' passing the 'Accept: text/html' HTTP header.
2. Fetch '/person/1.html'
If you want to fetch a JSON representation of the person with ID number
1, you could do it in two ways as well:
1. Fetch '/person/1' passing the 'Accept: application/json' HTTP
header.
2. Fetch '/person/1.json'
This way, you can do content-negotiation the right way if you have
the ability to send HTTP headers, but can still link to a particular
representation when needed.
In the case of @expose('json'), we default content_type to
'application/json', and in the case of @expose('template...'), we
default the content_type to 'text/html' for convenience.
--
Jonathan LaCour
http://cleverdevil.org
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
TurboGears Trunk group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---
[TurboGears] Re: Having trouble with SQLAlchemy and Left Joins
AZMel wrote: By doing a fetchAll() I am able to pass the results to my List template and paginate works as it should. Sure, that'll make it work (as in not break), but its not giving you any of the benefits of the actual paging. You are essentially fetching the entire result set (which could be hundreds or thousands of rows) into a list, and then the pagination is just slicing the already populated list. If you are doing this, you might as well not paginate at all! -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Safari and JSON
velotron wrote: I've been having some troubles with Safari 3.0 and JSON output on TurboGears 1.0.2.2. I'm using loadJSONDoc to call a controller which returns JSON. It works fine in other browsers, but in Safari causes a 500 error with the same exception as reported in another thread Mark Ramm and I debugged this issue a few weeks ago, and produced a patch to fix it, but I am not sure where the patch is or if its been checked into SVN yet. I know Mark is away right now, but when he gets back, maybe he can comment on where the patch is :) -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Having trouble with SQLAlchemy and Left Joins
AZMel wrote:
results = select(
[
SubDivision.c.Subdivision_id,
SubDivision.c.Name,
SubDivision.c.DisplayOrder,
Division.c.Division_id,
Division.c.Name
],
SubDivision.c.Division_id==Division.c.Division_id
).execute()
Yup Jonathan, that does work. Is there a way to pull the rows so that
it is directly passable to the templates or would I have to build a
function that would do that?
I am not sure I understand your question. You can do this select in
your
controller, or in another module, and just pass the results into your
template. Once they are in your template, you can loop through them and
display the results however you like:
table
tr py:for=result in results
td${result[1]}/td !-- subdivision name --
td${result[4]}/td !-- division name --
/tr
/table
I hope this helps.
--
Jonathan LaCour
http://cleverdevil.org
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
TurboGears group.
To post to this group, send email to turbogears@googlegroups.com
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
-~--~~~~--~~--~--~---
[TurboGears] Re: Having trouble with SQLAlchemy and Left Joins
AZMel wrote: If I pass the results object to my template then the paginate fails: File /usr/lib/python2.4/site-packages/TurboGears-1.0.2.2-py2.4.egg/ turbogears/paginate.py, line 89, in decorated raise 'Variable is not a list or SelectResults' Variable is not a list or SelectResults Unfortunately, I think that the SelectResults extension only works on query objects, and not arbitrary selects like I instructed you to use. So you are going to have to build a query object to do what you want, which is to fetch two different mapped objects in one query. The SQLAlchemy documentation provides some insight on how to do this (rather advanced) operation in its section on advanced data mapping: http://www.sqlalchemy.org/docs/ documentation.html#advdatamapping_resultset Personally, I have found limit/offset paging to work very poorly on large data sets, especially with high offsets. The problems with it are worsened if you use MySQL, which has a foolish implementation of offset where all records are pulled into memory, and then irrelevant ones are just thrown away. Good luck. -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Having trouble with SQLAlchemy and Left Joins
AZMel wrote:
Ok I'm beginning to understand the SQL Model now and I am able to run
a query using
records =
SubDivision.query().join('divisionJoin').select()
[snip, snip...]
Why does it not return the fields in Division?
You are performing a query against a mapped object, which will always
return a list of instances that match your query constraints. If you
want to get back a list of *fields* from multiple different entities,
you are going to want to perform a more low-level operation that will
explicitly request back the fields that you care about, like so:
from sqlalchemy import select
results = select(
[
SubDivision.c.Subdivision_id,
SubDivision.c.Name,
SubDivision.c.DisplayOrder,
Division.c.Division_id,
Division.c.Name
],
SubDivision.c.Division_id==Division.c.Division_id
).execute()
for result in results:
print result
I hope this helps you out!
--
Jonathan LaCour
http://cleverdevil.org
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
TurboGears group.
To post to this group, send email to turbogears@googlegroups.com
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
-~--~~~~--~~--~--~---
[TurboGears] Re: genshi traceback problem even on sample project
Noah Gift wrote:
UndefinedError: logging_in not defined
I think it might have to do with the version of genshi, as other
people I work with were using an older version of genshi, I think 3?
I just bought a new laptop and did a new easy_install and I think I
grabbed a newer version from easy_install that broke things.
I also had this problem recently, and it turns out that the issue has
something to do with the way that newer versions of genshi look for
template variables. In this particular case, the logging_in variable
doesn't exist in the template (meaning it is not being passed into the
template at all). Older versions of genshi ignored this problem and
would
just return None (I think) when you accessed an undefined variable.
You can fix this and stay with the latest and greatest version of genshi
by changing your master template to check to see if the variable is
actually
defined, before accessing it:
div py:if=tg.config('identity.on',False)
and not locals().get('logging_in', False)
This should solve your problem!
--
Jonathan LaCour
http://cleverdevil.org
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
TurboGears group.
To post to this group, send email to turbogears@googlegroups.com
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
-~--~~~~--~~--~--~---
[TurboGears] Re: Who's coming to PyCon?
Kevin Horn wrote: PyCon activities start tomorrow here in Dallas, and I was just wondering who from this list is planning on being there? Will you be attending just the conference? Tutorial day? Sprints? I will be attending, along with several co-workers. I am speaking on my TurboGears application, WhatWhat Status (http://cleverdevil.org/ whatwhat), which is featured in the TurboGears book. I will not be attending the sprints or tutorials, but am definitely planning on spending some time hacking some beers in the hotel bar, and would be happy to lead any beer-related sprints ;) Anyone who wants to meet, feel free to email me. -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com 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 -~--~~~~--~~--~--~---
[TurboGears] Re: TGWebServices without TG?
Arnar Birgisson wrote: I know this sounds backwards, but can I use TGWebservices without turbogears? In particular can I plug TGWebservices controllers into my cherrypy-only project and expect it to work without pulling in the whole turbogears stack? You might want to take a look at the recently open sourced soaplib from my employer. It works great, and is designed to be deployed as a WSGI application under any WSGI compliant server, including CherryPy. You can find soaplib here: http://trac.optio.webfactional.com/ ...and it can be installed using easy_install. Best of luck with SOAP :) -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com 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 -~--~~~~--~~--~--~---
[TurboGears] Re: TGWebServices without TG?
Bob Ippolito wrote: I did look at soaplib. The API for writing clients is really bad, and on top of that I couldn't get it to talk to the service in question. I am not *too* surprised that you got this feeling. Soaplib was originally written for creating the server side of web services, so its server support is definitely more comfortable and clean that the client side. That being said, if you could submit a bug to the Trac site explaining your problem, it would really help us improve Soaplib. Its easy to point out that something doesn't work for you, but it doesn't really help us make it better :) Also, the client-side should get better when the experimental wsdl2python in the subversion repository gets better. When this is done, you should be able to transparently supply the WSDL of a SOAP service to a client object, and it should be able to dynamically discover all of the types and methods of the service, making life a lot easier. The API for writing servers looked fine I guess, but I'm not in a position to where I'd ever have or want to create a SOAP service. Totally fair. We only do it because we have to, and I personally would never write a SOAP service for my own use or in my own products. Its a legacy system, as far as I am concerned. The primary author of soaplib is extremely interested in working with Kevin to make soaplib more of a generalized web service library for creating and deploying SOAP and RESTian web services with JSON or XML (or whatever). We'll probably be having a conversation at PyCon with Kevin about this. elementsoap worked great, eventually, but it doesn't really do anything for you beyond shorthand for creating the request documents which is probably why it worked. Its totally inadequate for our needs, but it is certainly one of the better SOAP libraries out there. Python is perfectly suited for web services, and I think TGWebServices and soaplib both make it a lot easier. When (and if) the authors start working together, I think some great things could be produced. -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com 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 -~--~~~~--~~--~--~---
[TurboGears] Announcing Elixir!
Today, we are pleased to announce the release of Elixir (http://elixir.ematia.de), a declarative mapper for SQLAlchemy. Elixir is the successor to ActiveMapper and TurboEntity, and is a collaboration between Daniel Haus, Jonathan LaCour and Gaëtan de Menten. Elixir's website provides installation instructions, a tutorial, extensive documentation, and more. The eventual goal of Elixir is to become an official SQLAlchemy extension after some time soliciting feedback, bug reports, and testing from users. Daniel Haus http://www.danielhaus.de Gaëtan de Menten http://openhex.com Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Announcing Elixir!
iain duncan wrote: Congrats! That was fast. =) I look forward to trying it out. Do you have a mailing list or something for feedback and bug reports etc? http://groups.google.com/group/sqlelixir/topics There is a sample TurboGears application available in the SVN repository for those who want something just to look at and try. -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com 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 -~--~~~~--~~--~--~---
[TurboGears] Re: TurboEntity - ActiveMapper status?
Robin Haswell wrote: Seriously though, is it feasible for people in California to just fly to DC and attend? What does a cross-country airfare cost you guys? How long does it take? We don't have a real domestic air service here which means people in the north of England on a lower/middle-class salary can find it difficult even to attend conferences in London. PyCon is in Dallas, TX this year (as it was last year). So, its not a cross-country trip for anyone in the US. Flights from any major city to Dallas around the time of the conference ranges between $150-$400 round trip. The flight from either side of the country is no longer than 4 hours, I don't think, which is pretty short! I am not a very big fan of Dallas, or of the conference venue, but you cannot argue that its a very central place to host the conference so that it is accessible to people coming from either coast. -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Activemapper strikes again... import troubles.
percious wrote: So, unless someone has a better way to fix this problem, I propose the solution is to re-write all of the identity classes without activemapper, hence aleviating my problem. It is extremely straightforward to define your own plain SQLAlchemy model objects for the identity classes in your model.py. This should solve your problem rather quickly. -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com 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 -~--~~~~--~~--~--~---
[TurboGears] Re: TurboEntity - ActiveMapper status?
iain duncan wrote: Not meaning to pester, but I was wondering what the status is on the possible merged superMapperEntity thingy. I ask only because if it is thought that a beta of the collaboration might come out some time in the next six months or whatever, then I don't think I'll spend any time looking at the either of them by themselves, but will stick with plain SA or assign_mapper for the time being. Thanks to all the developers of both for the work! We are getting closer every day. We don't want to make the same mistakes we all made last time, releasing before there were enough tests, documentation, etc. We already have a library that is working quite well, and uses a DSL-like syntax for defining model objects and relationships. We have a small test suite, and fairly well documented code, but still have a few decisions to make, a bunch more tests to write, and documentation to attend to. I would say that we will definitely be ready before 6 months, and hopefully much sooner than that. I won't make any further commitment than that, because I don't want to make any promises I can't keep. But, suffice it to say that things are coming along quite nicely. Thanks for the interest. When we have an initial beta ready, we will definitely email the TurboGears list to let everyone know. Best - -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com 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 -~--~~~~--~~--~--~---
[TurboGears] Re: TurboEntity - ActiveMapper status?
Karl Guertin wrote: Thanks for the interest. When we have an initial beta ready, we will definitely email the TurboGears list to let everyone know. You know you want it done by the end of Feb so you can show off at PyCon. ;] I have to worry about finishing my slides and presentation first :) Seriously though, anyone who wants a sneak peek, just come and find me at PyCon, and I'll show you what we have so far. -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Brief Book Review
Chris Cioffi wrote: 1. Application specific widgets. For instance, if I've got a type of record that I need to display on lots of templates, what's the best way to proceed? Should I create a widget's package and include the widgets like I do forms? Or should I use ?python ...? and directly import the widget? The section on WhatWhat Status should cover this fairly well. WhatWhat uses widgets extensively, and they are pretty much *all* specific to the application. Widgets help make things like AJAX really really simple to do, and can help you minimize duplication. -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com 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 -~--~~~~--~~--~--~---
[TurboGears] TurboGears at PyCon 2007
Just to let everyone here know, my talk Creating the WhatWhat Project with TurboGears has been approved as one of the talks for PyCon 2007! I am looking forward to presenting how TurboGears made creating a full web application with fancy AJAX support easy. Suggestions on the presentation are quite welcome. Are there any other TurboGears talks that were accepted? -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com 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 -~--~~~~--~~--~--~---
[TurboGears] multiple date picker widgets?
I swear I have done this before, but its not working for me now. How
do I display multiple date picker widgets on the same page with totally
different field ids? I have tried this:
In my controller:
@expose(...)
def action(self, ...):
...
return dict(
date_picker=CalendarDatePicker()
)
In my template:
ul
li py:for=item in items
${date_picker.display(field_id='picker_%s' % item.id)}
/li
/ul
... but I still get the same id on every single widget. What am I
doing wrong?
--
Jonathan LaCour
http://cleverdevil.org
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
TurboGears group.
To post to this group, send email to turbogears@googlegroups.com
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
-~--~~~~--~~--~--~---
