Re: [tg-trunk] Another problem with tests in TG 2.3
That's what the other tests you found broken were supposed to prevent On Jun 18, 2013 2:36 PM, Christoph Zwerschke c...@online.de wrote: I found another problem when running tests for a quickstarted project with SQLAlchemy: The test application is only loaded in TestController.setUp() which is only run when the test methods in tests/functional run. When you run only the tests in tests/model, then the application is not loaded, the config is empty and setup_db will throw an error. I guess this problem has not been noticed in TG 2.2 because when you run the complete test suite, tests/functional runs before tests/model, so everything is fine, and additionally the nose plugin that was included in Pylons made sure that the configuration was loaded before running the tests. Since we do not use that plugin any more in TG 2.3, we should be more careful about the proper setup. I'll refactor the test templates a bit today to make the setup process cleaner. -- Christoph -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To unsubscribe from this group and stop receiving emails from it, send an email to turbogears-trunk+unsubscribe@**googlegroups.comturbogears-trunk%2bunsubscr...@googlegroups.com . To post to this group, send email to turbogears-trunk@googlegroups.**comturbogears-trunk@googlegroups.com . Visit this group at http://groups.google.com/**group/turbogears-trunkhttp://groups.google.com/group/turbogears-trunk . For more options, visit https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out . -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To unsubscribe from this group and stop receiving emails from it, send an email to turbogears-trunk+unsubscr...@googlegroups.com. To post to this group, send email to turbogears-trunk@googlegroups.com. Visit this group at http://groups.google.com/group/turbogears-trunk. For more options, visit https://groups.google.com/groups/opt_out.
Re: [tg-trunk] Tests for tg2devtools
So yea, coming back from the death here :) That code actually does two things. a) It automates starting a project and makes sure that is possible. b) It then runs a generate and then runs the tests of the generated project to make sure it's tests are properly run. So it's a test of both the generator and the generated project. To validate that changes to the templates don't break quickstart which will be very bad. On Mon, Jun 17, 2013 at 12:47 PM, Alessandro Molina alessandro.mol...@gmail.com wrote: I never noticed tg.devtools had a testsuite, as it is does it actually make any sense? As It runs a subset of the tests available in the testsuite of the generated package, can't we just run the testsuite of the generated app? On Mon, Jun 17, 2013 at 6:32 PM, Christoph Zwerschke c...@online.dewrote: In devtools.test there is a test_pastetemplate which is broken in 2.3 because devtools.pastetemplate does not exist any more. Are there plans to add tests to devtools again before 2.3 is out? -- Christoph -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To unsubscribe from this group and stop receiving emails from it, send an email to turbogears-trunk+unsubscribe@**googlegroups.comturbogears-trunk%2bunsubscr...@googlegroups.com . To post to this group, send email to turbogears-trunk@googlegroups.**comturbogears-trunk@googlegroups.com . Visit this group at http://groups.google.com/**group/turbogears-trunkhttp://groups.google.com/group/turbogears-trunk . For more options, visit https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out . -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To unsubscribe from this group and stop receiving emails from it, send an email to turbogears-trunk+unsubscr...@googlegroups.com. To post to this group, send email to turbogears-trunk@googlegroups.com. Visit this group at http://groups.google.com/group/turbogears-trunk. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To unsubscribe from this group and stop receiving emails from it, send an email to turbogears-trunk+unsubscr...@googlegroups.com. To post to this group, send email to turbogears-trunk@googlegroups.com. Visit this group at http://groups.google.com/group/turbogears-trunk. For more options, visit https://groups.google.com/groups/opt_out.
Re: [tg-trunk] Offline For Unknown Time
That's great news. Good to know ;) On Sun, Aug 28, 2011 at 10:23 PM, Michael Pedersen m.peder...@icelus.org wrote: I almost hate to make this post, since it seems like I'm begging for trouble, but... Things look done here. We lost power for nearly 8 hours. I had to run the generator so our sump pump would work, and that was the extent of it all. I have no property damage, no fallen branches, just a (much shorter than expected) power outage. I'm certainly not going to complain. On Sun, Aug 28, 2011 at 4:39 AM, Christoph Zwerschke c...@online.de wrote: Good luck to you and all the others out there. -- Christoph -- 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. -- Michael J. Pedersen My IM IDs: Jabber/peder...@icelus.tzo.com, AIM/pedermj022171 Yahoo/pedermj2002, MSN/pedermj022...@hotmail.com My LinkedIn Profile: http://www.linkedin.com/in/michaeljpedersen Twitter: pedersentg -- 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. -- 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.
Re: [tg-trunk] MongoDB / Ming backend and authentication support for quickstart
Well I was just looking at it and it looks pretty good. I couldn't find
anywhere to improve it.
The only tiny thing I noticed is that the from {{package}} import model
line could be used only once as it's the same for both options, but that's
nicpicking
http://sourceforge.net/p/turbogears2/tg2devtools/ci/1c62ad678c5dbfff6be2f2f0d286738f2da67bb2/tree/devtools/templates/turbogears/+package+/controllers/root.py_tmpl?diff=a55f6371a6c097c4c9b21f2c46720c08cd2991c4
On Tue, Aug 9, 2011 at 11:42 PM, Michael Pedersen m.peder...@icelus.orgwrote:
I've not reviewed the code, so this is a qualified I love it. This was
something that I was going to be looking to work for sometime soon. I'm glad
you got to it. After we've got 2.1.2 out the door, I'll take the time to do
a proper review.
On Tue, Aug 9, 2011 at 7:19 PM, Alessandro Molina
alessandro.mol...@gmail.com wrote:
This is something that I always wanted to do but as it was quite long
is something that I always postponed.
Yesterday I decided that even starting with something not really
perfect would have been an improvement over nothing and so I started
writing the necessary code.
To support this I created the ming branch on both tg.devtools and
tg.core repositories.
Currently I have pushed a version that seems to work with support for
authentication, users and groups.
Also predicates seem to work correctly for them.
What do you guys think?
Any review and help is really appreciated as the code is still in
experimental status and needs some clean up.
Also it is still missing ensure_index and permissions support.
Involved changes are:
devtools -
https://sourceforge.net/p/turbogears2/tg2devtools/ci/1c62ad678c5dbfff6be2f2f0d286738f2da67bb2/
core -
https://sourceforge.net/p/turbogears2/tg2/ci/203b2496ab1d413bfcea60aba2f941e910455998/
--
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.
--
Michael J. Pedersen
My IM IDs: Jabber/peder...@icelus.tzo.com, AIM/pedermj022171
Yahoo/pedermj2002, MSN/pedermj022...@hotmail.com
My LinkedIn Profile: http://www.linkedin.com/in/michaeljpedersen
Twitter: pedersentg
--
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.
--
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] Turbogears 2.1 breaks with SQLAlchemy 0.7beta
Hello guys, Just an FYI. Due to the change of API in SA0.7 (http://www.sqlalchemy.org/trac/wiki/07Migration#Thesqlalchemy.exceptionsaliasinsys.modulesisremoved) to be exact. The current release of TG is broken, as several packages it uses for example http://dpaste.com/416049/ use the old import. Until this is fixed in TG the solution is to run. pip install -U sqlalchemy==0.6.6 -- 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.
Re: [TurboGears] Re: SQLAlchemy 0.7 and TG 1.5 breakage...
Hey Sam, Is it general breakage or just on the imports like 2.x ? On Mon, Feb 14, 2011 at 11:40 PM, Sam samsli...@gmail.com wrote: Just noticed the thread about 2.1 breakage. Since I don't use 2.x I usually ignore those threads. ;) On Feb 14, 7:25 pm, Sam samsli...@gmail.com wrote: Just a quick note that the docs for 1.5 call for typing in: easy_install SQLAlchemy which currently gives one a 0.7 beta instead of the 0.6.6 it presumably used to give. This does not work (only tested with Identity on - but I'd bet it causes problems everywhere). easy_install SQLAlchemy==0.6.6 worked fine. I'd also imagine this is potentially an issue with the entire 1.x series. Thanks Sam -- 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. -- 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] [offtopic] Pycon roomsharing ?
Hello guys, I'm looking for someone that will be willing to do roomsharing for pycon. And I'll be very interested in finding someone that is involved in the wsgi world. My current plans are to stay in for the conference days + 1 or two of the tutorials. That is arrive on march 10 leaving on march 14 or 15. Any takers ? Sorry for the offtopic. -- 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: [offtopic] Pycon roomsharing ?
Sorry I mean. conferences + two days of sprints. Not two days of tutorials. On Wed, Jan 26, 2011 at 9:32 AM, Jorge Vargas jorge.var...@gmail.comwrote: Hello guys, I'm looking for someone that will be willing to do roomsharing for pycon. And I'll be very interested in finding someone that is involved in the wsgi world. My current plans are to stay in for the conference days + 1 or two of the tutorials. That is arrive on march 10 leaving on march 14 or 15. Any takers ? Sorry for the offtopic. -- 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: [tg-trunk] TurboGears 2.1 Released!
I'm glad this is finally out. I'll like to thank everyone for the hard work put here ! On Fri, Nov 19, 2010 at 6:28 PM, Chris Perkins ch...@percious.com wrote: The TurboGears team is proud to present TurboGears 2.1. 2.1 has been in development for about one year with the first alpha released in October of 2009. If you haven’t been following along, here is a review of the changes that 2.1 brings from 2.0. Better performance. The TG team worked hard profiling to see what could be done to make TG faster. 2.1 is at least 20% faster than 2.0 on page-loads as a result. Better Mako support. (quickstart template now includes a --mako option) If you want a highly performant website, Mako is a better option than genshi. Kajiki support. This template engine is for those who like the XML templating on Genshi, but need much better performance. Re-written dispatcher. Object Dispatch has now become Abstract Dispatch, and the code that decides which controller method should be executed has been refactored and consolidated. An open API is provided for those that want to create their own dispatch mechanisms by using the _dispatch method in your controllers. Pylons 1.0 support. Those of you still running 0.9.7 can do so as well. TG 2.1 is cross -compatible, which means if you have a 2.0 application, you needn’t upgrade to Pylons 1.0 until you decide to. Reduced dependencies. For those of you who use TG as a service, or do not need database or an admin, TG has reduced it’s dependencies to the low-20s. The full stack with SQLAlchemy and an admin still has more packages, but the packages which were most difficult to install have been removed (those requiring RuleDispatch in particular). Finally, documentation improvements. The documentation has been visually overhauled, reorganized, and brought up to date. There is still considerable work to do in this area, but a significant effort has been made to solidify those areas which are most often asked about by our users. TurboGears is committed to maintaining the 2.x branch for the long-term. This release is intended not to make significant strides in capability, rather to refine our existing functionality in order to add significant consistency to the codebase. We have already started working on a 2.2 branch, which continues this effort, and will open up more APIs to the framework. We look forward to your continued support! A special thanks goes out to all of you who made this release possible. Without the dedication from folks writing docs, providing feedback and bugfixes, this release could not have happened. We look forward to the continued community support for the future to come. cheers. -chris -- 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 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.
[TurboGears] Sites Powered by Sprox?
Hello people, As you may know I'm giving a pycon2010 talk for Sprox (http://us.pycon.org/2010/conference/schedule/event/36/) And I was wondering if it will be a good idea to add a who is using it as the last slide for my presentation. So If you have a site (public or private) and are interested in a little plug please send me an email for me to add you. I think it will be enough with - Person or Company in charge of the dev work - Person or Company running the site - URL of the site (if avaliable) - How are you using Sprox? Ideally it should be very short! 2-3 lines at most. -- 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: [TurboGears] observations about TG 2.1
On Fri, Nov 13, 2009 at 9:44 AM, Jonathan LaCour jonat...@cleverdevil.org wrote: Hello Jonathan, This discussion belongs in the trunk list So I have moved it there. 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! Thank you very much! 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. This is one of the big problems with the new set of renderers. I also agree we need a better way for them. There is a ticket in trac about it. Apparently this was solved http://trac.turbogears.org/ticket/2287 if it wasn't enough fell free to give more input. (I did but never got a reply from the original author of the patch) and this is a feature I don't really use. 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. Inadequate is not a correct term. The replacement is a 95% replacement and the only thing missing is this @when back when I was implementing this I asked for feedback for example: http://groups.google.com/group/turbogears-trunk/browse_thread/thread/7b21549b3fea370e/ and at least 2 other threads since no one replied (except mramm, who said he was ok with getting rid of it) we wrote this off as a not-so-common feature of TG1 which could be stripped. 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 :) well a better solution (yet still monkeypatch) will be to monkeypatch the type itself. that is something along the lines of. builtin.__json__ = my_custom_json() That said I'm willing to work with you on a solution for this where we can extend tg.json.py 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. Definitely I think it should be in app.cfg. 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. I'm -0 on this one. do we really need generic dispatch? can't we just provide a hook to extend tg/json.py in theory all you will need is to extend the buildin json serializer add rules for your custom types and tell TG to use it. 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 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] Regarding the use of the Mailing Lists
It was pointed out in the tg1.5 thread that people are using the main mailing list for everything and the trunk list is semi-abandoned this is not right, and we should fix it. Therefore I'm asking everyone to please follow this simply list of advice before posting. To all other moderators fell free to tell people that their thread is in the wrong list and send a CC there together with your reply. - If you have a question regarding how something works in a released version please use the turbogears list otherwise go to the trunk list. - if it's a feature request or bugfix go to the trunk list (ideally with a trac ticket, even better with a repo where the fix has been applied.) - if you are not sure simply go to turbogears and we'll redirect you if we think it's the right thing to do. The overall idea is to not mix discussion (which can get big) with support and feedback. Thank You --~--~-~--~~~---~--~~ 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: TurboGears 1.5 development plans
On Thu, Nov 5, 2009 at 2:39 AM, Chris Arndt chris.ar...@web.de wrote: On 5 Nov., 04:37, Jorge Vargas jorge.var...@gmail.com wrote: On Wed, Nov 4, 2009 at 4:04 AM, Chris Arndt chris.ar...@web.de wrote: - Reclaim SVN repository? - Migrate Trac and SVN to new server - Separate tags/branches/trunk structure for TG1 and TG2 I believe it was agreed some time ago we'll migrate to mercurial, why go back to svn? TG2 did the move. I don't suggest that TG2 move back to SVN, but I'am against moving TG1 into hg anytime soon. I think this is one of those cases where this should be in trunk. To be honest, I was never happy with the way the decision of migrating TG2 to hg decision was made and I still don't see what advantages it has brought. I'm sorry to heard that but everyone is very happy with it. just look at On the contrary, there exists considerable confusion now where the official repo is (do the 2.0 docs even mention the hg repository?) and it is poorly maintained (e.g. missing tags for official releases). Just take a look at the number of people here that didn't had commit access in svn http://bitbucket.org/pedersen/tg_2_1_docs/descendants/ http://bitbucket.org/mramm/tg-21/descendants/ The reason why the move isn't finished is because we are waiting on an upgrade of the turbogers account to point hg.turbogears.org to it. Yet again another topic not for the main list. - Revive turbogears-trunk and make distinction between users and development mailing list clear. I do not think this need reviving simply a lot of discussion is currently happening on IRC. IRC is not an optimal medium for development discussion, IMHO. It is not archived properly, unstructured and hard to search. Ideally, development discussion and decisions should be documented in the docs or the ticket system, but a mailing list is the next best thing. It seems you all misinterpreted me on this, which probably means I didn't explained myself correctly. I'm not saying we are going to replace the ML with irc. I'm just saying a lot of discussion has happen on IRC which reduced the traffic of the ML. - migration of TG Trac and SVN to dedicated server afterwards again why svn? See above. - Start discussion about the relationship of TG 1 and TG2 and the (poor) maintenance state of the TG2 branch. The 2.1 branch has had a ton of commits recently and the 2.0 branch is in maintenance mode and 2.0.4 will come out only if a security release is needed. http://bitbucket.org/turbogears/tg-dev/http://bitbucket.org/turbogears/tgdevtools-dev/ andhttp://bitbucket.org/turbogears/tg-docs/ have had a ton of changesets. - The 2.0.3 release is STILL not listed on PyPI. yes, give me access to it and you will see it up thre in the next couple of minutes. - There are more than 30 tickets pertaining to TG2 on the turbogears trac, which have not had a milestone assigned and it looks like they are not being attended to See http://trac.turbogears.org/query?status=!closedgroup=versionmilestone=milestone=__unclassified__order=priority I mentioned this several times on the mailing list, but nothing I'm sorry we are all busy people. I started going over your list the first time you created it but I haven't had the time. I'l do my best to go over it but remember we are all volunteers here. happens. Are you still looking at the svn repository for this? No. Chris --~--~-~--~~~---~--~~ 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: TurboGears 1.5 development plans
On Fri, Nov 6, 2009 at 3:01 AM, Diez B. Roggisch de...@web.de wrote: IRC is not an optimal medium for development discussion, IMHO. It is not archived properly, unstructured and hard to search. Ideally, development discussion and decisions should be documented in the docs or the ticket system, but a mailing list is the next best thing. You are so right about this. For starters, I'm not even *allowed* to go to IRC at work. So from the about potentially 16-18h a day, I could only stay on IRC for about half of them. But then there is the issue of timezones, the fact that permanently following a chat in the hope of something interesting or relevant happening is massively distracting (to me at least), the interleaved discussions of others... I don't mind the occasional IRC conference. But even that I can't guarantee to attend. Real Live and such. And where are the results of those discussions you guys have? Can I read them? Can I comment on them? Can I *work* on them? No. I'm sorry all I said was that most of the support and bugfixes have been moved there. All mayor changes had been discussed in the list. I do agree with what you say and from my part I'm sorry we should indeed use the ML more to report some bugs for everyone to see, although other things are way better in a faster feedback channel. For example the recent content-type bug will not be fixed if we didn't had people on IRC discussing it. So I'm feeling I'm cut out of the development efforts. The public visibility of those is reduced, as no one can follow discussions and decisions by searching through ML or TRAC. Which might give the impression to others that the project isn't very much alive. I don't agree with this. In the end progress equals code and the more checkins you see the more active a project is. Yes ML and trac help with the impression but a project that is getting tons of tickets is not more active than a project that is getting tons of checkins. For me this resulted in not doing anything anymore, except fixing maybe concrete bugs I encounter when working with TG2. The whole HG vs. Mercurial issue I also don't see as benefitial - but I can cope with it. See my other response. Diez --~--~-~--~~~---~--~~ 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: observations about TG 2.1
On Fri, Nov 13, 2009 at 9:44 AM, Jonathan LaCour jonat...@cleverdevil.org wrote: Hello Jonathan, This discussion belongs in the trunk list So I have moved it there. 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! Thank you very much! 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. This is one of the big problems with the new set of renderers. I also agree we need a better way for them. There is a ticket in trac about it. Apparently this was solved http://trac.turbogears.org/ticket/2287 if it wasn't enough fell free to give more input. (I did but never got a reply from the original author of the patch) and this is a feature I don't really use. 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. Inadequate is not a correct term. The replacement is a 95% replacement and the only thing missing is this @when back when I was implementing this I asked for feedback for example: http://groups.google.com/group/turbogears-trunk/browse_thread/thread/7b21549b3fea370e/ and at least 2 other threads since no one replied (except mramm, who said he was ok with getting rid of it) we wrote this off as a not-so-common feature of TG1 which could be stripped. 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 :) well a better solution (yet still monkeypatch) will be to monkeypatch the type itself. that is something along the lines of. builtin.__json__ = my_custom_json() That said I'm willing to work with you on a solution for this where we can extend tg.json.py 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. Definitely I think it should be in app.cfg. 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. I'm -0 on this one. do we really need generic dispatch? can't we just provide a hook to extend tg/json.py in theory all you will need is to extend the buildin json serializer add rules for your custom types and tell TG to use it. 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] Regarding the use of the Mailing Lists
It was pointed out in the tg1.5 thread that people are using the main mailing list for everything and the trunk list is semi-abandoned this is not right, and we should fix it. Therefore I'm asking everyone to please follow this simply list of advice before posting. To all other moderators fell free to tell people that their thread is in the wrong list and send a CC there together with your reply. - If you have a question regarding how something works in a released version please use the turbogears list otherwise go to the trunk list. - if it's a feature request or bugfix go to the trunk list (ideally with a trac ticket, even better with a repo where the fix has been applied.) - if you are not sure simply go to turbogears and we'll redirect you if we think it's the right thing to do. The overall idea is to not mix discussion (which can get big) with support and feedback. Thank You --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
TG2 tickets review Was: [TurboGears] Re: TurboGears 1.5 development plans
On Thu, Nov 5, 2009 at 2:39 AM, Chris Arndt chris.ar...@web.de wrote: This belongs to the trunk list. On 5 Nov., 04:37, Jorge Vargas jorge.var...@gmail.com wrote: On Wed, Nov 4, 2009 at 4:04 AM, Chris Arndt chris.ar...@web.de wrote: - There are more than 30 tickets pertaining to TG2 on the turbogears trac, which have not had a milestone assigned and it looks like they are not being attended to See http://trac.turbogears.org/query?status=!closedgroup=versionmilestone=milestone=__unclassified__order=priority I mentioned this several times on the mailing list, but nothing happens. I went over that list and commented, slotted properly and/or closed almost all of them Your feedback is appreciated. please note a lot of them where simply misplaced which you could have looked at instead of sending them to 2.x --~--~-~--~~~---~--~~ 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: Status of TG scheduler projects?
On Wed, Nov 4, 2009 at 4:15 AM, Chris Arndt chris.ar...@web.de wrote: Hi Jorge, thanks for your answers. I wrote to Vince directly as well and he gave me some more information in private email. +1 although I'll prefer it to be it's own hg repo. even if it stays in google code. Any particular reason for this? I would prefer that is hosted on svn.turbogears.org, because then we could add maintainers ourselves in case it is ever abandoned. But I'm not fixed on this. that can be done with hg.turbogears.org, my preference is for mercurial over svn rather than the actual URL. Chris --~--~-~--~~~---~--~~ 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: Status of TG scheduler projects?
On Sun, Nov 1, 2009 at 6:27 AM, Christopher Arndt chris.ar...@web.de wrote: Hi everybody, ticket #2396 [1] has led me to the discovery that the TG scheduler was extracted as an external project hosted on code.google.com [2]. I see that several TG maintainers are listed as project owners for this project. What is the status of this project? - Why was it extracted into an external project? Probably to be usable in TG2 right? yes, - Why is it hosted on code.google.com and not in the TG SVN repository? because it was done by a third party - Is this actively maintained? I believe so, vinces is using it in prod. - If so, who is the actual maintainer (Vince Spicer?)? yes - Will it be maintained for the foreseeable future? I do not know. - Is it kept in sync with the TG 1 version? I do not know - Will it be updated to the new devlopments in Irmen de Jong's version [3]? I do not know The reason I'm asking all these questions is that if this project will be actively maintained, I'd like to remove it from the TG 1.5 core or at least deprecate it. But for this to happen, we need to be sure that it will be maintained and I'd also prefer it to be hosted on svn.turbogears.org. +1 although I'll prefer it to be it's own hg repo. even if it stays in google code. Chris [1] http://trac.turbogears.org/ticket/2396 [2] http://code.google.com/p/tgscheduler/ [3] http://www.razorvine.net/download/kronos.py --~--~-~--~~~---~--~~ 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: migrate quickstarted projects from 2.0 to 2.1
On Fri, Oct 30, 2009 at 5:00 AM, pipoun pip...@gmail.com wrote: On Oct 29, 8:49 am, Jorge Vargas jorge.var...@gmail.com wrote: On Wed, Oct 28, 2009 at 8:41 AM, pipoun pip...@gmail.com wrote: Should I update theses files? How can I do that automatically? You should updated them. And no there is no way to update them automatically as there is no way for the tool to know if it should overrides your changes or not. Thanks for the info I've tried to quickstart a new project in another folder, but it doesn't work because paster doesn't want to create a new project with the same project/package/module name. yes that is the worst part. I normally rename the old one to something else. I had to create a new virtualenv and quickstart from it. Now I have to merge the files... I hope there will be a more practical way to do that in the future. completely agree, however it's a complex problem. Other than having a branch in your dvcs where you can merge from I can't think of another solution. The problem is really that the QS code has no idea if you modified the files so it can't overwrite them. And in some cases you DO want to get rid of them. --~--~-~--~~~---~--~~ 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: migrate quickstarted projects from 2.0 to 2.1
On Wed, Oct 28, 2009 at 8:41 AM, pipoun pip...@gmail.com wrote: Hi all, The update from 2.0 to 2.1 is simple and documented: (tg2env)$ easy_install -U -i http://www.turbogears.org/2.1/downloads/current/index tg.devtools But I'm wondering if we have to update the files that have been automatically generated with 'paster quickstart'. So is there any differences between a quickstart project in 2.0 and 2.1? Yes, several minor things have changed. In general it should only be adding more things, however quickstart will evolve overtime and the changelog/release notes will only point out the critical changes. Should I update theses files? How can I do that automatically? You should updated them. And no there is no way to update them automatically as there is no way for the tool to know if it should overrides your changes or not. Thanks in advance! --~--~-~--~~~---~--~~ 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: TurboGears User Survey
On Mon, Oct 19, 2009 at 11:09 PM, Uwe Schroeder u...@oss4u.com wrote: On Monday 19 October 2009 10:37:04 am Chris Arndt wrote: One reason for doing this survey was to find out, whether there is still interest in further development of a CherryPy based TG version or if we just do a couple more maintenance releases of the TG 1.1 branch and then let it rest. I would be interested in working on TG 1.5 but I am only willing to put effort in this, if there is sufficient interest. The TG 1 developer base is very small now (basically only three active devs atm), and continuing to evolve the TG 1 code base would mean a serious commitment and I'm not even sure there is a place for it in the Python web framework world. I certainly think that it would not make sense to continue both branches under the umbrella of the TurboGears moniker, but that's just my opinion. On the other hand, I get often get reports from people running still on TG 1 and no intention of switching soon. Switching a large application is really hard. I've started working on switching my app to TG2, but honestly, it will probably take a year to get there. So many crucial things changed completely (nope, not starting the compatibility rant again :-) ), so in my case I need to completely rewrite a heck of a lot of code and that doesn't even cover the whole registration, signup and auth stuff. Could you please elaborate on this more. Are you still using sqlobject? Regarding the authauth stuff. Could you please point out the places where the API is not backwards compatible for your needs? TG1 works fine so far. It has it's quirks and I invented a bunch of workarounds to make it work the way I want. I checked up on TG2 and there I'd need another bunch of workarounds, which would require learning the completely different base of things. which TG2 workarounds? TG1.1 and TG1.5 have very similar issues to TG2 in my case. My biggest issue is that there is no toscawidgets support for TG1 anymore. Resources are not injected anymore. So I'm using a stone age toscawidgets release on TG1.0.4 which one can't even download anymore. Toscawidgets itself didn't change all that much, but omitting the resources from loading is just a killer. What good does it do to define a javascript that is never injected? So basically I'm stuck on a 1.0.4 version and I don't have the time or the resources to pull it over to TG2 anytime soon As others said this shouldn't be the case. Uwe --~--~-~--~~~---~--~~ 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: Where to Start: Auth by Context?
On Wed, Oct 28, 2009 at 9:28 AM, L Dary luked...@hotmail.com wrote: Let me start by saying how impressed I am with TG2, and also how excited I am to finally be starting to attempt to make some applications with it (I started out reading the TG1 book, and really watching the development, but never really made anything with TG1). I have decided to make my first attempt at a 'real' application, and need some advice on where to start to figure out my first road block: Authentication and Authorization. The way I am thinking about the users does not seem to fit into the User, Group, Permission setup quite right. Let me describe the structure I have put down on paper, and hopefully someone can help me get started with a link or some advice. The application is based around self-contained instances of events. Any user has the right to create their own events (which they are the manager for). A user can be a participant in events, an assistant for an event, a manager of an event, or they can also be a system administrator. This breaks down really into two 'system-level' groups: Users and System Admins. This seems like it would work fine with the usual User, Group, Permission setup. It is the authorization of content, based on the user's specific role within an event that has me stumped, however. A user may be part of any number of events, and have different roles within each event. User A might be the manager of Event A, and a participant in Event B. What I want to accomplish is that when User A requests details of Event A that they would receive additional options than what they receive when they request details of Event B. There is one additional piece to all of this, which is that all participants in an event are put into 'Teams' which further changes what is displayed on each page. The way I would describe it is: User, Group, Role (per event), Team (per event), Permission. You are certainly right and this is a flaw in the UGP paradigm as well as for r.what as that should be more generic. What you are describing is the abstraction of row level permissions or in a more general way. You need to know about the owner of an object In the last couple of weeks I have been discussion this with mcdonc (author of r.who, but not r.what) on IRC for the last few weeks and it is a hard topic to abstract. So far we came up with two alternative systems and well they are waiting for someone to sit down and write the code :) I guess my overall question is: Can this be done with the existing TG2 auth (or by extending it), or will I need to do something more involved? in theory yes, but that will involve some not-so-nice-hacks. You could create some sort of predicate that will pull things from the request and/or environ and create a SQL query to look for some particular field in your object. However this is very inefficient if you need to scale it. Ideally I think this should be develop as some sort of tgext module as it's an specific need. If you are interested in talking about it please drop by #turbogears on freenode. Please ask for any clarification where I haven't been clear. Thank you so much for any help. --~--~-~--~~~---~--~~ 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: What does turbogears.decorator.decorator do? (pre-2.0 version of TurboGears)
On Fri, Oct 16, 2009 at 11:28 AM, Diez B. Roggisch de...@web.de wrote: Chris Seberino schrieb: On Oct 16, 3:05 am, Christopher Arndt chris.ar...@web.de wrote: Can you give a more complete code example of what you are trying to do? I believe that these functions are not decorators but *generate* decorators. I've been using my own custom lightweight auth system for years... I was just curious what the last line does. I thought any function that returned a function was *already* a decorator!? def access_control(function): Decorator that denies access without authentication. def new_function(function, *parameters, **keywords): Adds a wrapper requiring authentication. if (logged_in in cherrypy.session) and \ cherrypy.session[logged_in]: return function(*parameters, **keywords) else: raise turbogears.redirect(/access_control_/ log_in) return new_function access_control = turbogears.decorator.decorator(access_control) The problem with this is the same as with the IMHO much to over-generic repoze.w*-system that is TG2-agnostic: you will get you decorator executed *after* validation has taken place. Now depending on your site, this might impose a security-risk, if validator-code is thus run for users that don't have the necessary privileges. This is not entirely accurate. In both tg1 and tg2 the decorators are more like registries so when you load the controller they get processed and stored in the decoration. On each call from the web the decoration is ran which effectively means it gets called on every run. Diez --~--~-~--~~~---~--~~ 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: TG 2.1 Auto instalation with tg2-bootstrap
On Wed, Oct 7, 2009 at 5:42 AM, Helio Pereira helio.mc.pere...@gmail.com wrote: Hi all, I am trying to install TG 2.1 but can't download tg2-bootstrap.py. Download and run the script with the following commands: wget http://www.turbogears.org/2.1/downloads/current/tg2-bootstrap.py python tg2-bootstrap.py --no-site-packages tg2env Sorry for the late response. This was deliberately left not possible because 2.1 is in alpha. I do agree that the link should be removed. if we do. I think what we really need is to update the link/script to point to hg and the 2.1 index. Regards, Helio Pereira --~--~-~--~~~---~--~~ 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: tg-admin kid2genshi command
On Sat, Oct 10, 2009 at 10:48 AM, Christoph Zwerschke c...@online.de wrote: I've just added a tg-admin kid2genshi command to TG 1.1 in SVN. This command converts all existing Kid templates in your project to Genshi templates. I've put this in quotes because it only does a minimal job of changing the namespace and altering simple py:extends constructs to use the xinclude mechanism instead. You can also convert back from Genshi to Kid with the -r option. All available options are displayed with --help. Will anyone be interested in seeing this command in the 2.0/2.1 branches? --~--~-~--~~~---~--~~ 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] tg-admin kid2genshi command
On Sat, Oct 10, 2009 at 10:48 AM, Christoph Zwerschke c...@online.de wrote: I've just added a tg-admin kid2genshi command to TG 1.1 in SVN. This command converts all existing Kid templates in your project to Genshi templates. I've put this in quotes because it only does a minimal job of changing the namespace and altering simple py:extends constructs to use the xinclude mechanism instead. You can also convert back from Genshi to Kid with the -r option. All available options are displayed with --help. Will anyone be interested in seeing this command in the 2.0/2.1 branches? --~--~-~--~~~---~--~~ 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: tg2 and PIP
On Thu, Oct 15, 2009 at 10:14 PM, Jose Galvez jj.gal...@gmail.com wrote: does TG2 work with PIP and or Distribute? I've been looking at them lately and wondering where the whole thing is going to end up it sure does work with pip, I personally make that happen and have been using it for at least a year :) As for distribute I haven't used it personally but Tarek and the guys have made a very good work to get the replacement setuptools module so I'm pretty sure it works. --~--~-~--~~~---~--~~ 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: Turbogears 2.0.3 not in PyPI
On Tue, Sep 22, 2009 at 3:04 PM, davidjagoe davidja...@gmail.com wrote: Ahoy! I have built a TG2 app using the recommended method (virtualenv, tg2- bootstrap, paster, ...) and everything works great. I am now preparing for the first production deployment of my app and would like to deploy it as an egg. The setup.py lists the correct dependencies (e.g. TurboGears2 = 2.0.3). Unfortunately the latest TG2 version in PyPI is 2.0.1, so when I easy_install my app that is the latest version I can get. This is correct, sorry about this. The version in the private index is the canonical place to look for it. Firstly, is there any reason that later versions are not in PyPI? just that the person that owns the index didn't update it :( Secondly, I have not been involved in this community before (this is my first TG app) but if you could use a hand I'd be happy to upload the later releases. Thank you for the offer :) the problem right now is about coordination. And the need for a better release process Thanks, David --~--~-~--~~~---~--~~ 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: Is there a way to do a not so quick start?
On Wed, Oct 14, 2009 at 2:24 PM, notnow ca17...@bellsouth.net wrote: I'm just using this thread because it came up in my search. How can you add auth after a quickstart? The webfaction install script quickstart does not include auth. No simple way really. You will need to look at what the QS script does and add that to your project. Diff is your friend there. On Sep 30, 5:37 pm, Crusty crust...@gmail.com wrote: Hey there, what you are trying to do feels kinda incompatible with the TG philosophy. A dude once wrote in some doc str TG related to Pylons as Ubuntu related to Debian. TG is meant to be easy-out-of-the-box usuable, whereas pylons provides the full flexibility, but at the cost of more complexity. TG is a facilitating unit a bit like glue between all those nice subsystems (Pylons, Genshi, etc) If you dont want to use 2 of the basic TG pillars, I dont see what added value you get from moving to TG. TG is basically preconfigured Pylons with heaps of sugar on top and glue code to integrate the others, which you dont want. Surely you could hack TG in such a way, but not sure if thats the intention. I guess many here probably wont agree, and it's always nice to see new people joining TG, but I'm just trying to help you with your specific problem at the best way possible... You got the entire thing running already on Pylons... so you got the worst behind you. Greetings, Tom On Tue, Sep 29, 2009 at 4:56 PM, percious ch...@percious.com wrote: To answer your questions: 1. The one option you could take is to choose noauth at the quickstart and thenaddthings as you need them. As for mako, I have the templates for this coded, we just need toaddthem into thequickstartswitch. I have been looking for some push to do so, but everyone (else) seems sort of in love with genshi. 2. Well, since TG is built right on top of pylons, you can just use your pylons controllers right in your tg app without any modification to them. All you must do is provide routes, here is some documentation on how to do that:http://turbogears.org/2.1/docs/main/Config/Routes.html Hope that helps. cheers. -chris On Sep 29, 6:03 am, loxs akat.me...@gmail.com wrote: Hi, I am new to TG, coming from pylons background. I had a nice chat with some of you today in IRC and as I said there, I started considering the idea of migrating to TG2. I have some hard time though. Mainly because what I need is not so standard. Here are two of the questions that come in mind. I guess they may be immature, as I haven't read most of the documentation yet, but I'll try asking :). 1. Is there some way to do a not so quick start? I mean, is there some way to choose my components when creating a turbogears project? I don't want SQLAlchemy (I'll use CouchDB), and I want to use Mako, instead of Genshi. I didn't find any docs on how to create such a project. 2. Is there some good way of migrating a pylons project to TG? Most of my projects have some TG packages integrated on top of pylons, like ToscaWidgets, repoze.who, repoze.what. And now I like Object Dispatch and want to use it. So I think that instead of supporting lots of hacks to keep this packages integrated with my projects, I'd like to migrate them to TG altogether. And I couldn't find anything on such topics. Not even blog posts. Disclaimer: I'm not disappointed by Pylons at all. Just the contrary, it's great. And I hope that TG won't take away the flexibility I have with pylons now.- Hide quoted text - - Show quoted text - --~--~-~--~~~---~--~~ 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: [TurboGears] TurboGears 2.1a1 is released!
to the template lookup in Mako. This allows the admin to inherit your local project’s master.mak file. An inhertance clause in Mako that uses local would looks something like:: %inherit file=app:templates.master/ Genshi has support for this automatically, but it is not explicit, and we are looking at ways to support this explicitly before 2.1 goes to final. ToscaWidgets2 Support -- ToscaWidgets2 recently made a 2.0a1 release. We have included in TurboGears2.1 the ability to easily configure your application for TW2, along with other added support for this next-generation widget framework. Thanks === This release comes not without considerable effort on the part of the TurboGears team. I would like to thank Michael Pedersen for his undying effort with the docs. Michael helped to collect about 190 todo items for our docs, and squashed a countless number of them. We now have about 130 items todo on the docs, but that number is ever- decreasing with his and other’s effort. Thanks to those folks who have contributed to the DocSprint, and who still continue to contribute, including Michael Fletcher, Jorge Vargas, and Seth Davis. If you use TurboGears, and find you need to dig into the source code to figure stuff out, please help us make the docs better by contributing to a DocSprint or sending us a pull request. Thanks to Jorge for straightening out the Json rendering issue. Also, by removing TurboJson from the stack of required packages, we have opened the door for TurboGears to run on AppEngine and Jython. This would not be possible without Jorge’s effort. Thanks also to Mark Ramm, Christopher Ardnt, Florent Aide, Alberto Valverde, Paul Johnston, Christoph Zwerschke, and Lee McFadden for their continued support of TG. Finally, I just wanted to send a thank you to the folks who have contributed to the TG codebase by association. Mike Bayer, Jason Kirtland, Ben Bangert, Philip Jenvey, Chris McDonough, and last but not least Ian Bicking. Thanks for all of your effort making possible this great conglomeration of parts. cheers. -chris --~--~-~--~~~---~--~~ 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: TurboJson missing in TG 2.0 documentation
On Tue, Sep 29, 2009 at 8:09 AM, Christophe de VIENNE
cdevie...@gmail.com wrote:
Hi,
I was looking for what replaced turbojson in TG2 to find out it is still
there but not mentioned at all in the TG 2.0 documentation.
I would suggest an addition.
If you like I can report this on the tg trac.
The code is backwards compatible so the documentation is pretty much
@expose('json')
A ton of docs mention it, so I'm not really sure if it's needed.
However a section on __json__ should be nice. yet this didn't exist in
the original docs.
Thanks,
Christophe
--~--~-~--~~~---~--~~
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: TurboGears 2.1a1 is released!
to the template lookup in Mako. This allows the admin to inherit your local project’s master.mak file. An inhertance clause in Mako that uses local would looks something like:: %inherit file=app:templates.master/ Genshi has support for this automatically, but it is not explicit, and we are looking at ways to support this explicitly before 2.1 goes to final. ToscaWidgets2 Support -- ToscaWidgets2 recently made a 2.0a1 release. We have included in TurboGears2.1 the ability to easily configure your application for TW2, along with other added support for this next-generation widget framework. Thanks === This release comes not without considerable effort on the part of the TurboGears team. I would like to thank Michael Pedersen for his undying effort with the docs. Michael helped to collect about 190 todo items for our docs, and squashed a countless number of them. We now have about 130 items todo on the docs, but that number is ever- decreasing with his and other’s effort. Thanks to those folks who have contributed to the DocSprint, and who still continue to contribute, including Michael Fletcher, Jorge Vargas, and Seth Davis. If you use TurboGears, and find you need to dig into the source code to figure stuff out, please help us make the docs better by contributing to a DocSprint or sending us a pull request. Thanks to Jorge for straightening out the Json rendering issue. Also, by removing TurboJson from the stack of required packages, we have opened the door for TurboGears to run on AppEngine and Jython. This would not be possible without Jorge’s effort. Thanks also to Mark Ramm, Christopher Ardnt, Florent Aide, Alberto Valverde, Paul Johnston, Christoph Zwerschke, and Lee McFadden for their continued support of TG. Finally, I just wanted to send a thank you to the folks who have contributed to the TG codebase by association. Mike Bayer, Jason Kirtland, Ben Bangert, Philip Jenvey, Chris McDonough, and last but not least Ian Bicking. Thanks for all of your effort making possible this great conglomeration of parts. cheers. -chris --~--~-~--~~~---~--~~ 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: TG 1.1
On Thu, Sep 3, 2009 at 9:46 AM, Christophe de VIENNEcdevie...@gmail.com wrote: Hi Florent, 2009/9/3 Florent Aide florent.a...@gmail.com Hi Guys, I have worked on the 1.1 release and I have all tests working in TG itself and in the QS template (the default one with SQLAlchemy, with and without identity)! Well done ! In the process I removed all deprecation warnings from SQLAlchemy 0.5.5 about the session_mapper. At the moment I have just replaced the session mapper with the sqlalchemy.orm.mapper. BUT this means that user code that relied on the session_mapper behaviour (instanciating the object with arguments, auto saving, query method on the class) will break. We could try to mimic the session_mapper behavior (it is documented in the SQLAlchemy documentation) but I would rather avoid this cruft and explain how to migrate from the old SQLAlchemy way to the new one... What do others out there think? Can we make the old behavior optional ? It would require an explicit activation, so that the developper knows that he is relying on a deprecated behavior. I kind of agree with this. Do we really need to mimic it? It's deprecated so an explanation that you should migrate seems best to me. My 2 cents, Christophe --~--~-~--~~~---~--~~ 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: First Few Documentation Updates
raises hand too. I'll like to expend a couple of hours this weekend getting us a independent doc release process so we can make this faster and better and finally see your initial work go live. On Thu, Sep 3, 2009 at 9:25 AM, perciousch...@percious.com wrote: *raises hand. I'm spending a few hours every week on this process. Also, I think we should have a doc sprint in the near future, as a prelude to TG 2.1a1 release. cheers. -chris On Sep 2, 11:02 pm, Michael Pedersen mjpe...@gmail.com wrote: Okay, I've been working on these docs quite a bit since I first sent this out. As of a few minutes ago, I finally managed to complete the first file reviews. Every single file was read by me, and quite a few todo items were noted. As of right now, I've got 128 items on the todo list. That does not cover the emails I've saved from this list as get this documented, which I'm now adding. Nor does it include docs tickets from trac.tg.org, which will be forthcoming soon. Basically, we now have a mostly fixed target set of items for the docs. Who's ready to help me start whittling this list down? On Mon, Jul 6, 2009 at 10:26 AM, Michael Pedersen mjpe...@gmail.com wrote: On Mon, Jul 6, 2009 at 10:04 AM, Lukasz Szybalski szybal...@gmail.comwrote: The output is visible athttp://web.icelus.tzo.com/~marvin/tg2/http://web.icelus.tzo.com/%7Emarvin/tg2/ How is this different then the official tg2 docs? Not sure what you're plan is but wouldn't it be easier to modify the original content and add the few sections that you have above. Work on the original to get the pdf generated, and keep modifying until all the information is in the same place? As to how it's different, compare these two pages: http://turbogears.org/2.0/docs/index.html http://web.icelus.tzo.com/~marvin/tg2http://web.icelus.tzo.com/%7Emarvin/tg2 When you do, ask a couple of questions (and pretend you know nothing at all about TG when you do, this is your first time looking at the docs, etc): 1. How do I get this installed? 2. What are the pieces that come with TG? 3. How can I use those pieces? 4. What are some of the common patterns for coding in TG? 5. What plugins are available? And those are just some starter questions. Once you've started asking those questions, try to find the answers using the older style and the newer style. In my own experience, and along with the feedback I've seen so far, the style I'm promoting will be significantly easier to navigate. Instead of screens full of links, we have actual text describing what people can expect to find. We have (just beginning) an actual to do list, so that we can identify where we've left documentation holes that need to be plugged. We have clearly defined areas for people to be able to submit their own docs on various items. Personally, I find the newer style much easier to read and navigate. As to work on the original, that's exactly what I'm doing. The original source for the docs is available at http://bitbucket.org/mramm/tg_2_1_docs/This is a Mercurial repository which I have forked (and my fork is visible at http://bitbucket.org/pedersen/tg_2_1_docs/). I've even sent along a pull request already for the base changes I've done, and I'm looking to get back to the documentation much more seriously tonight than I have been for a few days (July 4th weekend for me was fun, but busy). -- Michael J. Pedersen My IM IDs: Jabber/peder...@icelus.tzo.com, ICQ/103345809, AIM/pedermj022171 Yahoo/pedermj2002, MSN/pedermj022...@hotmail.com -- Michael J. Pedersen My IM IDs: Jabber/peder...@icelus.tzo.com, ICQ/103345809, AIM/pedermj022171 Yahoo/pedermj2002, MSN/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-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: The Turbogears2 has any timer funtions?
On Sat, Aug 29, 2009 at 1:51 AM, Boerncayso...@gmail.com wrote: Hi,all: I want setup a timer funtion in my tg2 app,so the tg2 has any builtin timer ? any body used it? this is no longer part of the core see http://pypi.python.org/pypi/TGScheduler/ thanks! -- Boern Parx --~--~-~--~~~---~--~~ 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] Infraestructure, bugfix and release sprints September 2009
Hello Guys, I think it's time for a sprint (actually several) to get several things updated. Goals == Infraestructure - final move away from svn - update beta.tg.org with tgext.mercurial and tgext.registration - final decision on HG repos (I believe hg.tg.org should be a self hosted set of hg repos and we should use BB to handle sync to the world and handle non-official forks) - discuss trac status, update, migrate, clean slate, etc. possibly migrate away from trac? or at least update to 0.11 - work on beta.tg.org content - work in upgrading our release process. Releases - - Apply all acceptable patches from trac, and any other bug fix people have - release TG2.0.4 and TG2.1a1 - test out our buildbot for real :) - merge all of mpedersen docs updates. and release them. Publish his TODO list which is quite big for people to fork and help. Potential Schedule sept 4-6 infraestructure (if anyone else but me and mark is interested in this we can move it to 11-13) sept 18-19 tg2.1a1 a third one? People that I think shouldn't miss this: - Florent, to give access to all resources needed, pypi, new box, etc. - Mark, to export the svn to hg - Jon, to work in the site content - ChrisP, for buildbot and 2.1a1 - Me, to work on hg.tg.org and the trac migration - mpedersen for the docs updates Of course everyone is welcome to join. --~--~-~--~~~---~--~~ 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] Infraestructure, bugfix and release sprints September 2009
Hello Guys, I think it's time for a sprint (actually several) to get several things updated. Goals == Infraestructure - final move away from svn - update beta.tg.org with tgext.mercurial and tgext.registration - final decision on HG repos (I believe hg.tg.org should be a self hosted set of hg repos and we should use BB to handle sync to the world and handle non-official forks) - discuss trac status, update, migrate, clean slate, etc. possibly migrate away from trac? or at least update to 0.11 - work on beta.tg.org content - work in upgrading our release process. Releases - - Apply all acceptable patches from trac, and any other bug fix people have - release TG2.0.4 and TG2.1a1 - test out our buildbot for real :) - merge all of mpedersen docs updates. and release them. Publish his TODO list which is quite big for people to fork and help. Potential Schedule sept 4-6 infraestructure (if anyone else but me and mark is interested in this we can move it to 11-13) sept 18-19 tg2.1a1 a third one? People that I think shouldn't miss this: - Florent, to give access to all resources needed, pypi, new box, etc. - Mark, to export the svn to hg - Jon, to work in the site content - ChrisP, for buildbot and 2.1a1 - Me, to work on hg.tg.org and the trac migration - mpedersen for the docs updates Of course everyone is welcome to join. --~--~-~--~~~---~--~~ 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] TurboJson and Python2.6, a fix
Today with cfarrell on IRC we tracked down a bug with TurboJson running under py2.6. Apparently older versions of PEAK-rules didn't work with py2.6 so I have bumped the dependency here http://trac.turbogears.org/changeset/6618 Of course we now need to bump the TG dep but I haven't done that because it will break people running trunk (or the branch for that case). For users the fix is simple pip install -U PEAK-Rules or easy_install... (Note: caps are important!) With TG 2.0.4 this of course will be included. --~--~-~--~~~---~--~~ 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] TurboJson and Python2.6, a fix
Today with cfarrell on IRC we tracked down a bug with TurboJson running under py2.6. Apparently older versions of PEAK-rules didn't work with py2.6 so I have bumped the dependency here http://trac.turbogears.org/changeset/6618 Of course we now need to bump the TG dep but I haven't done that because it will break people running trunk (or the branch for that case). For users the fix is simple pip install -U PEAK-Rules or easy_install... (Note: caps are important!) With TG 2.0.4 this of course will be included. --~--~-~--~~~---~--~~ 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: Flash Widget
On Fri, Aug 21, 2009 at 10:05 AM, working_antosgili...@o2.pl wrote: Greetings everyone, As I am trying to make my site capable of playing locally stored flv movies I found a document describing how to do it with TG1 (http://docs.turbogears.org/1.0/RoughDocs/WidgetRecipes#id2) My application is based on TurboGears 2.0 and I wanted to use the recipe - is there an updated version of recipe anywhere? Did you try the generic widget? the difference from TG1 and TG2 is that in 2 widgets are a separate package, so all you need to do is import from toscawidgets (or tw.forms) and things should work. It will be nice to repackage that as a tw. If I ever need flash I'll do that :) If there isn't, can anyone point me to an alternative approach towards serving locally hosted flv files and their playback in TG2. All help appreciated, Best, --~--~-~--~~~---~--~~ 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] Should we drop the TG index and use pypi only?
I know this has been discussed before but times are now different. Originally we needed the index because pylons 0.9.7 wasn't released and most TG dependencies where not on pypi. Today the story is different as everything is fetchable from pypi, on top of that the version in the index tend to lack behind as it is only updated every time a regular TG release happens. I'm not going to list the devs but it's a big thing. If you want to see all the mismatches just install TG from the index and then run pip install -U . (or python setup.py develop) on a quickstarted project and compare your sitepackages. so I'll like to revise the decision. Back then the pro index arguments where - unreleased packages - maintaining a well known set - pypi's instability Are those still valid? What is everyone's opinion on this? and more importantly are the ones in favor of the index up for the task of maintaining it? --~--~-~--~~~---~--~~ 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] List of Quickstarted files that are save to remove
From time to time people on IRC ask what is safe to get rid of without breaking TG, and they are right for a new guy you don't want to screw up your system. Today I was starting a new project and I decide to document my regular cleanup. Of course the ML is not a permanent place for this but neither is docs so I'm not sure (suggestions are welcome). files save to remove templates/about.html templates/authentication.html controllers/secure.py public/css/style.css public/images/* (under_the_hood_blue.png will be nice to keep :) content save to remove -- templates/footer.html templates/header.html templates/index.html templates/master.html (except tg.flash and last div) templates/sidebars.html parts save to remove - controllers/root.py - about - auth - manage_permission_only - editor_user_only - secc = SecureController() websetup.py - manager,group,permission and editor objects (or at least edit them) --~--~-~--~~~---~--~~ 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: List of Quickstarted files that are save to remove
On Sat, Aug 22, 2009 at 2:04 PM, Jorge Vargasjorge.var...@gmail.com wrote: From time to time people on IRC ask what is safe to get rid of without breaking TG, and they are right for a new guy you don't want to screw up your system. Today I was starting a new project and I decide to document my regular cleanup. Of course the ML is not a permanent place for this but neither is docs so I'm not sure (suggestions are welcome). files save to remove templates/about.html templates/authentication.html controllers/secure.py public/css/style.css public/images/* (under_the_hood_blue.png will be nice to keep :) I little correction you should probably want to keep or replace with your own the following images error.png info.png ok.png star.png under_the_hood_blue.png warning.png content save to remove -- templates/footer.html templates/header.html templates/index.html templates/master.html (except tg.flash and last div) templates/sidebars.html parts save to remove - controllers/root.py - about - auth - manage_permission_only - editor_user_only - secc = SecureController() websetup.py - manager,group,permission and editor objects (or at least edit them) --~--~-~--~~~---~--~~ 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: Python 2.6.2 - What kind of trouble am I asking for ?
On Tue, Aug 18, 2009 at 4:16 PM, dudeDadken.ad...@gmail.com wrote: I am using Ubuntu Server 9.04 which comes out of the box with Python 2.6.2. All the PG2 docs keep talking about it working just on 2.4 and 2.5. You mean TG2? The main install tutorial says: ...python 2.6 require additional steps which will be covered in the appropriate sections but never actually details any specific additional steps. Link please. So far, it has been working fine. QUESTION: Why is there this warning on python 2.6.2 . Is it really likely to break if I start exercising TG2 ? Should I downgrade to 2.5? Is there something else I should do in order to stay at 2.6.2 ? This makes little sense really, the only reason why TG couldn't work in 2.6 is for the lack of precompiled eggs which is really a user can't compile code problem. There is no reason for TG not to work with 2.6, in fact several people have been working with 2.6 Thanks --~--~-~--~~~---~--~~ 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: GSoC Final Report : TG2 Geospatial Framework
On Mon, Aug 17, 2009 at 5:53 PM, Sanjiv Singhsinghsanj...@gmail.com wrote: Hi TurboGears community, Summer of Code for 2009 ended today Highlights of the TG2 Geospatial Project are: GeoAlchemy -- GeoAlchemy[1] is a sqlalchemy extension for spatial databases. It provides an ORM layer for gis data using python / wsgi software. GeoAlchemy-0.1 was released yesterday and has been receiving some publicity[2]. A TG2 app using geoalchemy is hosted[3] for demo. GeoAlchemy Datasource for FeatureServer - FeatureServer[4] is a python GIS server for storing, manipulating and querying gis features in a variety of data backends using Web Feature Service. A new datasource for featureserver has been written using GeoAlchemy. This will allow web frameworks / applications using sqlalchemy to make use of featureserver easily. The datasource has not yet been contributed to featureserver but it can be used by importing from tgext.geo.featureserver. FeatureServer Controller for TG2 --- tgext.geo now has a FeatureServerController. The controller does two things (a) processes config parameters from tg.config, and (b) dispatches requests to featureserver using featureserver api. A tutorial for using FS with tgext.geo and geoalchemy datasource is in docs repo. A copy of this is in the geoalchemy docs[5] too. I thank my mentor Mark Ramm and the entire TG community for their support and encouragement. regards Sanjiv Singh [1] http://geoalchemy.org/ [2] http://sgillies.net/blog/928/geoalchemy , http://benjamin.chartier.free.fr/pro/?p=1469 and http://tinyurl.com/ol37cx [3] http://demo.geoalchemy.org/ [4] http://featureserver.org/ [5] http://geoalchemy.org/featureserver.html Great news, I'm going to take a look at this to see if I finally start that GIS project I want to get my friend into (he is a geographer and still stuck in desktop land) --~--~-~--~~~---~--~~ 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: Suggestion about how turbojson handle SQLAlchemy object circuit.
On Fri, Aug 14, 2009 at 11:45 AM, David Broudydbro...@threeaspen.com wrote:
On Aug 13, 2009, at 8:32 PM, Jorge Vargas wrote:
Umm this is interesting AssociationProxy is an extension that doesn't
follow the _sa_ convention. And I agree this is a rather simple patch.
In fact it should be as simple as adding a new function to
http://svn.turbogears.org/projects/TurboJson/trunk/turbojson/
jsonify.py
will you work on a patch + test for it? I don't have any models around
that use that extension.
Yeah, I should be able to do that next week. Though looking at 2.1 (or
2.0 for that matter) I don't think it can be done in a function, but
is a one line change to the existing conditional.:
if not key.startswith('_sa_') and not
key.startswith('_AssociationProxy_':
that will be the fix for TG2.1 for 2.0 you will need to add the
function to TurboJson I think you confused both implementations.
Are there instructions to get a source environment for 2.1 anywhere,
or is it just as simple as replacing subversion with mercurial from
the 2.0 docs?
Right, that hasn't been updated yet. You could just do the mercurial
checkouts or you can fork and request for a pull later.
Now as I said that has been removed (although an equivalent
implementation could be set in place for 2.1, the question is do we
want it?) the proper way will be to subclass the Encoder here and (for
now monkey patch L39: _instance = GenericJSON()) to put in your
modified instance. Suggestions on how to make that better are welcome.
I'm not familiar with what monkey patch L39 references. As far as
making is easier to subclass,
you need to tell TG to use your class currently there is no way of
doing that. Therefore you will have to do something like this in your
code.
tg.json._instance = YourJSONClass() -- that is referred to as monkey
patching. Because you are changing the behavior of a module from
outside the module which in some cases could generate very bad things.
In this case it is safe but not nice coding.
I think some additional callback to
deal with relationships would be extremely helpful, and save the
inheritor from having to reimplement the entire is_saobject(obj)
condition, including filtering out of private SA attributes, which may
be subject to change.
This is correct it has changed a lot (take a look at TurboJson) but
since TG2 depends on SA0.5 we can safely ignore those for now. THe
check for SA will probably evolve if SA0.6 changes the way we can
detect it's non-column attributes.
Just implementing your own default won't do it,
because the key is skipped before the value.
I'm sorry I don't get this? you mean is_saobject returns false for
your extension?
Actually, what about
moving the startswith _sa_ check to it's own function that could then
be overridden? That would allow derived classes to exclude at the
field or relationship level, using the key, while still calling
through to the super class that can implement the private key
behavior. Is that what you meant by a new function above? If so, I
guess it just took me a little while to get there :)
adding a callback could be a good idea. What we need to be careful is
that if you overwrite that call you won't overwrite everything else.
I suggest you start by coming up with a check to filter out the
AssociationProxy, then evolve that into something that will check for
SA too, with that we can figure out which is the best way to integrate
it back into json.py
--~--~-~--~~~---~--~~
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: using raw post data
On Fri, Aug 14, 2009 at 4:23 PM, Sanjiv Singhsinghsanj...@gmail.com wrote:
Hi,
I am trying to use a wsgi app with tg2 which uses post data obtained
by environ['wsgi.input']. But the tg2 middleware stack is urlencoding
the data.
A simplified controller method to show this:
�...@expose()
def read(self, **kw):
environ = request.environ
length = int(environ['CONTENT_LENGTH'])
post_data = environ['wsgi.input'].read(length)
return str(kw) + \n + post_data + \n
This returns
{'{type: Feature, id: 29, properties: {road_name: Peter
Road}}': u''}
%7B%22type%22%3A+%22Feature%22%2C+%22id%22%3A+29%2C+%22properties%22%3A+%7B%22road_name%22%3A+%22Peter+Road%22%7D%7D=
Is there a way to to prevent this encoding?
I believe it's request.body and request.body_file I always forgot take
a look at http://pythonpaste.org/webob/index.html#request
regards
Sanjiv
--~--~-~--~~~---~--~~
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: Redirect
On Wed, Aug 12, 2009 at 6:53 PM, Carlos Ribeirocarribe...@gmail.com wrote:
My 0.02 cents - not that anyone asked :-)
I agree that redirect() looks cleaner, but I personally dislike magic
exceptions happening at my back. It's not clear why does it break the
execution flow. Using raise does not look as fancy but seems to me to be
the the right thing to do.
That's a valid point. But who says redirect is an exception in the
first place? I mean it is implemented as an exception but it really is
a method call to another controller. So yea it's a matter of tastes.
On that same camp using redirect() opens the possibility for a future
implementation that is not an Exception :)
But that's just my opinion.
Carlos Ribeiro
On Wed, Aug 12, 2009 at 03:35, Jorge Vargas jorge.var...@gmail.com wrote:
On Wed, Aug 5, 2009 at 12:20 AM, El Teathe.el@gmail.com wrote:
In TG1, the only redirects I ever saw were handled as exceptions. In
TG2 I've seen two forms:
redirect('/somewhere')
raise tg.redirect('/somewhere')
Is there a right time to do one vs. the other? Is one more correct
than the other? One thought I've had is that the raise may be used if
you want to indicate that any database transactions from that request
should be discarded (I think this is done on exceptions).
both are ok.
The second one was to keep compatibility with TG1, I use
redirect('foo') as it is shorter (in the back it's doing the exception
thing)
Thoughts?
--
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: carribe...@gmail.com
mail: carribe...@yahoo.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
-~--~~~~--~~--~--~---
[TurboGears] Re: Suggestion about how turbojson handle SQLAlchemy object circuit.
On Fri, Jul 24, 2009 at 6:37 AM, Diez B. Roggischde...@web.de wrote: 一首诗 schrieb: That sounds reasonable. But, for your facebook example, there is another problem. If we don't want to get these 4000 thousand friends, we have 2 choices： 1. don't use relationship of SA to use the default encode mechanism of turbojson 2. write a customized __json__ I think, the 1st choice is not acceptable in most cases, but the 2nd one is also annoying when we have more than 40 tables. So, how about this : Find a way to mark fields of an object that should be skimmed when encode it to JSON. But the __json__-method is exactly such a spceification. And both the __json__-method as well as any declarative approach you suggest (which would be *very* hard to implement for us, because its's SQLAlchemy/SQLObject that we'd need to change) are IMHO to limited anyway. Because there might be occasions where I different json-representations for the same classes. So instead, I suggest you familiarize yourself with the simplejson API. There you can declare custom serializers, and if you want, write one that knows how to fully traverse an SA-object and it's relations. This could be very well a recipe in the docs - but I don't think it's justified to be included in the core, as the need for customization is very high so everybody will have to write json-encoders anyway. I agree with Diez on this. pulling everything in is bad and putting too little is also bad. __json__ was invented for these cases. Now could you please explain why 40 tables = 40 __json__'s ? Sorry to say this but if you have back and forth relationship to everything then there is something wrong with your DB design instead of the json layer, a those joins will be painful and your network objects (size of the json data will be huge). --~--~-~--~~~---~--~~ 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: Suggestion about how turbojson handle SQLAlchemy object circuit.
On Fri, Jul 24, 2009 at 12:19 PM, David Broudydbro...@threeaspen.com wrote: On Jul 24, 2009, at 4:20 AM, 一首诗 wrote: we have 2 choices： 1. don't use relationship of SA to use the default encode mechanism of turbojson 2. write a customized __json__ I think, the 1st choice is not acceptable in most cases, but the 2nd one is also annoying when we have more than 40 tables. There's at least one other choice: Use the jsonify.when decorator. If you can define your criteria using hasattr instead of isinstance, then this should be less tedious than defining __json__ on every class. Sorry, I don't have an example of this I can post, as it was easier in my case to just use __json__ In fact, I'm not sure where the decorator is documented, but looking at the source it's pretty obvious, and it's just a thin wrapper of prioritized_methods.prioritized_when anyway. Hope that helps. That behavior is stripped in TG2.1 mainly because no one really used it. And getting rid of ruledispatch was a big deal. Currently the code has no alternative. Your solution for this problem could work with the when decorator but I don't see it as the best solution. Which criteria will you use to strip all unwanted attributes from all objects? It seems to me like a very big set of hasattr check that will return false on all objects that don't have it and only true on a flew that do. Wouldn't it be better to subclass the serializer and do things from there? again which will be the criteria? Will anyone come up with an example where this is needed? Back to the original point I seriously doubt you will need that many __json__ methods and I also doubt there is a generic way to serialize relationships that will make everyone happy. Dave Broudy Three Aspen Software 2922 Evergreen Pkwy, Suite 311 Evergreen, CO 80439 Email: dbro...@threeaspen.com // Web: http://www.threeaspen.com Office: 303.278.0908 // Fax: 303.500.3112 AIM/YIM: dbroudy --~--~-~--~~~---~--~~ 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: Suggestion about how turbojson handle SQLAlchemy object circuit.
On Thu, Aug 13, 2009 at 2:25 AM, ob1.dataob1.d...@gmail.com wrote: I'm a newbie, so don't quote me on this but I think I read somewhere that JSON does not scale well. So I think the alternative of using XML encoding to serialize might be better. that isn't really true. Almost every json string will be smaller than the XML equivalent. The only exception is some deformation (which by the way somehow breaks the idea of XML) that some protocols do, for example the webservices defined by WSGI have some optimization where you can extract a set of the XML and replace it with a reference then put that set below in the XML stream which saves you space because the block of code is only one time in the steam and you have several references to it. That in itself has two mayor problems. 1- It break the concept that XML is human reable, because it breaks the flow and more importantly 2- It means your data model is broken! Why do you want to store the same information twice in the same stream?? Also, I think you need Elixir installed on top of SQLAlchemy to handle M:N relationships in the traditional fashion. Then maybe it'd be simpler. huh? have you used sa declarative? I think you are confusing active record (what you call traditional) with data mapper (SA's way) --~--~-~--~~~---~--~~ 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: Critical security update for tg2 users!
On Wed, Aug 12, 2009 at 10:38 PM, El Teathe.el@gmail.com wrote: The biggest problem with answering this is that you may be doing bad things that are complete away from TG. For example there is no way for TG to validate that you are not storing creditcard data in your database. I could really use a pointer to a set of documentation somewhere that lists all the requirements for securing my site. I would think it would include changing this secret, getting the site out of debug mode, and maybe even validating every form (even if you don't assign a validator to a field - which I am hoping escapes injection attacks). Injection attacks are something that is caught at the SA level. In theory it's query builder and object layer will catch all attempts at it. I say in theory because a bug may be found or you could be using sqlalchemy.sql.TEXT I expect TG is used by many professionals - but many people like myself as well, who are not well experienced in web architectures and SQL. That's why I use TG - to abstract away and simplify, but I feel like it may leave my site and/or database open to vulnerabilities because I don't grasp all the nuances. Sadly this is not a TG issue. And even though I agree TG should tell you all you need to do to close the holes TG opens we can't tell you how to close the holes you open. My previous approach was to buy Mark's book - and it was great, but I've since moved on to TG2. Is there any page of mandatory steps and best practices to properly secure a TG2 site? I don't think there is. That should be a chapter on the deployment guides. Mike On Aug 12, 9:47 am, Antoine Pitrou antoine.pit...@gmail.com wrote: On Aug 12, 3:16 am, Mark Ramm mark.mchristen...@gmail.com wrote: You can also set it in development.ini using a key like: sa_auth.cookie_secret = mysupersecret In [app:main] I assume? --~--~-~--~~~---~--~~ 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: Suggestion about how turbojson handle SQLAlchemy object circuit.
On Thu, Aug 13, 2009 at 1:28 PM, David Broudydbro...@threeaspen.com wrote: On Aug 13, 2009, at 2:12 AM, Jorge Vargas wrote: Your solution for this problem could work with the when decorator but I don't see it as the best solution. Which criteria will you use to strip all unwanted attributes from all objects? It seems to me like a very big set of hasattr check that will return false on all objects that don't have it and only true on a flew that do. Wouldn't it be better to subclass the serializer and do things from there? again which will be the criteria? Will anyone come up with an example where this is needed? The case I was working with was serializing the lists from an AssociationProxy. I'm pretty new to TG, but it seems to me the default behavior isn't great, at least in TurboJson 1.2.1, skipping keys starting with _sa_ but including the private _AssociationProxy_* collections, which aren't really in a usable format. I think it should either skip the private proxy collection too, or include it in a usable form. Undoubtedly skipping it makes more sense as a default behavior. Maybe this is really a SA issue, because not all of their private keys start with _sa_, but it seems easy enough to fix at the turbojson level. Umm this is interesting AssociationProxy is an extension that doesn't follow the _sa_ convention. And I agree this is a rather simple patch. In fact it should be as simple as adding a new function to http://svn.turbogears.org/projects/TurboJson/trunk/turbojson/jsonify.py will you work on a patch + test for it? I don't have any models around that use that extension. My model only had one class that used an association proxy, but if you had a bunch of classes that had a reasonably finite set of objects in an association proxy (say 10 keywords each), I think that's a use case that justifies a global way to do it for a given project, such as the when decorator. And if they were all called keywords, then it's only one hasattr to check. I hadn't thought about subclassing the whole serializer. I think that's a little bit more intimidating, but like I said, I'm pretty new to TG, so I'm still trying to absorb it all. In my case, subclassing would have made sense, because I wanted to take out something (_AssociationProxy_* keys) and I couldn't figure out how to do that in a when decorator without basically overriding the whole process anyway. In TurboJson this will be done with a simple jsonify.when decorated function that will magically get called by TurboJson. As explained here http://docs.turbogears.org/1.0/JsonifyDecorator Now as I said that has been removed (although an equivalent implementation could be set in place for 2.1, the question is do we want it?) the proper way will be to subclass the Encoder here and (for now monkey patch L39: _instance = GenericJSON()) to put in your modified instance. Suggestions on how to make that better are welcome. So in summary I believe subclassing GenericJSON + telling TG to use your version is WAY simpler than having someone go try to understand generic functions and then implement one. Back to the specific case I really believe this should be patched into tg2.1 and TurboJson as AssociationProxy needs to be filtered (at least by default) just like every other SA relation. I think the decorator syntax is nice and clean, and the best examples are in TurboJson it self: datetime, decimal and explicit. Presumably those are handled in TG 2.1 as well, so hopefully there's a nice way to subclass and override similar types of objects, such as a duration or a currency. yes indeed the functionality is 99% equivalent the only thing missing is the when, the problem is that the old implementation used generic functions which well created a ton of dependencies and did not bring in a lot. I know it sounds like a lot but pretty much all of TurboJson was replaced by one 50 lines file http://hg.turbogears.org/tg-21/src/tip/tg/jsonify.py which is equivalent and I'm pretty sure it's faster. --~--~-~--~~~---~--~~ 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: [TurboGears] Critical security update for tg2 users!
On Tue, Aug 11, 2009 at 9:16 PM, Mark Rammmark.mchristen...@gmail.com wrote: We recently discovered that TurboGears2 ships with quickstart configuration that leaves users of it's default user authorization/authentication scheme vulnerable to a serious security issue. If you are running a TG2 application in production you are strongly encouraged to set the cookie salt for the authorization cookie in repoze.who to something other than it's default value. This is simple enough to do, just set base_config.sa_auth.cookie_secret to any secret value you'd like. For example: base_config.sa_auth.cookie_secret = mynewsecret You can also set it in development.ini using a key like: sa_auth.cookie_secret = mysupersecret Failure to do this could leave you vulnerable to someone who knows the default cookie secret being able to craft a cookie that allows a user into your site without authenticating through the normal mechanism. TurboGears 2.0.2 will enforce setting the cookie secret and will refuse to run if you have not set that value in your configuration. We've just released 2.0.2, which also fixes another security issue which could cause controller methods decorated with something other tha...@expose to still be exposed through the url dispatch mechanism. You can update to 2.0.2 with easy_install -Ui http://turbogears.org/2.0/downloads/current/ turbogears2 Small correction, on my linux box you need easy_install -Ui http://turbogears.org/2.0/downloads/current/ TurboGears2 note the caps. -- 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-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 installation and underlying components version problem.
On Mon, Aug 3, 2009 at 8:50 PM, Jdjdsw2...@yahoo.com wrote: From what I gather, TG2 installation puts together a bunch of cool projects together in the right way for them to be extremely useful. We have chosen it for our project. Now the problem is that we would like to freeze these components that it come with. Everytime I install a new tg2env and TG2 in from the instructions, I get different version of the stuff. Also these seem to differ on different linux distributions (CentOS, Fedora, Ubuntu etc) We would like to have one environment that refers to specific versions of the underlying components. What we would like to see is... -- TG2.0 -- component1 (v2.2), component2 (4.5.3) -- TG2.1 -- component1 (v2.3), component2 (4.5.3) Is my understanding off ? Any suggestions or more explanation on how things are put together ? another solution for this is to use pip and it's requirements.txt feature. Thanks /Jd --~--~-~--~~~---~--~~ 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: TG2 now available in Debian
On Fri, Aug 7, 2009 at 5:55 AM, Stefano Zacchiroliz...@debian.org wrote: Hi all, since yesterday, finally all the TG2 stack is available in Debian. It is currently in the unstable suite, but if no additional problems will arise it will soon be part of the testing suite as well, ready to be released. If you're using Debian unstable, getting started with TG2 application development is then a matter of: # apt-get install python-tg.devtools it is recommended to install all Recommends: packages (which apt does by default) to have a reasonably complete development environment. If you only need to run TG2 applications (i.e. you do not need the development tools) then installation instructions are: # apt-get install python-turbogears2 If you have specific question on the packaging do not hesitate in contacting me directly (I follow this list, but only sparingly) or, as usual, file a bug report in the Debian bug tracking system. I would love if you could add to the turbogears website the above information on how to use TG2 in Debian and derivatives distribution (including Ubuntu). awesome news. Many thanks in advance, Cheers. --~--~-~--~~~---~--~~ 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: [TG2] ForeignKey could be empty with SA?
On Tue, Aug 11, 2009 at 2:05 PM, matigromati...@gmail.com wrote: On 30 jul, 05:51, Marko Springfeldt ma...@springfeldt.de wrote: SQLite does not support foreign key constraints and SQLAlchemy dose not check the integrity of the database. Hi Marko, thanks for replying. I'm reading your suggestion. Just a question. In TG1 with SQLObject and SQLite there is relational integrity. Who is controlling it? SQLObject checks this and send an Exception? SO had some validators with formencode, which I believe did it. If you want to know for sure I suggest you ask in the SO list. Thanks. Matías --~--~-~--~~~---~--~~ 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: Redirect
On Wed, Aug 5, 2009 at 12:20 AM, El Teathe.el@gmail.com wrote:
In TG1, the only redirects I ever saw were handled as exceptions. In
TG2 I've seen two forms:
redirect('/somewhere')
raise tg.redirect('/somewhere')
Is there a right time to do one vs. the other? Is one more correct
than the other? One thought I've had is that the raise may be used if
you want to indicate that any database transactions from that request
should be discarded (I think this is done on exceptions).
both are ok.
The second one was to keep compatibility with TG1, I use
redirect('foo') as it is shorter (in the back it's doing the exception
thing)
Thoughts?
--~--~-~--~~~---~--~~
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: Is there an initialization callback for a TG2 app?
On Tue, Aug 4, 2009 at 2:18 AM, gizlimehm...@gmail.com wrote: Hi all, My TG2 app has to run a bunch of worker threads in the background to do very specific tasks. I want to write a function to start these threads every time paster starts serving my application. Essentially, I need an initialization hook for my app. I did see the make_app() function inside middleware.py.. It seems like the right place to put this initialization code. Any ideas? There is one but it's not document yet http://trac.turbogears.org/ticket/2117 doc patches welcome :) Thanks. --~--~-~--~~~---~--~~ 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: sphinx error(s) while building TG2 docs: webob
On Mon, Jul 6, 2009 at 11:26 AM, Stefano Zacchiroliz...@debian.org wrote: On Jul 6, 4:51 pm, Michael Pedersen mjpe...@gmail.com wrote: Which version of Sphinx are you using? I found errors with 0.6.x that are only corrected by going to the still in development 0.6.3. You can get/install it from the Mercurial repository here:https://bitbucket.org/birkenfeld/sphinx-06/ I'm using 0.6.2. Even if it is fixed with 0.6.3, I'm building the doc for the corresponding Debian package, which should be buildable with the packaged version of sphinx, i.e., released versions. For the moment I'll stick with my workaround which basically empties the webob lines, if you have better fixes ... they are more than welcome :-) This was a bug that was fixed during pycon and reintroduced later by a bad merge :( From back then I know 0.6.0dev had the fix so you may want to try with 0.6.0 or 0.6.1 --~--~-~--~~~---~--~~ 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: New Json renderer on tip and question regarding it's flexibility
Hello, Just a quick reminder of this. Any opinions on it? if not I'll
choose option A
On Sun, May 24, 2009 at 1:03 AM, Jorge Vargasjorge.var...@gmail.com wrote:
Hello Guys,
I just wanted to let you know I pushed the json stuff to tip[1], which
has a minor backwards incompatibility with older quickstarts, if you
upgrade you will see this error.
MissingRendererError: The renderer for 'json' templates is missing.
Try adding the following line in you app_cfg.py:
base_config.renderers.append('json')
which despite it's obviousness, someone asked me what's up? so read
this and add that line.
I'll committed a patch so newer quickstart will have json on by
default.[2] Please note this introduces a broken tests, see below.
My last question regarding this ends up at how permissive should it
be. So far our json renderer will automagically render any object that
- has __json__ and it's a callable
- is of type date,datetime, Decimal, Sqlalchemy class, SA result
proxy, row proxy or.
now we have a final choice here
a- make it call __repr__ and if that fails str(obj)
b- make it fail with an error that the item is not jsonable
c- make it a configurable option.
Currently the code implements b which is why the quickstart will
fail at /environ.json because it doesn't knows how to render a logger
object, this is nice to catch errors But something you just want a
quick valid json string, in which case a seems better.
[1] https://bitbucket.org/mramm/tg-21/changeset/bd8b45a54d91/ to
https://bitbucket.org/mramm/tg-21/changeset/0f59c4073032/
[2] https://bitbucket.org/mramm/tgdevtools/changeset/d924a5326f27/
--~--~-~--~~~---~--~~
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: The future of TurboGears
On Mon, Jun 22, 2009 at 1:13 PM, Derick Eisenhardtderick.eisenha...@gmail.com wrote: On Jun 21, 6:31 pm, Jorge Vargas jorge.var...@gmail.com wrote: To be honest. I don't like that. Every tool that has taken that approach ends ups being bad. Sure we need to make it as much friendly as possible but I don't want this to become the average idiot tool (no offense really) but I guess I do prefer to aspire to the best of us recently someone send me this quote. This users are idiots, confused by functionality mentality is a disease.Think users are idiots? Only idiots will use it Linus Torvalds So please please don't read me as elitist read me as best of breed both in components and users. I have to disagree. For some reason many people seem to think that you have to choose between being user friendly to newbies or powerful for the experienced. You CAN make both parties happy. Also, I know you intended not to sound elitist but talking about best of breed users and that idiot quote from Linus do not help your cause. Assuming someone is an idiot just because they are inexperienced is just about the best way to make yourself sound elitist. :/ Please note that idiotic in this case means someone that doesn't knows/cares instead of a real idiot. I'm not saying it has to be designed for idiots ...but there are currently too many assumptions of prior/external knowledge assumed in the documentation. This is what I was trying to get at. Let me go ahead and reiterate...I love Turbogears, and I have nothing but respect and gratitude for everyone who has worked so hard to give us this wonderful platform. But, we are limitting our user base if you assume your users already know some of these things. I think the problem here is that you keep saying we and you like they are two different sets of people. Of course not all users will become developers. But the we group can do a lot more than just sit back and point. Let's think of it in a usage scenario, generic new user Bob has been developing PHP sites for years, but has decided it's time to check out one of these new MVC frameworks all his friends are so crazy about. He looks at Ruby on Rails and Django, since they are 2 of the most well known first, then he stumbles across Turbogears and likes some of the stuff he sees. I think this comment is totally flawed, so you are saying that to do RoR or Django you don't need to know ruby/python, that is plain wrong. (note this is totally personal) That user is someone I won't waste my time on. That is different from making things newbie friendly. But being as he has no previous Python experience, when he looks at the tutorials and docs he becomes quickly confused by certain parts of the language that he is unfamiliar with. Yes, he could always go do his own independent research, but it would be so much easier, and make him love TG that much more if there was just a paragraph or two mixed in with the current new user docs to help him get past those hurdles without having to search elsewhere. I really don't think the TG docs are the place for you to learn python. I know for me personally, I've had to search out many of my questions on Pylons, SQLAlchemy and other's websites because there was something not documented on the TG site. The whole purpose of a project like Turbogears is to take all the disparate parts and combine them into one cohesive whole. Why do you want to duplicate effort? the SA docs are excellent , the pylons docs are also excellent. Sure when you start you don't know they are there, but after you do they will be there. That said Sphinx is doing wonderful things on this department and we already have API integration of the docs, now we need a better way to have inter-sphinx docs and that work is underway. And this brings me to the JS/widget discussion... If TG were to have a preferred/default JS library it's not that users would be required to use it, it's just that it would be made easy to use and be documented here. If someone wanted to use a different toolkit they'd always be free to use whatever they like, they would just have to research it's use elsewhere rather than on the TG site. other have pointed out that is a field that is still disputed staying neutral (at this point in time) is the best. I look at Turbogears like the web development equivalent of a Linux distribution. There are all these parts out there one can take and glue together, but the distribution takes them all and glues them together for you so you don't have to. Also in the same metaphor you could look at as Pylons is like the Debian to Turbogears' Ubuntu. Going on with your analogy that means the Ubuntu people need to go out and document all of gnome? This is really how we should be treating documentation and bugs. If a bug is found in Turbogears that is a result of one of your upstream components, let's say SQLA for example. You shouldn't mark the bug as won't fix
[tg-trunk] Re: TurboMail 3.0rc1 - real world testing needed
On Fri, Jun 26, 2009 at 3:06 PM, Felix Schwarzfelix.schw...@web.de wrote: Alexandru Marinescu schrieb: Since we are on this. I would like to provide support for both turbomail 2 and turbomail 3. And since there are differences in both configuration and API, is there a way of getting the version of the installed turbomail package? You could use setuptools or just check for example if the message has a send method (which it hasn't in TurboMail 2). Just let me know what you need so I can provide it (though I think TurboMail 3 is so much better and so compatible that I ask people to use TurboMail 3 if possible). +1 I really don't see the point in having TM2 compatibility. fs --~--~-~--~~~---~--~~ 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 trunk testing
On Mon, Jun 22, 2009 at 12:53 PM, Christoph Zwerschkec...@online.de wrote: I see some problems with the current test suite for TG2 (trunk): * The output is cluttered with deprecation warnings: pylons\templating.py:328: DeprecationWarning: pylons.h is deprecated: beaker\cache.py:129: DeprecationWarning: Specifying a 'type' and other namespace configuration with cache.get()/put()/etc. is deprecated. dispatcher.py:...: UserWarning: this functionality is going to removed in the next minor version Tests or code should either be updated or should catch the warnings so that they don't appear in user output. * The following tests are broken for me: ERROR: test_lookup_with_dispatch (tg.tests.test_rest_controller_dispatch.TestTGController) AttributeError: LookupAlwaysHelper instance has no attribute '_setup_wsgiorg_routing_args' ERROR: test_template_override (tg.tests.test_tg_controller_dispatch.TestTGController) TypeError: No object (name: h) has been registered for this thread * If tests in test_stack break, the complete log with all the debug entries is shown, which is sometimes useful, but normally way too much. Can this somehow be switched on and off? I think it should be switched off by default. I've currently no time to work on these problems. Maybe somebody can solve these things, or I am doing something wrong. Those come from pylons, they are fixed in the hg tip for 2.1. I guess we could backport those fixes. -- Christoph --~--~-~--~~~---~--~~ 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.0.1, line 500 at controllers.py
On Fri, Jun 26, 2009 at 3:51 AM, Jeffreyjeffre...@gmail.com wrote: controllers.py, line 500 if hasattr(obj, im_self): klass_instance = obj.im_self else: print obj klass_instance = obj this will cause apache wsgi exception, is this a bug? You are right it shouldn't be there. it was left in by mistake while fixing the security issue we found on RestController (sorry it was late). Fixed in svn r6592 Yours Faithfully Jeffrey Hsu --~--~-~--~~~---~--~~ 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: [patch] no dep on Catwalk if auth support is not requested
Hello Zack or Stefano :p
On Mon, Jun 22, 2009 at 5:52 AM, Stefano Zacchiroliz...@debian.org wrote:
[ please Cc: me on replies ]
Heya, I'm packaging TG2 for Debian [1].
awesome looking forward for that one. Lets see if it's out before
luke's RPMs :)
As a minor nitpick, I've noticed that quickstart outputs a dependency
on Catwalk even if auth support has not been requested by the
user. Out of sync with that, Catwalk is actually used in the generated
code only if auth support has been requested.
The simple attached patch fix this incoherency by avoiding output the
dependency if auth support is not requested. Can you please consider
merging it? The live version of the patch is available at [2].
This is indeed correct, In fact if you saw allow_only = None it will
work but that's encouraging security issues which we don't want.
So yes your patch should go in. I'll make sure it's applied next
saturday on our bugfix day.
BTW, given that auth support implies more dep in the generated egg,
I've also changed the default of auth support to no in the Debian
package, any strong reason for having that default to yes? It was
that way in TG1.
This is something I don't like at all. In fact in TG1 we consider that
default to be one of the bad decisions. So I really encourage you to
make auth = yes by default because this is what the quickstart sets as
default. In TG2 we want to let people know up front this that this is
not a toy framework and defaults reallly matter for this.
TIA,
Cheers.
[1] http://upsilon.cc/~zack/tags/turbogears/
[2]
http://svn.debian.org/viewsvn/python-modules/packages/tg.devtools/trunk/debian/patches/avoid-catwalk-dep.dpatch
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
iD8DBQFKP1R11cqbBPLEI7wRAs9JAKC85X+UaQLbj8lNoMwSSH+fJu8pHwCfYP65
FWS5XW7VibszFXRHlgrDzXA=
=ZLlp
-END PGP SIGNATURE-
--~--~-~--~~~---~--~~
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: Everything there is to know about the current auth/identity in TG2
On Mon, Jun 22, 2009 at 9:39 AM, Gustavo Naream...@gustavonarea.net wrote: Jorge said: you can not use functions if you keep the current allow_only = foo() but if you transform that into allow_only = autorrize(foo()) or something similar that objection is gone. It's the exact same thing: authorize() will receive a True or a False, and it cannot do anything useful with it. ahhh sorry I meant to say authorize(foo) for paramenters you can do authorize(foo,'var','var') -- Gustavo Narea xri://=Gustavo. | Tech blog: =Gustavo/(+blog)/tech ~ About me: =Gustavo/about | --~--~-~--~~~---~--~~ 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: TurboGears 2.0.1 released
On Mon, Jun 22, 2009 at 8:19 AM, micheleDiegolim.dieg...@gmail.com wrote: Hi t all, I've installed tg 2.0.1 on win vista using cygwin. which commands you ran? did you use a venv? did you activate the venv? But the paster --help output is: $ paster --help Usage: paster [paster_options] COMMAND [command_options] Options: --version show program's version number and exit --plugin=PLUGINS Add a plugin to the list of commands (plugins are Egg specs; will also require() the Egg) -h, --help Show this help message Commands: create Create the file layout for a Python distribution help Display help make-config Install a package and create a fresh config file/ directory points Show information about entry points post Run a request for the described application request Run a request for the described application serve Serve the described application setup-app Setup an application, given a config file ... no tg2 tools! Any suggests? Michele --~--~-~--~~~---~--~~ 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] TurboGears BugFix Day Jun-21-2009
Originally we wanted to make this the 2.0.1 release but oh well Activities - Bring your favorite bug (and patch if possible) - Triage of existing bugs - Apply all (acceptable) patches from trac and/or ML - Make it public so people can bring their bug and adopt a bug - Release 2.0.2 - finally shut down write access to the SVN. - apply all proposed fixed and typo's from the sphinx/discus comments to the sources. --~--~-~--~~~---~--~~ 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: Ok, 2.0 is out, what about turbogears 2.1?
On Mon, Jun 15, 2009 at 11:54 AM, Gustavo Naream...@gustavonarea.net wrote: Hello, Jorge said: Anyway, that function would be anything but a predicate. It won't be reusable, it won't be stateless. why it has to be stateless? why not reusable? you are assuming we'll keep doing allow_only = not_autorized() that of course is dumb. something like this could do the job. http://wiki.python.org/moin/PythonDecoratorLibrary#Countingfunctioncalls It must be stateless just because it must be reusable across requests and threads. Isn't that reason enough? If it's a function that returns True or False, then its result is obviously not stateless. in which way a function is not stateless? a function by definition IS stateless. there is no local storage of a function. Did you really read what I said? If it's a function that returns True or False, then its result is obviously not stateless. In other words, *the* *result* of the function (*not* the function itself) is not stateless. That result will be either True or False, which is a *constant*, and the evaluation of an object cannot depend on a constant! As a consequence, its result could not be used in @require or .allow_only -- it will be True or False forever, whatever the requests, because it would be evaluated when the module is loaded and will remain constant from there on. not really. If you make a decorator that will evaluate on each call it will serve the same purpose. Although I agree the syntax will need to be changed. What are you going to evaluate, if what is left is a bool? (see below) why do you assume the call is going to be made on module load? Maybe because it's one of the basic things you first learn in Python? Try this simple experiment if you don't believe me: Create a module which has the contents below: class MockObject(object): def __init__(self): print Initialized class CoolController(object): allow_only = MockObject() def my_action(self,): pass my_action.predicate = MockObject() Now try to import it from another module (just import it, don't do anything else) and tell me what you got. Next, guess why you got that. Hint: Anything that is outside a function/method is evaluated when the module is loaded, even decorators and their arguments. did you missed the part where I said that syntax will need to change? we'll need something like allow_only = autorize(MockObject()) The other similar thing would be to wrap the predicates around functions which return True/False. But it wouldn't be a good idea either: 1.- You'd need one of those functions per predicate. why? first of all the predicate will be become the functions instead of the class. Second with just one decorator you can do this. Remember a decorator can keep state 2.- It could be dangerous. They should only be used *inside* the controller action (i.e., inside the method, never outside) or in the templates. This is, they must not be used in .allow_only or @require, for example. see below 3.- You'd have to instantiate them on each function call, which would be inefficient: def has_permission(permission): predicate = repoze.what.predicates.has_permission(permission) return predicate.is_met(request.environ) if it's a function it doesn't needs to be instantiated, seems like you missed the point a predicate will be a function not a class and you will have 3-4 decorators that will provide the is_met, allow_only and require functionality. What you propose is simply unrealistic: If you replace predicates with functions that return True or False, what the decorator will receive will be a True or False. The decorator won't be able to evaluate anything. The closest thing you could do, is to use it as callable in the @require and call it in the controllers: @require(predicate1) @require(predicate1,param1,param2) def my_action(self,): if predicate2(): pass I'm willing to put on that sacrifice for a cleaner query API. after all I believe you do more queries on auth than calls to require/allow_only And that would be wrong too, because then predicates won't be able to receive arguments: @require(has_permission(foo)) # -- @require received True or False when # the module was loaded and this value # won't ever change why do you keep thinking the function will be evaluated on module load. the function will be called! by require on each call to the function. You're totally mistaken. def my_action(self, ): if predicate_foo(): # here it will work pass Now let's imagine that somehow it's possible what you say, that the predicate could keep track of the status: Am I talking Chinese? the predicate doesn't need to keep track of anything when I said that? it will simply read for the env and return true or false.
[tg-trunk] Re: The future of TurboGears
On Wed, Jun 17, 2009 at 4:10 PM, Derick Eisenhardtderick.eisenha...@gmail.com wrote: So, TG2 finally has a stable release. However, it's release has sadly come out to little fan fare as far as most of the web is concerned. I'm worried by the current state of advertising/marketing and documentation, that what there is available currently has very little appeal to the majority of web developers out there. For TG2 to make any real traction it's going to have to appear to be the best of breed web development environments. As far as I can tell the only folks currently interested are those of us who have previously been using TG1, are hard core python fans, or are already sold on the idea of distributed/modular development (WSGI). That unfortunately leaves Turbogears with a somewhat niche audience. Django grew it's user base by advertising to people that it was the best, easiest to learn and use web development platform and better than Ruby on Rails. Their community seems to still be growing at rapid rates, while I've seen hardly any difference in new users around here since TG2 went final. At the end of the day, the average web developer doesn't care what platform they're using, or how it works...they just want the quickest and easiest method to get what their site running and doing what they want. Currently, TG2 still has a good bit of a learning curve. And I'm sorry to burst anyone's bubbles, but we DO NOT in any way shape or form have the best documented web development platform. And until it's retardedly easy for someone who has never programmed in Python, barely ever used the MVC model before, and knows nothing of command lines to jump in and make their first TG site in less than an hour, it's going to remain a niche audience. To be honest. I don't like that. Every tool that has taken that approach ends ups being bad. Sure we need to make it as much friendly as possible but I don't want this to become the average idiot tool (no offense really) but I guess I do prefer to aspire to the best of us recently someone send me this quote. This users are idiots, confused by functionality mentality is a disease.Think users are idiots? Only idiots will use it Linus Torvalds So please please don't read me as elitist read me as best of breed both in components and users. Beyond that our site is a bit of a joke currently. We're not even self hosting as far as I can tell. Now I know there's http://beta.turbogears.org out there, and I know folks are working on the Pages CMS. But we really should have had all that up before 2.0 went final. It's truely amazing how much a person will judge you're product simply on the the looks of your website alone, especially when the product is a web development platform. I totally agree and I did my best to try to get that working, (jon1012, faide and me worked to get that done) but as Mark said we all have day and consulting jobs. TG2 the software was ready pre-pycon but the new site wasn't. The decision was made to ship the product because the damage from people judging for a bad site was less than from people thinking TG2 was vaporware. TG2.0 was delayed several month 2-3 for the infraestructure to ca Anyway at this point in time beta.turbogears.org is usable and people should be able to request for an account and work on it. Furthermore, ToscaWidgets is dead in the water as far as I can tell and it's widget selection is sparse at best. I have to disagree, releases are made and the infrastructure is there to make all the widgets you want. It is absolutely imperative that TG have a full-featured widget toolkit built-in by default and it be just as well documented as any other aspect of the platform. Actually it comes with 2 ToscaWidgets and webhelpers. TG1 had fairly good integration with MochiKit, but TG2's current stance appears to be you can either use this basic Tosca stuff someone threw together and then let stagnate for a year, or go out and find a real widget library (jQuery, Dojo, etc), but you'll have to figure out how to use it by yourself. And that is the exact opposite of the position we should be portraying to new users...if people want that situation, why not just use plain ol' Pylons? Note I do believe (please check the archives) that TW wrappers for JS libraries are a bad idea. I think you are confused about the role of TW. and a widget library if you want ajax widgets then YES! go learn the JS library you want. There is nothing you can and should do on the framework to integrate a JS library other than doing magical stuff. ToscaWidgets is a forms library, you shouldn't think it's more than that. I think the decision to be JS agnostic for TG2 was a good thing it means you are able to put anything you want! for the client site. Remember most mid-big project the guy working JS is probably a different one tha the one doing backend stuff. As long as you throw json out for those parts you will be fine :)
[tg-trunk] Re: The future of TurboGears
On Wed, Jun 17, 2009 at 8:05 PM, Anthony Theocharisanthony.theocha...@gmail.com wrote: Hear Hear. I was glad to read your concerns, Derick, and find that they generally echo my own. As a developer, I'm very interested in the current state of TG, as well as in growing a thriving community. There's been talk around my office of trying to give the TG site a facelift, but we're swamped with work right now, so it won't be right away. by all means, we need content for beta.turbogears.org and I got 2 feature pending for it that will allow us to have a sane sites running on TG and suggestions and fixes. If you are really interested in this please send me and email and I'll get you credentials. I've looked at some of the refactoring going on in 2.1, and I'm pretty impressed with it. Looks cleaner than the 2.0 branch, avoids some of the confusing situations that lead to bugs. But Derick's right: there's too much left unpolished in 2.0 right now. This is the main reason why dispatch was refractored in 2.1, ChrisP made the conclusion that the bugs where based on a bad design and I agree with him, after having to go in there to fix/spot some bugs. For instance, I've noticed (after spending the last week debugging issues introduced with 2.0 final) that there are no tests for most of the Routes features. As a result, two separate patches broke bits of routing functionality between 2.0RC1 and 2.0. Another recent patch passed all tests, but caused all tw.forms widgets to render escaped xhtml. links? so this means 2.0.1 fixes the things? Is anybody focused on fixing bugs in the 2.0 branch? yes, just take a look at 2.0.1 it had several bug fixes that we applied, in fact take a look at the announcement I just made for the bug fix day next saturday (jun-27) please please bring all your bug and patches :) Is anybody focused on keeping the web site up to date? yes and no. I volunteered for the architecture, and Jon and Mark where going to get the content but we have all been very busy, right now everything is near 50% complete. Do we have 'official' repositories for 2.0 and 2.1? (Different posts link to different tags on the 2.0 svn, and the bitbucket for 2.1 isn't linked to from turbogears.org.) Official packaged distributions? We are in the transition from svn to hg (in case you did not know) Currently it goes like this. official 2.0 http://svn.turbogears.org/branches/2.0 official 2.1 http://bitbucket.org/mramm/tg-21 eventually they will all live at hg.turbogears.org I love TurboGears, but it's hard to explain to newbies why (even harder than explaining the related delays to clients!). The learning curve is too steep, right now, with incomplete or out-of-date documentation, and no official looking / easy to navigate resources. it is indeed hard to explain to a client that the tool is better, most clients just go for the most popular which leaves us with a ton of php apps :( To be fair, the current documentation is way better than the 1.0 docs were, but, like Derick said, Django's still got us beat by a long shot. I'm reallly looking forward for http://groups.google.com/group/sphinx-dev/browse_thread/thread/b88fffe1e6693535 This will imprpove the feedback on the docs the most. Currently the docs are written on a I need this let me contribute it matter, and it also has the problem of advanced users don't know how to think like newbies The one thing I would disagree with Derick on is the inclusion of a Javascript library with our widgets. I don't think TG2 should be tied to any JS library. I think that adding unobtrusive javascript to a page using any combination of decent Widget and JavaScript libraries is a relatively trivial accomplishment for any programmer savvy enough to know those words mean. I feel like this differs from including, say, a default Widget set, or default Templating Engine, in that including a javascript/css file into a template is a much more transparent process, and easily grokked by a new developer. But I'm sure this is a discussion that's already been had. +1 Anticipating an interesting (and informative?) thread of discussion, Anthony On 17-Jun-09, at 1:10 PM, Derick Eisenhardt wrote: So, TG2 finally has a stable release. However, it's release has sadly come out to little fan fare as far as most of the web is concerned. I'm worried by the current state of advertising/marketing and documentation, that what there is available currently has very little appeal to the majority of web developers out there. For TG2 to make any real traction it's going to have to appear to be the best of breed web development environments. As far as I can tell the only folks currently interested are those of us who have previously been using TG1, are hard core python fans, or are already sold on the idea of distributed/modular development (WSGI). That unfortunately leaves Turbogears with a somewhat niche audience. Django grew it's user base by
[tg-trunk] Re: TurboMail 3.0rc1 - real world testing needed
On Tue, Jun 16, 2009 at 3:10 AM, Felix Schwarzfelix.schw...@web.de wrote: Hi, yesterday I published the first release candidate of TurboMail 3.0. As the status 'release candidate' implies this release *should* be stable enough to be used by normal users. TurboMail 3.0b2 got quite some testing by various users and we found some interesting bugs during the process. Now we need even more real-world testing to get a rock-solid final release! I uploaded the files to http://www.schwarz.eu/opensource/misc/2009/turbomail/ until Alice can put them on the TurboMail webspace. Changes since beta2: - 'mail.smtp.count' was renamed to 'mail.smtp.max_messages_per_connection' to reflect the semantics better, default was lowered to 1 to prevent log warnings about disconnects - 'mail.tries' was renamed to 'mail.message.nr_retries' - Reworked UTF8qp extension which is now only necessary for backwards compatibility. We have a separate, less intrusive 'UTF8qp' charset which can be used for quoted printable encoding without the extension. - SMTPTransport always sends ehlo (report with patch by akalias) - SMTPTransport is more robust in case of connection drops (reported+initial patch by Ethan Frey) - Fixed a couple of bugs in the Pylons adapter (reported+diagnosed by little wiki) - Configuration option for message encoding is now 'mail.message.encoding' (was 'message.encoding') to provide a consistent naming (reported by Domen Kožar) - HTML documentation is included in the release tarballs Roadmap to 3.0: - Give that release candidate 2-3 weeks of field testing - release new versions if serious bugs are found - write release notes for 3.0 - Remove all pointers to the old svn in trac - Rework trac pages so that they reflect the current status - Find a way to push updated docs to the website. Hello Felix, awesome work on this extension. I just love all the features you guys pumped into it. Great work! I just wanted to point out that Alex from GSOC is on the last bits of tgext.registration which uses turbomail for it's confirmation emails, and I'm sure we'll give this a really nice 'real world' test with that. fs --~--~-~--~~~---~--~~ 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: The future of TurboGears
On Wed, Jun 17, 2009 at 4:10 PM, Derick Eisenhardtderick.eisenha...@gmail.com wrote: Beyond that our site is a bit of a joke currently. We're not even self hosting as far as I can tell. Now I know there's http://beta.turbogears.org out there, and I know folks are working on the Pages CMS. But we really should have had all that up before 2.0 went final. It's truely amazing how much a person will judge you're product simply on the the looks of your website alone, especially when the product is a web development platform. Sorry forgot to say this. We currently have a dedicated server which runs: beta.turbogears.org gsoc.turbogears.org www.toscawidgets.org It also has a pypi, trac and builbot that are not on use. The idea is to move everything to that box and in the process do the svn-hg migration. Also note that our 3 GSOC projects, actually just 2 of them are aimed at infrastructure. Alex's project (which I mentor) is aimed at building the HG and other components (registration,profile,etc.) and ChrisP student Jesse is working on buildbot. Please note that none of these are installations they are actually building component to simplify both project with webUIs to be released as components for everyone to use on their sites. I want to say ones more that I reallly wanted the new site to be up for the 2.0 release but I was convinced that we where better off with a shipped product and no site than with neither of them. --~--~-~--~~~---~--~~ 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: TurboGears 2.0.1 released
2009/6/21 biomatrix2008 biomatrix2...@gmail.com: easy_install -U paster quickstart xxxto create a new project cd xxx python setup.py develop paster setup-app development.ini error show need zope.alchemy easy_install zope.alchemy error show need babel easy_install babel error show need catwalk easy_install catwalk then no error run paster setup-app development.ini On Jun 21, 12:41 am, Jorge Vargas jorge.var...@gmail.com wrote: 2009/6/20 biomatrix2008 biomatrix2...@gmail.com: This one is better. On windows vista, zope.alchemy,babel,catwalk were needed to be installed manually. did you ran python setup.py develop on your project? Those dependencies are totally optional and only part of your project. On 6月20日, 下午12时20分, Mark Ramm mark.mchristen...@gmail.com wrote: This is a pure bugfix release. We fixed a major issue with allow_only security restrictions not working on crud controllers (and subclasses). If you use the CrudRestController or the CrudController you will want to upgrade immediately. Other fixes worth mentioning: - content_type support improved (now it's not ugly) - Jinja2 support is fixed - ToscaWidgets? http://trac.turbogears.org/wiki/ToscaWidgets now can be removed when use_toscawidgets is set to false - i18n logging now set to a sane default - and other minor fixed as explained in wiki/changelog 2.0.2 is expected to follow this release fairly quickly with a fix for custom routes and the __before__ method of DecoratedController not working because it has no decoration attribute. 2.0.2 will be the last release coming out of svn, all future releases will happen out of a soon to be created 2.0 branch at hg.turbogears.org. -- 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 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] TurboGears BugFix Day Jun-21-2009
Originally we wanted to make this the 2.0.1 release but oh well Activities - Bring your favorite bug (and patch if possible) - Triage of existing bugs - Apply all (acceptable) patches from trac and/or ML - Make it public so people can bring their bug and adopt a bug - Release 2.0.2 - finally shut down write access to the SVN. - apply all proposed fixed and typo's from the sphinx/discus comments to the sources. --~--~-~--~~~---~--~~ 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: a new registration extension
sorry I'm a little lost. this is a port of ?? Did you knew about the GSOC project at http://gsoc.turbogears.org/hg/tgext.registration/ and http://bitbucket.org/alexandru_marinescu/tgextregistration/ how is your different than that? and why it's called registration2 :) Ideally I'll like to have one true extenstion that we'lll all work on to not repeat ourselfs as a community. On Sat, Jun 20, 2009 at 10:37 PM, alexbodn.gro...@gmail.com wrote: hello friends, i managed to port to 2.0 and hopefully improve the registration extension. it's not so hard to work with. it's called tgext.registration2. http://www.resheteva.org.il/packages -- alex --~--~-~--~~~---~--~~ 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: turbogears2 on webfaction
yea totally my first thing on WF is a bashrc entry. python=python2.5 by the way I got a fabric script to install TG2 if you are interested in alpha testing it :) On Sun, Jun 21, 2009 at 4:58 AM, Alice Zoë Bevan–McGregoral...@gothcandy.com wrote: On WebFaction you can use Python 2.5 if you wish: python2.5 script name — Alice. --~--~-~--~~~---~--~~ 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: How about turbogears2 on GAE?
On Sun, Jun 21, 2009 at 4:53 AM, biomatrix2008biomatrix2...@gmail.com wrote: like the title please search the archives this has been discussed a lot. At this point in time all that's probably needed is someone to get it done as the hard showstoppers from back then are fixed. 1- 10k file limit (with the zip import) 2- pylons not working 3- genshi/mako not running 4- C dependencies I'll advice you to use the 2.1 branch as the drop from TurboJson reduces the C dependencies count by a lot. The only issue I can see today is zope.sqlalchemy as the transaction manager needs C extensions but that is an optional dependency. and of course some interfaces to the datastore and the gae apis' Bottom line no one in the core team is currently interested (or has the time) in appengine. Although I do have to admit that I'm getting more interested in it recently due to wave, but I'm not touching it until I get my sandbox account. So anyone willing to take on the task is more than welcome and I'm sure you will get the support of the team. --~--~-~--~~~---~--~~ 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: TurboGears 2.0.1 released
On Sun, Jun 21, 2009 at 2:26 PM, Boydbebswor...@gmail.com wrote:
That's great news; I've just spent the evening fighting a content_type
issue ;)
- content_type support improved (now it's not ugly)
But I now have an issue of text/plain taking precedence over text/html
with IE7 on a RestController, the method is defined with different
possible content-type as shown below:
@expose('vcrm.templates.rest_get_all')
@expose(content_type='text/csv')
@expose(content_type='text/plain')
@expose('json')
def get_all(self, **kw):
over simplified architecture of the function:
client_request_xxx are only sniffing the content-type of the request/
response
if client_request_json():
return dict(a=b)
elif client_request_csv():
return a,b,c
elif client_request_text():
return blabla
return dict()
With the decorator @expose(content_type='text/plain') IE7 receives a
text/plain page. Chrome 2, Firefox 3.5 and opera 10b receive the more
interesting text/html version. Without the text/plain decorator it
works as expected (or more precisely as I understand it).
I believe this is currently not supported. in fact the new syntax is
simply syntax-sugar under the hood it is doing the pylons.response
I believe the current implementation will overwrite the content_type
with the last you specified. if you need to modify the content_type
based on a if/else construction you still need to use the old syntax.
Of course a patch to make it work on a stacking basis will be great
but I'm not sure if that's doable giving that there is no way to
figure out which one you are actually using.
So either I misunderstood something which is most likely or there is a
bug in the way this update handle IE's Accept header */* in that
particular case.
This is indeed seems like a bug in IE. If I recall correctly if you
return a str IE will think it's plain/text and firefox/gecko will
think it's test/html
I've just tried upgrading my env by running the command found in the
doc (tg2env)$ easy_install -U -i
http://www.turbogears.org/2.0/downloads/current/index
tg.devtools) I don't know if I missed another step.
that is correct. Just to be sure search for the 2.0.1 egg :)
Any help will be appreciated.
Boyd
The header of the request are as follow:
- IE7 --
GET /partner/ HTTP/1.1
Accept: */*
Accept-Language: en-us
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;
SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; InfoPath.2; .NET CLR
1.1.4322; Tablet PC 2.0; .NET CLR 3.5.30729; .NET CLR 3.0.30618)
Host: 127.0.0.1:8080
Connection: Keep-Alive
Pragma: no-cache
Cookie:
vcrm=6c6a0cf163013e302f955773aeb0a5d47f69e747684682aab50d3ce17ee8a0216e5c2af7;
authtkt=223f411f320027133a1935922902f5214a3e702cadmin!
HTTP/1.0 200 OK
Server: PasteWSGIServer/0.5 Python/2.6.1
Date: Sun, 21 Jun 2009 18:09:20 GMT
Pragma: no-cache
Cache-Control: no-cache
Content-Type: text/plain; charset=utf-8
Connection: close
- FIREFOX ---
GET /partner HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1)
Gecko/20090616 Firefox/3.5 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/
*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie:
vcrm=680d4286fa7bf88498174a661cf41e0e6a7ec830431e669438b937e9e7ca97b86b360047;
authtkt=9fd2e9e590c6c13a89d213c23978fc634a3e3f0aadmin!
--~--~-~--~~~---~--~~
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: tgext template
On Sat, May 2, 2009 at 8:56 AM, alexbodn.gro...@gmail.com wrote: hello friends. i'm working at a tg2 extension, which i'd like to package in a standard way, with paste script. i'd ask you which template to use for creating an egg source subtree. i went for basic_namespace, which created me a reasonable subtree, but when i added my working files (a subtree containing model.py, controller.py, widgets.py etc) with a templates/ subdirectory, the templates/ contents was missing from the egg (only __init__.py) was taken. thanks in advance for your help -- Currently there is a experimental paster command in the GSOC repo. http://gsoc.turbogears.org/hg/tgdevtools-alex/ Both ChrisP and I agree on this and I think it's going to be merged into tip unless someone complains. alex --~--~-~--~~~---~--~~ 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: PDF version of TG 2.0
On Mon, Jun 15, 2009 at 9:11 PM, heru susantoheru.on.ge...@gmail.com wrote: hello, is there any pdf version of TG 2.0 documentation for offline reading ? None for download, but you should be able to build a copy with sphinx thank you, heru --~--~-~--~~~---~--~~ 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: [tg-trunk] TurboMail 3.0rc1 - real world testing needed
On Tue, Jun 16, 2009 at 3:10 AM, Felix Schwarzfelix.schw...@web.de wrote: Hi, yesterday I published the first release candidate of TurboMail 3.0. As the status 'release candidate' implies this release *should* be stable enough to be used by normal users. TurboMail 3.0b2 got quite some testing by various users and we found some interesting bugs during the process. Now we need even more real-world testing to get a rock-solid final release! I uploaded the files to http://www.schwarz.eu/opensource/misc/2009/turbomail/ until Alice can put them on the TurboMail webspace. Changes since beta2: - 'mail.smtp.count' was renamed to 'mail.smtp.max_messages_per_connection' to reflect the semantics better, default was lowered to 1 to prevent log warnings about disconnects - 'mail.tries' was renamed to 'mail.message.nr_retries' - Reworked UTF8qp extension which is now only necessary for backwards compatibility. We have a separate, less intrusive 'UTF8qp' charset which can be used for quoted printable encoding without the extension. - SMTPTransport always sends ehlo (report with patch by akalias) - SMTPTransport is more robust in case of connection drops (reported+initial patch by Ethan Frey) - Fixed a couple of bugs in the Pylons adapter (reported+diagnosed by little wiki) - Configuration option for message encoding is now 'mail.message.encoding' (was 'message.encoding') to provide a consistent naming (reported by Domen Kožar) - HTML documentation is included in the release tarballs Roadmap to 3.0: - Give that release candidate 2-3 weeks of field testing - release new versions if serious bugs are found - write release notes for 3.0 - Remove all pointers to the old svn in trac - Rework trac pages so that they reflect the current status - Find a way to push updated docs to the website. Hello Felix, awesome work on this extension. I just love all the features you guys pumped into it. Great work! I just wanted to point out that Alex from GSOC is on the last bits of tgext.registration which uses turbomail for it's confirmation emails, and I'm sure we'll give this a really nice 'real world' test with that. fs --~--~-~--~~~---~--~~ 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: how does the data come into your database?
On Fri, Jun 19, 2009 at 3:31 AM, Michael Brickensteinbrickenst...@mfo.de wrote: Hi! Chris, Alberto and I have been working hard in the CRUD area. I think, much advancements have been made in this area. So, I am very interested, how data is entered in average TG/TG2/... web applications. Is your admin interface web based? Is it hand written, or do you use existing CRUD solutions? using sphox /tgext.admin in newer stuff. plain python script in order stuff. Who enters the data? Script / developer / admin/ secretary? Script and dev, the secretary type use the real webapp How many persons use the admin interface? less than 5 in all cases How long per day are they supposed to work with it? don't know, I guess I don't have a ton of data input tools. I know one app I wrote is supposed to be the 8hrs/day tool for some client but they use the query tool we build for them. Are there granular permissions requirements? Table permissions (which classes/ tables can be edited), Row level permissions (which objecs can be edited), column level permissions (block specific attributes)? yes but currently not enforced by the tools. I know rum has some work on this but I haven't try it. How many tables does your database contain? Or can you give any measure for the complexity? It depends on the project but it 20-100 I'll say. Do you use additional tools for your database for querying/editing the data? paster shell, also several query tools like php*admin and Sequel Pro but that's mostly for development. What additional requirements do you have, that are not fulfilled by todays CRUD packages? - inline editing of objects. For example if you have a User and it's Groups be able to edit it in the same window. - multi object forms. For example to present a single form for the user to fill and that will be stored in 2-3 different tables at the backend. Michael --~--~-~--~~~---~--~~ 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: CMS with TG2
On Mon, Jun 15, 2009 at 1:27 PM, KMCBkmcbrea...@yahoo.com wrote: Jorge, I tried location TurboCMF at these locations without success. http://svn.turbocmf.org/ not working http://docs.turbocmf.org/ not working http://www.turbocmf.org/ working, but only a hello world type test page I did find a presentation on TurboCMF (link below). Can you provide it's present location? I also looked at GoogleCode and bitbucket, no luck there. Alice has have a ton of issues with her hosting. Currently the best way to reach her I think it's on IRC. Pretty much she had to migrate everything which is a ton of work. Also there is a bug she needs to fix in 2.0 :) for CMF dispatch to work. Please note I'm not a user of CMF although I do appreciate her work, I'm actually a developer for tgext.pages :) Thanks, KMCB Presentation http://www.docstoc.com/docs/4196228/TurboCMF-A-lightweight-framework-for-database-driven-web-applications --~--~-~--~~~---~--~~ 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: Problem accessing values in a temp[late
On Thu, Jun 11, 2009 at 7:35 AM, AlienBabymatt.j.war...@gmail.com wrote:
Hi, I'm new to working with Turbogears2 and I have a problem
accessing values from a dict in a template.
This code gets executed in the root controller to query the DB and
pass a couple of dictionaries back, exposed to a particular template.
The query / returned data that is causing the problem comes from this
table definition in the model;
This table is queried in the controller with the following code;
�...@expose('browseeve.templates.ShowAllianceList')
def ShowAllianceList(self):
alinfo=DBSession.query(alliances)
XCinfo={};
for al in alinfo:
XC=DBSession.query(corporations).filter_by
(corporationID=al.executorCorpID)
XCinfo[al.allianceID]=XC
Display alliance table.
return dict(alinfo=alinfo, XCinfo=XCinfo)
you aren't returning the list or object but a query that will get
them for you. XC is a query object that is ready to be executed but
it's not the result. you need to call one() on it.
The alinfo dict is accessible in the following template no problem,
but I have problems with XCinfo;
In its current form, that template extract builds output lines similar
to;
GoonSwarm OHGOD 824518128
browseeve.model.corporations.corporations object at 0x06109150
5251 1149295800
ahhh I miss eve :( I wish I had the time to play that. I cancel my
subscription after I realized all I did was log in to change skills
and chat with the corp. At least I left BC 5 training ;)
AlienBaby.
--~--~-~--~~~---~--~~
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: TG2 No module named site.config.middleware
On Mon, Jun 15, 2009 at 8:30 AM, Jason R. Coombsjar...@jaraco.com wrote:
I'm trying to install TG2 for the first time, but I run into a number
of errors and warnings, same as AFO here:
http://groups.google.com/group/turbogears/browse_thread/thread/0048b8c99c472c36/59d4ae844938caee?lnk=raot
After following the workarounds described there, when I finally run
paster serve development.ini, I get the following traceback:
PS C:\Users\jaraco\projects\jaraco.site\jaraco.site paster serve
development.ini
Traceback (most recent call last):
File C:\python\Scripts\paster-script.py, line 8, in module
load_entry_point('pastescript==1.7.3', 'console_scripts', 'paster')
()
File C:\Python\lib\site-packages\pastescript-1.7.3-py2.6.egg\paste
\script\command.py, line 84, in run
invoke(command, command_name, options, args[1:])
File C:\Python\lib\site-packages\pastescript-1.7.3-py2.6.egg\paste
\script\command.py, line 123, in invoke
exit_code = runner.run(args)
File C:\Python\lib\site-packages\pastescript-1.7.3-py2.6.egg\paste
\script\command.py, line 218, in run
result = self.command()
File C:\Python\lib\site-packages\pastescript-1.7.3-py2.6.egg\paste
\script\serve.py, line 276, in command
relative_to=base, global_conf=vars)
File C:\Python\lib\site-packages\pastescript-1.7.3-py2.6.egg\paste
\script\serve.py, line 313, in loadapp
**kw)
File C:\Python\lib\site-packages\pastedeploy-1.3.3-py2.6.egg\paste
\deploy\loadwsgi.py, line 204, in loadapp
return loadobj(APP, uri, name=name, **kw)
File C:\Python\lib\site-packages\pastedeploy-1.3.3-py2.6.egg\paste
\deploy\loadwsgi.py, line 224, in loadobj
global_conf=global_conf)
File C:\Python\lib\site-packages\pastedeploy-1.3.3-py2.6.egg\paste
\deploy\loadwsgi.py, line 248, in loadcontext
global_conf=global_conf)
File C:\Python\lib\site-packages\pastedeploy-1.3.3-py2.6.egg\paste
\deploy\loadwsgi.py, line 278, in _loadconfig
return loader.get_context(object_type, name, global_conf)
File C:\Python\lib\site-packages\pastedeploy-1.3.3-py2.6.egg\paste
\deploy\loadwsgi.py, line 409, in get_context
section)
File C:\Python\lib\site-packages\pastedeploy-1.3.3-py2.6.egg\paste
\deploy\loadwsgi.py, line 431, in _context_from_use
object_type, name=use, global_conf=global_conf)
File C:\Python\lib\site-packages\pastedeploy-1.3.3-py2.6.egg\paste
\deploy\loadwsgi.py, line 361, in get_context
global_conf=global_conf)
File C:\Python\lib\site-packages\pastedeploy-1.3.3-py2.6.egg\paste
\deploy\loadwsgi.py, line 248, in loadcontext
global_conf=global_conf)
File C:\Python\lib\site-packages\pastedeploy-1.3.3-py2.6.egg\paste
\deploy\loadwsgi.py, line 285, in _loadegg
return loader.get_context(object_type, name, global_conf)
File C:\Python\lib\site-packages\pastedeploy-1.3.3-py2.6.egg\paste
\deploy\loadwsgi.py, line 561, in get_context
object_type, name=name)
File C:\Python\lib\site-packages\pastedeploy-1.3.3-py2.6.egg\paste
\deploy\loadwsgi.py, line 587, in find_egg_entry_point
possible.append((entry.load(), protocol, entry.name))
File build\bdist.win-amd64\egg\pkg_resources.py, line 1913, in
load
ImportError: No module named site.config.middleware
There are no Google hits for site.config.middleware. What is this
and why doesn't my environment not have it?
I'm using Windows Vista 64-bit with Python 2.6.2 64-bit.
I've followed all of the install steps and workarounds as in the
previously-referenced post, except that I'm not using virtualenv (I'm
letting the packages install in my system site-packages).
I appreciate any suggestions.
This seems like a bug with venv on Vista, could you send it to their list?
Regards,
Jason
--~--~-~--~~~---~--~~
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: Everything there is to know about the current auth/identity in TG2
On Mon, Jun 15, 2009 at 12:02 PM, Gustavo Naream...@gustavonarea.net wrote: Hi everyone. Jorge said: Here we go once again... It's not how repoze.what works. It's all about how Python works. In Python, an object can act as a boolean if its __nonzero__/__bool__ method is set accordingly. For TG2 users, a horrible error-prone monkey-patch has been implemented and enabled by default by popular demand: http://trac.turbogears.org/ticket/2205 I'm sorry but this is circular logic to me. It is a monkey patch because you decided not to enable it by default, because it's error-prone (to monkey patch), because someone (I know this predates r.what) decided the predicates where classes which forced the __nonzero__ call. It all boils down to the fact that the current internal state of the system forces ALL of those decisions on us. If you implement it half way (aka booleanize_predicates) you are creating several other problems (your error-phone point and the ugly API). As I've said before, the problem is not that __non_zero__ is set dynamically (i.e., monkey-patched). The problem is that __nonzero__ should not be set. From a generic perspective, not specifically about repoze.what: The only safe way to evaluate a condition represented by an object that is shared among threads, is to make this object stateless and evaluate it by passing other objects which represent the context of the evaluation. I believe you wanted to say the current implementation of non-zero, there is nothing wrong with non-zero itself. No, I meant __nonzero__, however it's defined, is wrong. [1] If you want to skip the step where you pass the context, so you could pass it implicitly to save code (i.e., with thread-locals being the only way to do so, AFAIK), you'll end up with a buggy software: This object won't be stateless anymore, in spite of being used in many threads, which is absolutely unreliable. how are thread locals buggy? if you simply pass the environ to each call won't that fix all your issues with it? make each predicate take the environ as first argument and make them functions that return a boolean or raises NotAutorizedException. What is the flaw there? Noone but you said that thread locals were buggy. And the flaw is in the whole proposal, because you cannot use functions, as I've told you in another thread. you can not use functions if you keep the current allow_only = foo() but if you transform that into allow_only = autorrize(foo()) or something similar that objection is gone. Cheers. [1] http://groups.google.com/group/turbogears/browse_thread/thread/f35ef3d347793682 -- Gustavo Narea xri://=Gustavo. | Tech blog: =Gustavo/(+blog)/tech ~ About me: =Gustavo/about | --~--~-~--~~~---~--~~ 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: how to know which config file was loaded?
On Mon, Jun 15, 2009 at 6:28 AM, Jeffreyjeffre...@gmail.com wrote: thanks for the reply. paster setup-app and nosetests (functional tests) both use the websetup.py to initialize database. in tg2.1 this is split into 2 stages bootstrap and data and I hope we can incorporate something like bootalchemy to make the process less troublesome. the initial database is very large so i wish nosetests can load another smaller sample database. i think to do this websetup must know which config file (prod or test) is running. currently I do this with keeping websetup for the structure and then run a separate python and/or sql script to setup the test data. do you have a better way to do this (seperate setup and nosetests)? ps: i find conf object has a key '__file__' store the configure file path. On Jun 11, 11:24 am, Jorge Vargas jorge.var...@gmail.com wrote: On Mon, Jun 8, 2009 at 3:20 AM, JeffreyHsujeffre...@gmail.com wrote: i want to know which config file (development.ini, test.ini) was loading when running setup-app or in deployment. is there any method to get it? Umm I'm not sure. I think there is. I know there is a flag in the environ set by paster that will tell you if it's testing = True. I think you should ask in the Paste mailing list to see if PasteDeploy/PasteScript has a way to know which config file was used. To be honest the answer could be a little more complex as Paste* allows you to load more than one file. I think you could simply add a flag yourself to indicate which environment you are in. But back to the original issue, why you want this? maybe there is a better way. thanks --~--~-~--~~~---~--~~ 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: What's wrong with predicates being booleanized
On Mon, Jun 15, 2009 at 11:29 AM, Gustavo Naream...@gustavonarea.net wrote: Hello. From time to time I get (mostly private) emails from TG users who complained because there was no way to evaluate predicate checkers implicitly (i.e., without passing the environ explicitly) and now complain because, although it's possible, I strongly discourage it. So here I'll elaborate on the warning I put on the repoze.what-pylons docs, so I won't have to repeat the explanation over and over and over again in different ways, and keep receiving complaints (even from the same people) nevertheless. First of all, keep in mind that this has nothing to do with this functionality being handy or not. I agree it's handy, but that's out of the scope of this thread. My goal is _not_ to discuss if it's handy or not, but why it should be avoided. OK, so here I go... The warning reads: This functionality was implemented by popular demand, but it’s strongly discouraged by the author of repoze.what because it’s a monkey-patch which brings serious side-effects when enabled: 1.- Third-party components which handle repoze.what predicates may get erroneous values after evaluating a predicate checker (even if they don’t use this functionality!). 2.- If another non-Pylons-based application uses the same monkey-patch and you mount it on your application (or vice versa), the predicates used by both application will share the same WSGI environ. In the two scenarios above, it will lead to serious security flaws. So avoid it by all means! Use predicate evaluators instead. I'll start explaining side-effect #2 because I believe it'd be the most important one for TG2 users. Then I'll explain side-effect #1. = Predicates booleanized in multiple repoze.what-powered apps = This is how *all* TG2 applications behave: # Keep in mind that this is *pseudo-code* to illustrate how things work! ... from repoze.what.predicates import Predicate from tg import request ... class TurboGearsApp(object): def __init__(self, ...): ... Predicate.__nonzero__ = lambda self: self.is_met(request.environ) ... def __call__(self, environ, start_response): ... Through repoze.what-pylons, TurboGears 2 applications set the .__nonzero__ attribute of the base Predicate class, so predicate checkers can be used as booleans without passing the environ explicitly. Then it's perfectly possible for other non-Pylons based applications to offer this handy functionality as well if they use repoze.what, so they'd do: # Pseudo code here too. ... from repoze.what.predicates import Predicate from myframework import environ # -- Assuming they use thread-locals too ... class MyFrameworkApp(object): This doesn't have to come from a framework. It can be a raw WSGI app. def __init__(self, ...): ... Predicate.__nonzero__ = lambda self: self.is_met(environ) ... def __call__(self, environ, start_response): ... In both WSGI applications, the __init__ method will be called just once and its object will be shared among threads. Now, the problem arises when both applications are used together; this is, one mounted on the other. When they're used independently one another, there's no problem at all. When they are mounted one on the other, Predicate.__nonzero__ will equal: lambda self: self.is_met(myframework.environ) or, lambda self: self.is_met(tg.request.environ) forever, in every thread, in every request. How come? When MyFrameworkApp.__init__ is called first and TurboGearsApp.__init__ is called next, Predicate.__nonzero__ takes the following values, respectively: lambda self: self.is_met(myframework.environ) lambda self: self.is_met(tg.request.environ) Likewise, when TurboGears.__init__ is called first and MyFrameworkApp.__init__ is called next, Predicate.__nonzero__ takes the following values, respectively: lambda self: self.is_met(tg.request.environ) lambda self: self.is_met(myframework.environ) It will certainly cause problems. In the best case scenario, an exception will be raised and security won't be compromised. In the worse one, the environ will have a default value and thus security could be compromised. Either way, the application will be broken. And it's a big mistake to believe that it would be solved if repoze.what itself set Predicate.__nonzero__. It won't change anything at all. It'd be the same module-level change, just that instead of being dynamic (like the monkey- patch), it'd be static. And before somebody argues But it's not a common scenario!: So what? The point is that it's possible. There's nothing weird in having two repoze.what powered applications, one with TG2 and the other non-TG2 based. = Third party components = Now, this will be quite annoying for people who write plugins/routines that deal with predicate checkers, and pretty
[TurboGears] Re: Install log: failed
On Mon, Jun 15, 2009 at 6:24 PM, allen.fowlerallen.fow...@yahoo.com wrote: could you please clean that up in your huge logs it's impossible to parse what is a warning and what is not. [SNIP] PEAK_Rules-0.5a1.dev_r2582-py2.6.egg/peak/rules/indexing.py:220: DeprecationWarning: object.__new__() takes no parameters /home/afo/tg2test/lib/python2.6/site-packages/ToscaWidgets-0.9.6- py2.6.egg/tw/core/view.py:209: DeprecationWarning: object.__new__() takes no parameters obj = object.__new__(cls, *args, **kw) It is my undestanding that the newest TW doesn't depends on peak.rules anymore. [SNIP] (tg2test)a...@ubuntu:~/tg2test/testprj$ python setup.py develop /usr/lib/python2.6/distutils/dist.py:266: afoWarning: Unknown distribution option: 'message_extractors' warnings.warn(msg) This is because babel is not installed. [SNIP] /home/afo/tg2test/lib/python2.6/site-packages/PasteScript-1.7.3- py2.6.egg/paste/script/command.py:125: DeprecationWarning: BaseException.message has been deprecated as of Python 2.6 print e.message You must give a config file (tg2test)a...@ubuntu:~/tg2test/testprj$ This is too new to be removed. That is why it's deprecated, remember some people are still running 2.4 so I guess we are going to have to live with that. [SNIP] Two more comments 1- as I said those are warnings DeprecationWarnings meaning that future versions will remove them. 2- None are really in TG they are actually in packages that TG depends on. --~--~-~--~~~---~--~~ 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: Trouble with WebHelpers
please make a comment on the doc page where you saw that for it to be fixed. On Mon, Jun 15, 2009 at 8:16 PM, Sethseedifferen...@gmail.com wrote: Jorge, Thank you. Perhaps somewhere in the docs it should be noted that you have to use 'helpers.html.HTML.tag()' since the current listing of 'webhelpers.html.tags.TAGNAME()' is misleading. Seth --~--~-~--~~~---~--~~ 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: TG2, repoze.who and multiple auth sources
I'll love to see docs and/or a blog post on that. On Mon, Jun 15, 2009 at 11:15 PM, Sergei Beilinsbei...@narod.ru wrote: Hi Gustavo! I've seen you're using a rememberer called auth_tkt. To re-use the one used by the built-in plugin, change it to authtkt. Hm, that was the key ;-) It's only 15 minutes of my working day and both auth methods already work ;-) Lots of thanks! You may find this useful, to better understand the exact settings used in repoze.who in TG2:http://tinyurl.com/repozewhatquickstart-setup-sql Thanks, that will be helpful! -- Sergei --~--~-~--~~~---~--~~ 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: Different behaviour, equal environment
On Wed, Jun 17, 2009 at 5:30 AM, Sergei Beilinsbei...@narod.ru wrote: Hi All. Yesterday I stepped into a problem. My PC is an x86_64, with Ubuntu Jaunty and Python2.6. Four other machines are Ubuntu Hardy/python 2.5 (standalone), Jaunty/python 2.6 (in OpenVZ), Debian Lenny/python2.5 (standalone) and Debian Unistable/python2.6 (standalone). My application runs smoothly an my PC, both with py2.5 and 2.6, both under paster and mod_wsgi; and fails on all four other machines, both under paster and mod_wsgi! I checked all the library versions twice. What debugging techniques should I use to overcome this problem? What else should I check? What do you mean by fail? examples? code? at runtime? with paster serve? log p.s. I am thinking of installing a clean system under QEMU... -- Sergei --~--~-~--~~~---~--~~ 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: File uploads (again...)
On Fri, Jun 19, 2009 at 8:05 PM, Sethseedifferen...@gmail.com wrote:
I just found this thread while looking for information on this exact
subject. I am using TG 2 and have not found good documentation on
this.
I appreciate frankentux's post, but does someone have a more recent
example (perhaps with Sprox)? The object I'm getting doesn't seem to
have a .size attribute.
I think that will be a great tutorial.
It really boils down to learning how to use paste.fileapp it's trivial code.
I'm attaching a dated! class this worked with one of the Beta's I'm
not sure if it works with 2.0.1, also note it uses the really old
use_wsgi_app you shuld be using a WSGIController. Also it won't
compile as I removed references to my project. note it provides both
upload and download but the download isn't efficient, but this was for
a ow traffic site. And yes it uses plain ToscaWidgets.
import pylons
from pylons import config
from tg import expose, validate, redirect, flash
from formencode import validators
from tw.forms.datagrid import DataGrid,Column
from webhelpers.rails.number import number_to_human_size as
_number_to_human_size
from paste.fileapp import FileApp
from repoze.what import authorize
import os,shutil
import logging
log = logging.getLogger(__name__)
def number_to_human_size(obj):
return _number_to_human_size(obj.size)
attachment_table = DataGrid(fields=[
('Name','name'),
('Created On','created'),
('Type','type'),
('Owner Id','owner_id'),
('Description','description'),
('Policy Id','policy_id'),
('File Size',number_to_human_size),
('Local Path','path'),
])
class AttachmentController(BaseController):
This controller handles the CRUD of Attachment objects
require = authorize.not_anonymous()
@expose('projectone.webapp.templates.attachment')
def index(self):
pylons.c.widget = attachment_table
attachments= DBSession.query(Attachment).all()
log.debug(attachments)
return dict(page='All Attachments',objs=attachments)
@expose()
@validate(attachment_form)
def create(self, fileobj,overwrite=False,**kw):
upload_dir = pylons.config.get('attachments.path')
if fileobj is None:
flash('You must select a file to attach!',
status='status_warning')
redirect('/attachment/new?case_id=%s' % kw['case_id'])
local_path = os.path.join(upload_dir,fileobj.filename)
if os.path.exists(local_path):
flash('a file named %s already exists' % fileobj.filename,
status='status_warning')
redirect('/attachment/new?case_id=%s' % kw['case_id'])
local_file = open(local_path,'wb')
shutil.copyfileobj(fileobj.file,local_file)
local_file.close()
case_id = kw['case_id']
kw['name']=fileobj.filename
kw['path']=local_path
kw['size']=os.path.getsize(local_path)
kw['owner']= request.environ.get('repoze.who.identity')['user']
policy = DBSession.query(Policy).filter(Policy.case_id==case_id)[0]
del kw['case_id']
attachment = Attachment(**kw)
attachment.policy = policy
DBSession.add(attachment)
log.info(%s %s.%s % ('Created Attachment:',
attachment.__tablename__, attachment.id))
log.debug('Params : %s' % kw)
flash(File %s has been uploaded sucessfully % fileobj.filename)
redirect('/case/view/%s#ag'%case_id)
@expose('projectone.webapp.templates.widget')
def new(self, case_id=None):
log.debug('Method %s got params case_id=%s',request.path,case_id)
if case_id is None:
flash(No case to add attachment, status=status_warning)
redirect(/case)
pylons.c.widget = attachment_form
d = dict(page='New Attachment', value=case_id)
log.debug('Replying with responseDict=%s',d)
return d
@expose('json')
def fetch(self, **kw):
log.debug('Method %s got params %s',request.path,None)
cases = DBSession.query(Attachment).all()
d = dict(results=cases)
log.debug('Replying with responseDict=%s',d)
return d
@expose()
def download(self,attachment_id):
log.debug('Method %s got params %s',request.path,None)
attachment =
DBSession.query(Attachment).filter_by(id=attachment_id).first()
file_path = attachment.path
filename = os.path.basename(file_path)
fapp = FileApp(file_path,
**{Content-Disposition:attachment; filename=+filename})
return use_wsgi_app(fapp)
--~--~-~--~~~---~--~~
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
[TurboGears] Re: auth information not available on error
On Thu, Jun 18, 2009 at 10:07 AM, Antoine Pitrouantoine.pit...@gmail.com wrote: Hello all, It seems that, when generating a 404 page (or, I assume, any other error page), the ORM session has been invalidated and therefore any attempt by the basic layout template (which is inherited by the error template) to access attributes of the current user (e.g. tg.identity ['user'].foobar) produce the following traceback. Is there something I'm missing? (this behaviour, like other buggy behaviour already mentioned on this list, might be attributed to the zope.transaction layer...) That indeed seems like a bug, Could you provide a test case and a ticket for it. --~--~-~--~~~---~--~~ 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: Semantics of the tg.i18n.setup_i18n() function
On Sat, Jun 20, 2009 at 3:59 AM, Timur Izhbulatovtimoc...@gmail.com wrote: 2009/6/20 Mark Ramm mark.mchristen...@gmail.com: Thanks. I just had to do 2.0.1 very quickly today, but I think we should get this integrated in as soon as we can and do a 2.0.2 release this week too. Very good. I changed the ticket's milestone to 2.* bugfix, which seems appropriate. yes indeed I created that last night :) --Mark Ramm On Sat, Jun 13, 2009 at 12:59 PM, Timur Izhbulatov timoc...@gmail.com wrote: 2009/6/13 Jorge Vargas jorge.var...@gmail.com: On Fri, Jun 12, 2009 at 5:58 AM, Timur Izhbulatovtimoc...@gmail.com wrote: Hi all, I've been porting my app to 2.0 and noticed that setup_i18n() [1] doesn't set FormEncode translation if it finds language in session. This function is the only i18n API that the controller is aware of and it's called internally, so there's no way to change this without overriding controller methods. That is, currently FormEncode translation is only set when there's an Accept-Language match. Shouldn't setup_i18n() also set FormEncode translation if there's language in session? yes I think it should. OK. Here's a ticket for this http://trac.turbogears.org/ticket/2335 There's also a patch. -- Timur Izhbulatov — www.timka.org -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog -- Timur Izhbulatov — www.timka.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: Please bump up TG2's dependency on TW/tw.forms to 0.9.7.1
On Sat, Jun 20, 2009 at 3:27 AM, Christoph Zwerschkec...@online.de wrote: Alberto Valverde schrieb: Subject says it all, last release breaks tw.forms when displayed on Genshi and this one should fix it. There is no hard dependency of TG2 or its quickstart templates on TW any more, so people need to upgrade manually or add this dependency to their TG2 apps. actually that is not entirely accurate. TG core still depends on ToscaWidgets but not on tw.forms. -- Christoph --~--~-~--~~~---~--~~ 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: TurboGears 2.0.1 released
2009/6/20 biomatrix2008 biomatrix2...@gmail.com: This one is better. On windows vista, zope.alchemy,babel,catwalk were needed to be installed manually. did you ran python setup.py develop on your project? Those dependencies are totally optional and only part of your project. On 6月20日, 下午12时20分, Mark Ramm mark.mchristen...@gmail.com wrote: This is a pure bugfix release. We fixed a major issue with allow_only security restrictions not working on crud controllers (and subclasses). If you use the CrudRestController or the CrudController you will want to upgrade immediately. Other fixes worth mentioning: - content_type support improved (now it's not ugly) - Jinja2 support is fixed - ToscaWidgets? http://trac.turbogears.org/wiki/ToscaWidgets now can be removed when use_toscawidgets is set to false - i18n logging now set to a sane default - and other minor fixed as explained in wiki/changelog 2.0.2 is expected to follow this release fairly quickly with a fix for custom routes and the __before__ method of DecoratedController not working because it has no decoration attribute. 2.0.2 will be the last release coming out of svn, all future releases will happen out of a soon to be created 2.0 branch at hg.turbogears.org. -- 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 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 -~--~~~~--~~--~--~---
