[tg-trunk] Re: The future of TurboGears
On Tue, 2009-06-23 at 08:25 -0700, percious wrote: This thread really distresses me. The amount of effort that has gone into say what should be done instead of actually doing it is ludicrous. If you don't like the direction that TG is taking, participate in a sprint. Write some docs. Contribute patches. Provide information for the beta site. Organize a sprint. If you don't have the time, sponsor documentation changes, hire an intern to work on only-tg stuff... etc. Come hang out and pester me on the irc channel #turbogears if you'd like to contribute. 10 minutes or 10 hours, it all makes a difference. Sorry Chris, but I have to pipe up here, IMHO that is bolagna. I love what you're doing and appreciate it to death, *but*... A project should *always* want user feedback, whether it's positive or negative. If you only want to hear positive feedback, then you can be doing all kinds of things wrong, and no one will ever tell you, they'll just quietly leave. People with valuable things to say won't just be singing praises. Smart leaders want to hear people venting. Sure it won't all be right, but there *is* a reason they are venting. If they didn't care, they wouldn't do it. And, not all users will be contributors, that's a reality. If a project *expects* all users to be contributors, it's doomed to never have a wide user base. Contributors come from building a wide user base over time, they don't come from telling people they should all shut up or contribute. How many projects do you use? How many do you contribute to? Do you contribute to apache, vim, linux, etc, etc? People will always use way more than they contribute to. The last thing we need to do is make people feel guilty for not contributing just because they voice their opinions. All that does is chase more people quietly away. If TG's attitude is to become 'contribute or shut up', then I'd say that's the final nail in the coffin. And I say that with some distress because I really like the code, but really don't like the way the TG project has been managed. I agree that unfortunately TG is lacking in marketing, but if we want to have a viable product, the core team needs to focus on the technology. With a solid base of functionality, we will find folks who have the time and resources to provide us with the marketing this project so sorely needs. This is sooo backwards. And the success and lack thereof of various projects proves it. Most people want well documented well exampled smaller sets of features over feature rich less documented 80% done software. That's the painful truth. Focusing on code first, docs/marketing/public perception second is not fun, but it's critical. I have stopped using Toscawidgets for precisely that reason, I no longer believe docs and examples will ever catch up to the code. I have to train people, I can't train them effectively that way. I would rather use something way simpler with effective clear examples that I can show my workers and clients. I can't show someone toscawidgets without squirming. Yet again, I beseech people to read Fogels Producing Open Source Software. It would be a much needed wake up for those steering TG. my two cents canadian, Iain --~--~-~--~~~---~--~~ 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 Tue, 2009-06-23 at 13:26 -0400, Mark Ramm wrote: I have to jump in here on a quick note. This thread really distresses me. The amount of effort that has gone into say what should be done instead of actually doing it is ludicrous. snip Sorry Chris, but I have to pipe up here, IMHO that is bolagna. I love what you're doing and appreciate it to death, *but*... A project should *always* want user feedback, whether it's positive or negative. And we do appreciate and value feedback of all kinds, but it can be hard to feel like you give a good part of your life for something and people keep asking for *more.* That said, I can take it, so if you want to level any particularly harsh criticisms, or provide a long list of demands send them to me via private e-mail. But seriously, it impacts the motivation of all the TG developers when they read a thread like this, and it really would help a lot if people spent more effort building up the community than demanding yet more work from the existing developer pool. Sure, I agree. But what I believe you are underestimating is how much damage it does to a project when they are perceived to be shooting the messenger. I am not saying for a second that I agree with all of the criticisms. I am saying that it is a real mistake to answer *any* criticisms in a hostile manner and with that kind of attitude, whether correct or not. iain --~--~-~--~~~---~--~~ 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
This is sooo backwards. And the success and lack thereof of various projects proves it. Most people want well documented well exampled smaller sets of features over feature rich less documented 80% done software. That's the painful truth. Focusing on code first, docs/marketing/public perception second is not fun, but it's critical. oops, that should be the other way around, but I expect anyone reading my post can figure that out. I really don't think it's realistic to expect to be able to focus the core team on code and hope the rest will somehow keep up. Writing docs and examples is not as fun as writing code, and doing so requires a thorough understanding of the framework. So what are the chances that we will get new contributors wanting to do so? But docs/marketing/web presence first is the price you pay to get users. If you don't want users, do it however you like. But most users want understanding more than features. The Django devs did a very very good job of that at the beginning, and it paid off handsomely in the long run for them. iain --~--~-~--~~~---~--~~ 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: A Letter to the Authors of Web Authentication Libraries
On Sun, 2009-05-03 at 15:36 -0700, Graham Dumpleton wrote: FWIW, this person spammed his message to lots of groups. Possibly trying to drum up interest in his specific package and get it supported. One of the longer threads about it is at Django Developers group on Google Groups. I would hardly call Paul a spammer on the TG list. Whether he cross posted or not, he has been a long time contributer to TG and one of the more helpful people on the lists. Iain --~--~-~--~~~---~--~~ 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 needs a better helper to mount WSGI apps
On Fri, 2009-01-09 at 13:30 -0800, percious wrote: How about WSGIAppController, and you pass in a wsgi app to the __init__? I like the above idea, and Alberto's idea two. The above especially makes sense to me as it seems to make sense with what I see as the most common wsgi app pattern: callable object that is instantiated on server startup and called on request. Iain --~--~-~--~~~---~--~~ 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.0b1 testers needed
On Thu, 2008-12-25 at 13:57 -0500, Mark Ramm wrote: We are rappidly approaching the first 2.0 beta release. Thanks to the hard work of Florent, Chris, Jon, Christopher, Lee, Gustavo, and many others we have been able to jump directly from 1.9.7 to 2.0. New in this release: * Catwalk is now revived and integrated into the quickstart project for admin * Quickstart now has login/logout links by default * Quickstart has been completly overhauled for a fresh new look. * tg.url and tg.redirect now know about whatever routes you have defined. So, in an attempt to get all this out in front of a few more people and hopefully get a release out this weekend, I've just created a new index at: http://www.turbogears.org/2.0/downloads/2.0b1/index/ So, if you create a new virtualenv with the --no-site-packages option you should be able to get a fully functional TG2 install with all the latest goodness by activating your virtualenv and doing: easy_install http://www.turbogears.org/2.0/downloads/1.9.7b2/index/ tg.devtools Trying the above got me this: $ easy_install http://www.turbogears.org/2.0/downloads/1.9.7b2/index/tg.devtools Downloading http://www.turbogears.org/2.0/downloads/1.9.7b2/index/tg.devtools error: Unexpected HTML page found at http://www.turbogears.org/2.0/downloads/1.9.7b2/index/tg.devtools Thanks Iain --~--~-~--~~~---~--~~ 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.0b1 testers needed
On Thu, 2008-12-25 at 11:39 -0800, Iain Duncan wrote:
Trying the above got me this:
$ easy_install
http://www.turbogears.org/2.0/downloads/1.9.7b2/index/tg.devtools
Downloading
http://www.turbogears.org/2.0/downloads/1.9.7b2/index/tg.devtools
error: Unexpected HTML page found at
http://www.turbogears.org/2.0/downloads/1.9.7b2/index/tg.devtools
Thanks
Iain
It works if I change the link to:
http://www.turbogears.org/2.0/downloads/1.9.7b2/tg.devtools-1.9.7b2.tar.gz
Iain
Oops, it didn't after all:
Searching for TurboGears2
Reading http://pypi.python.org/simple/TurboGears2/
Couldn't find index page for 'TurboGears2' (maybe misspelled?)
Scanning index of all packages (this may take a while)
Reading http://pypi.python.org/simple/
No local packages or download links found for TurboGears2
error: Could not find suitable distribution for
Requirement.parse('TurboGears2')
Thanks
Iain
--~--~-~--~~~---~--~~
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.0b1 testers needed
On Thu, 2008-12-25 at 11:40 -0800, Iain Duncan wrote:
On Thu, 2008-12-25 at 11:39 -0800, Iain Duncan wrote:
Trying the above got me this:
$ easy_install
http://www.turbogears.org/2.0/downloads/1.9.7b2/index/tg.devtools
Downloading
http://www.turbogears.org/2.0/downloads/1.9.7b2/index/tg.devtools
error: Unexpected HTML page found at
http://www.turbogears.org/2.0/downloads/1.9.7b2/index/tg.devtools
Thanks
Iain
It works if I change the link to:
http://www.turbogears.org/2.0/downloads/1.9.7b2/tg.devtools-1.9.7b2.tar.gz
Iain
I just also tried:
easy_install
http://www.turbogears.org/2.0/downloads/2.0b1/tg.devtools-2.0b1.tar.gz
And got the same error:
Reading http://pypi.python.org/simple/TurboGears2/
Couldn't find index page for 'TurboGears2' (maybe misspelled?)
Scanning index of all packages (this may take a while)
Reading http://pypi.python.org/simple/
No local packages or download links found for TurboGears2
error: Could not find suitable distribution for
Requirement.parse('TurboGears2')
Iain
--~--~-~--~~~---~--~~
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: New quickstart style
On Mon, 2008-12-15 at 17:58 +0100, Jonathan Schemoul wrote: No problem :) Hey Jon, thanks for taking that over. I'll be continuing to work on my change dimensions in only one place framework, but it's pretty much a write off until we can confidently ignore IE6, so I appreciate your overhauling the template for TG2. Iain --~--~-~--~~~---~--~~ 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: New quickstart style
On Mon, 2008-12-15 at 11:21 -0800, Iain Duncan wrote: On Mon, 2008-12-15 at 17:58 +0100, Jonathan Schemoul wrote: No problem :) Hey Jon, thanks for taking that over. I'll be continuing to work on my change dimensions in only one place framework, but it's pretty much a write off until we can confidently ignore IE6, so I appreciate your overhauling the template for TG2. If you guys want to backport that to TG1.1, I will also not be in the slightest bit offended over my work being shelved. ;-) Iain --~--~-~--~~~---~--~~ 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: New quickstart style
On Sat, 2008-12-13 at 20:51 +0100, Gustavo Narea wrote: Hello. Florent Aide and Iain Duncan (sorry if I miss somebody) have been working on the new look feel for TG2 quickstarted projects and I wanted to say that it looks rather nice, I really like it. Jorge is helping port it to as my time is sketchy at best. I have just one suggestion: I think the flash should be more visible, distinguishing an error from a normal message. Good idea and thanks for the feedback. I've got a few more improvements in mind, but am being xmassed to death this weekend... ;-) Iain --~--~-~--~~~---~--~~ 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: IMPORTANT: the new css and IE6 issue
Hi everyone, re the new css. We discussed this aways back on the dev list and I said I was working on a new framework that could be used for the template, but that I did not think it would be ie-6 css compatible and asked for opinions. At that time, it seemed everyone was fine with no ie6, but of course at that time, ie 8 was also supposed to be out by now. notice that *think it would not* is very different from *it will break and we should warn you to upgrade*, but the clarify I think the best way today is to code things in a real browser, and then fix it for the bad ones. Which I think is the stage we are at now. Yeah, I agree. I knew the stretched absolute positioning was not going to work, but didn't realize the havoc the daisy chained selectors would cause. Basically, what I did make a system whereby you can change a geometric measurement in only *one* place, and have the all the other components respond properly. So changing the widths or height or margin of the outer container will reflow all other components in nice alignment. I have never seen this work in any IE6 supporting css setup, there is always the necessity to change numbers in several places, especially if combining floating three column layouts with absolutes and so on. I also kept *all* layout and presentation controls out of ids, so that users can use semantic ids as they see fit. That's really nice, I have dream about that for quite some time. Cool, that's at least some motivation to keep working on the concept. =) That said, I won't be at all offended if we shelve it for now until ie8. That's cool, but I'll warn you that porting it is not pretty, I just did it for my own site here: http://www.flyingnotfalling.com ( that's me! ) That site looks very nice, very professional indeed. As for shelving it I don't think so I'll prefer to have a ie6 workaround or simply a quickstart template for ie6 You should be able to compare the xhtml/css files from the tg template and flyingnotfalling to see what had to be done. Basically all layout behaviour that depended on things like .main.region.fixed-x-fixed-y had to be replaced with ids like #main-region I think we should try in this order a- try to make it work with some conditional comments I'm pretty sure that won't work, at least I tried long enough to abandon it myself! b- make a separate id layout template that's what I did for fnf, recommended c- fix it with JS? that was my *original* intent, to just have a js file for ie6 make the corrections, but the selector problem sunk that one Thanks for the interest! Iain --~--~-~--~~~---~--~~ 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: IMPORTANT: the new css and IE6 issue
That site looks very nice, very professional indeed. As for shelving it I don't think so I'll prefer to have a ie6 workaround or simply a quickstart template for ie6 You should be able to compare the xhtml/css files from the tg template and flyingnotfalling to see what had to be done. Basically all layout behaviour that depended on things like Would it be useful for me to put up a blank page on that site that is not in the menu just to have easier source to interrogate? Sorry this weekend is bad for me ( darn xmas things all weekend ). Iain --~--~-~--~~~---~--~~ 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 release plan thoughts
On Thu, 2008-12-11 at 15:21 -0600, Jorge Vargas wrote: On Wed, Dec 10, 2008 at 11:44 PM, Chris Miles miles.ch...@gmail.com wrote: On 11/12/2008, at 4:36 PM, Mark Ramm wrote: I assume Beaker is also the recommended caching solution for TG2, but would like clarification. Yes, beaker is the built in caching mechanism of TG2. Beaker supports memcached, and lots of other back-ends. It also doesn't suffer from the so-called dog-pile effect i the same way as some other web-framework's built in caching mechanisms do, because it's just plain awesome. That's good. I've decided to learn standard Pylons before looking at TG2 in detail. I assume a lot of Pylons knowledge will make working with TG2 much easier. From the experience of someone that did that, You will be disappointed and you will learn a lot. From someone that comes from TG1 or django, pylons is like giving you a 1 pieces puzzle with no picture of the image and a lot of ocean and sky tiles. So you have to expend a lot of time reading about the components and understanding how things are done, and ones your finally done with all those blue tiles you have no energy to get started with the ship. And this is exactly the kind of thing TG2 is here for. You start right there at the ship and if you don't want to expend countless hours on the sky and sea, you don't have to, but if some part of it is important you can dive in there. OMG, that was hilarious Jorge. What a perfect metaphor. ;-) Iain --~--~-~--~~~---~--~~ 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 release plan thoughts
On Wed, 2008-12-10 at 09:47 -0500, Mark Ramm wrote: I'm very interested to hear about how TG2 will avoid the scaling and traffic issues that hit pownce and twitter. Well, there are lots of issues, and without being super-connected to either Twitter or Pownce, one of the things that seems to have happened to both early on is that it was difficult for their platform of choice to connect to multiple databases and handle horizontal partitioning. Beyond that, it was hard for them to manage how many DB hits each page produced since the ORM's in their platform didn't make it easy to group sets of db changed together and submit them all at once. Nor did they have the flexibility that SQLAlchemy provides in grouping which data will be returned by a request of a particular mapped object, both because SA provides fine-grained control of what will be eager-loaded and what should be lazily loaded, and because SA as a Data Mapper implementation allows objects to map to data from several tables at once. You know, a detailed tutorial/article on the above would probably be very good TG2 publicity, as long as you can do so without looking like you're using Twitter/Pownce as scapegoats. Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TG2 release plan thoughts
On Tue, 2008-12-09 at 18:45 -0500, Mark Ramm wrote: On Dec 8, 11:58 pm, Mark Ramm [EMAIL PROTECTED] wrote: I'd like to propose that we declare the next stable TG2 release 2.0 and that we work together to get a release candidate by the end of the year. I assume this means rather than TG 1.9.7.beta3, we'll be seeing TG 2.0.0.beta1 next right? Seems about right, and that was the plan. Though I'm not opposed to keeping the numbering scheme we have now until the stable release becomes 2.0. I'm +1 on that. I think major release numbers create a lot of expectation in terms of polish and that it is a big marketing no-no to rush the major release numbers. my two cents Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: Include a widget on every request
On Tue, 2008-12-02 at 09:57 -0800, [EMAIL PROTECTED] wrote: It's totally acceptable to create the widget anywhere, and import it into master.html in a python block. It's all view logic so there's no reason not to do it in the template. And you can use TW widgets any time you want in TG2 -- the limitation that you couldn't import them in the template in tg1 is removed because in tg2 the resource injection happens after the template is rendered. Oh man, that is a big improvement over the old include list in the config file. Thanks! Now that said, I've always thought it would be really handy to be able to add stuff to the dictionary that goes to the template from startup code, is that possible in TG2? ( maybe it's a dumb idea... ) Iain --Mark Ramm On Nov 27, 6:59 pm, Radityo [EMAIL PROTECTED] wrote: I am trying to make a website using tg2b and currently I tried to create a web menu system using toscawidgets. But there are something that I cannot understand: 1. How to include a widget on every request without having to pass it through tmpl.context on every method in every controller? I could do in-line code without toscawidgets in master template, but some how it doesn't feel right. 2. I triedhttp://www.turbogears.org/2.0/docs/main/ToscaWidgets/Cookbook/Dynamic..., but sometimes it return empty list. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: Include a widget on every request
On Tue, 2008-12-02 at 23:49 -0500, Mark Ramm wrote: Now that said, I've always thought it would be really handy to be able to add stuff to the dictionary that goes to the template from startup code, is that possible in TG2? ( maybe it's a dumb idea... ) Well there's a callable that you can create and stick into the config that gets called to add extra parameters to the template's root namespace. Is that's what you're looking for? That sounds pretty good! Is that in the docs already? My apologies if it is, I haven't had time lately to sit down with the new and improved TG2 docs. Hoping to do so soon though. Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] opinions wanted, line length in new master.html
Hi folks, I've been working on the overhaul of master.html and welcome.html from quickstart, and would like some feedback. I noticed that previously, lines have been broken to meet PEP standards. I propose that we do *not* break lines at 80 chars in Genshi templates because: - the file is IMHO first and foremost an XML doc and not python code - in an XML doc, lines should preserve XML structure over PEP - it's enormously more convenient to the designers and front end coders to have xml structure visible at a glance even if lines are long whereas broken up lines are kindof a pain unless they are rellly long IE this: div ul li a href=asdjadjalsdj;a class=list of things that go past 80 stuff /a /li /ul /div is preferable to this: div ul lia href=asak akjasd asdkljl class= asds asdklj asdstuff/a /li etc etc Thoughts? Correct me if I'm wrong please! Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: opinions wanted, line length in new master.html
On Thu, 2008-11-20 at 10:45 +0100, Florent Aide wrote: On Thu, Nov 20, 2008 at 9:50 AM, Iain Duncan [EMAIL PROTECTED] wrote: I noticed that previously, lines have been broken to meet PEP standards. I propose that we do *not* break lines at 80 chars in Genshi templates because: - the file is IMHO first and foremost an XML doc and not python code yep - in an XML doc, lines should preserve XML structure over PEP as long as it is valid xml, your xml editor should be able to handle it... - it's enormously more convenient to the designers and front end coders to have xml structure visible at a glance even if lines are long whereas broken up lines are kindof a pain unless they are rellly long We need to get a balance here... Going over 80 is ok, because as you said we don't have to follow pep8 for XML documents. But having line 100/150 chars is also a pain... That's what I'm thinking too. Thanks for the feedback. Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: opinions wanted, line length in new master.html
On Thu, 2008-11-20 at 08:46 -0600, Jorge Vargas wrote: On Thu, Nov 20, 2008 at 3:45 AM, Florent Aide [EMAIL PROTECTED] wrote: On Thu, Nov 20, 2008 at 9:50 AM, Iain Duncan [EMAIL PROTECTED] wrote: I noticed that previously, lines have been broken to meet PEP standards. I propose that we do *not* break lines at 80 chars in Genshi templates because: - the file is IMHO first and foremost an XML doc and not python code yep - in an XML doc, lines should preserve XML structure over PEP as long as it is valid xml, your xml editor should be able to handle it... - it's enormously more convenient to the designers and front end coders to have xml structure visible at a glance even if lines are long whereas broken up lines are kindof a pain unless they are rellly long We need to get a balance here... Going over 80 is ok, because as you said we don't have to follow pep8 for XML documents. But having line 100/150 chars is also a pain... Thoughts? Correct me if I'm wrong please! You're the one working here... I say it's your call. We trust you to do sane things. agreed with all the above, another thing that should be done is spacing, current quckstart templates have 2 space indentation, I suggest we more that to 4spaces. I actually prefer 2 myself for templates just to control indentation amounts better, but good to hear. As for the formatting I don't know about you but I like my lia as a one liner. I the case of manuals I think that is often fine, but for looping constructs I'm partial to laying it out. Here's what that is looking like in my scratch pad: ul id=menu-left class=component list-menu vert li py:for=title,url in menu_side a href=$url$title/a /li /ul (NB: the id is optional and not required by the framework so that it is easy for everyone to pop in their own choice of semantic ids. The default css behaviours come from tag, class, and inheritance only. Thanks Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: opinions wanted, line length in new master.html
On Thu, 2008-11-20 at 10:21 -0500, Mark Ramm wrote: Perhaps we should standardize on: * Max line lengths 120 chars * Indentation 2 spaces (no tabs) * one liners can have the opening tag and closing tag all on one line * otherwise put opening and closing tags on a separate line Possibly there are other things which we may want to add to the standard? I like that so far. One annoyance I have found is that a lot of editors muck up their syntax highlighting when you use self closing tags. hence the a href=$thing/a instead of just a href= py:content=thing/ which makes my vim highlighting underline the whole rest of the page ... Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: opinions wanted, line length in new master.html
On Thu, 2008-11-20 at 15:49 +0100, Christopher Arndt wrote: Florent Aide schrieb: We need to get a balance here... Going over 80 is ok, because as you said we don't have to follow pep8 for XML documents. But having line 100/150 chars is also a pain... +1 I usually break long lines before element attributes and try to avoid breaking between an attribute and the value. If this isn't possible, I think its ok to have longer lines, but not too long. Please keep in mind that there are also people who edit XMl with a plain text editor... I'm using vim so I won't lose track of that! ;-) Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TG 1.x use_wsgi_app
On Fri, 2008-11-14 at 12:26 -0600, Ken Kuhlman wrote: I'm struggling with the decision of whether I should backport use_wsgi_app-type functionality to tg1.1b2, if I should hold off until 1.5, or even if it's a mis-feature that shouldn't be backported at all. As a memory refresher, use_wsgi_app is a TG 2.0 feature that is used to return a WSGI application from an exposed controller, and the ticket for backporting it to TG 1.x is #1951. Anyway, here's why I'm struggling: (a) I'm not sure that use_wsgi_app's interface is right. I think it would be better if it allowed the WSGI app to be used directly from a controller. For example, instead of this: class MyController(Controller): @expose() def some_controller(self, *args, **kwargs) return use_wsgi_app(your_wsgi_app) My two cents are that: - it would be great to have this in 1.1 - it's more important that the interface be right then for it to come out sooner - even though it would be great, it's not worth killing yourself over for 1.1 as CherrPy 2 is on the way to legacy thanks for listening to the peanut gallery! Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: turbogears.org troubles
On Fri, 2008-11-14 at 15:25 +0100, Christopher Arndt wrote: Christopher Arndt schrieb: The server where turbogears.org is having trouble again at the moment, which means that the SVN, trac and the wiki are not working properly at the moment. The main website seems to work ok, because it only used static files and no database. I have opened a ticket at WebFaction's support and am awaiting their response. I'll let you all know about further developments. All servers are up again. WebFaction seems to have restarted the server. Have we considered asking for a VPS from someone? I would not be surprised if Slicehost were open to the suggestion, having just been purchased by a larger company with the dough for promo. I've been really happy with them and have been moving more and more clients to VPS's on slicehost now. Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TG2 beta this week?
On Wed, 2008-10-15 at 22:23 -0400, Mark Ramm wrote: I got really sick at PloneConf, and have not made much progress on the TG2 release this week so far, but I'm still planing to do a release as soon as possible. I'm feeling a bit better this evening than I have been so I'm going to start prepping a release tonight and hopefully will be able to get a new index up tomorrow for people to test. If that goes well, the official release will probably happen Friday. Unless somebody changes my mind between now and Friday morning I'm planning to call this next release 1.9.7b1, and we will not be adding new features to before the final 1.9.7 release, so I'll be moving 1.9.7 work into a branch. I would very much like to expand on the new full stack tests that have recently been added to the trunk, and most of my effort between now and the beta release will be on increasing the number and quality of our tests. If you're interested in helping out on that front, just ping me, and I'll help out as much as I can, but these tests should be a lot like writing TG2 apps, so hopefully they should be easy enough to write. Update on the css work for the front end, I'm going to have to say it will take longer than I thought. ( ha ha, doesn't it always! ) I feel that a half baked css scaffold is going to be worse than nothing. It's the kind of thing that is totally useless if the core tags and selector hooks change, and I'm am making some interesting progress, but am far from nailing down anything I think is ideal. I am still very much interested in seeing it through though, especially after checking out deliverance. I think I can come up with something that will really fill a niche in that combination. BTW, I hope you're going to write about the Plone conferrence and TG2! Thanks Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: css framework
For the developer, clearly having A) is more important.
My thought too.
I have had the same problem with various sites, and I've abandoned the
associated accessibilty benefits of B). A skip to content link is
easy enough to implement, and while not solving the problem
completely, it does mitigate the effects somewhat.
Also, many of my current sites use Javascript in ways that throw away
other accessibilty issues, forcing different HTML representations
(layout templates, not resources) for screen-readers anyway.
The best method for that that I've seen using the jiggery pokery is that
used by the Drupal Zen theme, ( technique called body politic which I
believe comes originally from the positioniseverything site). This works
great, but the way you size your columns and middle content is quite
confusing to a new user and requires a bunch of interlocking arithmetic
on widths between the sidebars and the page and the main content.
I'm a big fan of declaring the main layout dimensions once and only
once, preferably all in the same section of the file, so I would go
with A. Adding a skip to content link to the main TG template might
be an acceptable compromise.
I ran a comparison yesterday while doing some drupal work ( The zen
layout for drupal is a really good css framework actually! ) and the
body politic method required changing those numbers in 4 places instead
of one in addition to the funny business of pulling everything past each
other with negative margins. I think maybe the best bet is to go with A,
and have comments or an example of how to convert to B for production if
desired.
Another direction I am thinking of going is to basically leave id's out
of the whole shebang. I want to make sure my work can be integrated
easily into other systems, and of course ids are one-and-only. This
would mean the framework ( such as it is, hardly merits the name
framework ) would only define roles for classes, and you can use id tags
as you see fit.
so say a fixed height header in a fixed width page block with a
container expanding to fill the header would attributes like this:
div id=page class=region r_1 fixed-x shrunk-y
div id=page-container class=container
!-- Header: a shrunk-x stretched-y region --
div id=header class=region r_1-1 stretched-x fixed-y
div id=header-container class=container
div id=header-component class=component
h3Header container in region, working/h3
/div
/div
/div!-- end region-1-1 --
...
But, those id tags would be totally optional. The framework rules would
be working off selectors like so:
/* fixed width column stretching to parent in the y */
.region.fixed-x.stretched-y { }
.region.fixed-x.stretched-y .container { }
And you could specify selectors for your own site specific rules on a
region basis:
.region.r_1-1 { }
or use your ids
#header.region {}
This would preserve the possibility of semantic css style of this kind
of thing:
#header ul li a.menu_item { }
I'm also *very* interested in Deliverance. I'll certainly be trying to
integrate the system with that. I like the idea of a Deliverance/WSGI
based theming app/framework that can be stuck over mixed
TG/Pylons/Plone/Django/Drupal frankensites. So keeping IDs clear may be
important in that regard. I wonder whether I should make the framework
classes use some kind of namespace tag prefix to keep options open? I
guess that could be an optional download or something you run a script
to achieve? Crap, then I need a name! ;-)
Iain
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
TurboGears Trunk group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---
[tg-trunk] css framework
Hey Florent, and (others) just wanted to let you know that I have been working on the css welcome page framework, just not really finalized on some decisions yet. I've also asked about some photos. Will post any updates. Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: css framework
On Thu, 2008-09-10 at 09:18 -0700, iain duncan wrote: Hey Florent, and (others) just wanted to let you know that I have been working on the css welcome page framework, just not really finalized on some decisions yet. I've also asked about some photos. Will post any updates. Here's an update anyhoo. I can't find a good way to have both: A) change something in one place only B) have middle content appear before floated columns in the document structure Some folks get pretty excited about B, quoting SEO needs and also that it's nice for screen readers not to have to read the sidebars first etc. However, I haven't seen anything that allows us to have the main content area resize itself gracefully while only changing the width of the parent page container. That is possible if the sidebars are first though because then one can use the floated-columns margined-middle technique without lots of jiggery pokery. I dunno which compromise seems best for coder use. The best method for that that I've seen using the jiggery pokery is that used by the Drupal Zen theme, ( technique called body politic which I believe comes originally from the positioniseverything site). This works great, but the way you size your columns and middle content is quite confusing to a new user and requires a bunch of interlocking arithmetic on widths between the sidebars and the page and the main content. Feedback appreciated. Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: Easy install is installing a beta again!
On Tue, 2008-23-09 at 07:52 +0200, Christopher Arndt wrote: iain duncan wrote: On Tue, 2008-23-09 at 02:06 +0200, Christopher Arndt wrote: No, easy_install is always installing the latest version, that's available on the download page linked on the projects PyPI page. Thatswhy the official and supported installation method is the one described on http://docs.turbogears.org/Install using the tgsetup.py script, which will install the correct current stable version. The last time we discussed this on here ( with Florent ) I'm pretty sure everyone agreed that easy_install should install the latest release, not the latest release candidate or beta. I haven't looked up the thread, but that is my recollection, possibly erroneous. Florent, do you recall? Maybe it should, but it doesn't. That's just not the way easy_install works by default. To easy_install a version with a higher number is newer and (if you don't specify a version contraint) will install it. This is exactly why we are providing the tgsetup.py script, because it specifies which version of TG to install internally (This also answers ChrisM's question). This is also why I always say that the tgsetup.py way is the official installation method for TG 1.0, because the easy_install way may break at any time. This behaviour of easy_install is not specific to TG or its packaging, easy_install does the same for all packages. For example if you currently do easy_install SQLAlchemy, you get a 0.5 release candidate not a 0.4 stable release. easy_install has no notion of stable or supported releases it only knows that release candidates are older than release versions with the same version number. The only way to work around this is: a) You tell easy_install which version you want (which makes it difficult to give consistent installation instructions to users). b) You point easy_install to a package index where only the stable packages (and all dependencies) are and tell it to not look somewhere else (i.e. at the PyPI). This is the reason why I wrote the tgsetupng.py script [1] [2] and EggBasket [3]. IMHO having it install a non release is really weird. 1.1b1 *is* a release, it's just not a stable one, but easy_install doesn't care. I as a user would always expect easy_install to give me something known good and expect to have to ask specifically for a beta. Unfortunately that expectation doesn't match reality. Now I will defer to those in charge of course, but I really believe this is a case of bad packaging and does not contribute to our reputation in the marketing department. I'd like to humbly request that this be brought up on the main list to see what people actually are expecting. As explained, this is not a packaging issue, it's an issue of how to use easy_install correctly and how to provide the right package index structure for it. I have written about the issues with easy_install several times on this and the main TG mailing list, please search the archives if you want to know more. Chris [1] http://trac.turbogears.org/ticket/1785 [2] http://trac.turbogears.org/browser/projects/tgsetupng/trunk [3] http://pypi.python.org/pypi/EggBasket Okey dokey, thanks for the explanation Chris. I got the wrong impression from the way the previous discussion on this petered out. Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: Opinions requested re css framework and IE6
On Mon, 2008-22-09 at 08:02 +0100, [EMAIL PROTECTED] wrote: On 9/22/08, Christopher Arndt [EMAIL PROTECTED] wrote: +1 gazillion on not wasting your voluntary effort for TG on supporting this outdated piece of crap. If customers want support for IE6 they should pay for it BIG TIME. I'm 100% with Chris on this one. This template is mostly going to be seen by potential developers; I very much doubt that particular group will be using IE6. Or at least as soon as IE8 is out it won't. ;-) Ok, good to know, thanks for the feedback. I think in the interest of timeliness what I will do is to try to establish the basic html structure, layout, class, and id guidelines, and make the TG template pages first so y'all can let me know what you think of the structure. Probably will require a week or so though as it's being squeezed in between badly needed client time. Thanks Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Easy install is installing a beta again!
Hey folks, dunno if this is intentional or not, but easy_install turbogears is now installing 1.1 beta. Shouldn't this default to 1.0.7? Thanks Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: Easy install is installing a beta again!
On Tue, 2008-23-09 at 02:06 +0200, Christopher Arndt wrote: iain duncan schrieb: Hey folks, dunno if this is intentional or not, but easy_install turbogears is now installing 1.1 beta. Shouldn't this default to 1.0.7? No, easy_install is always installing the latest version, that's available on the download page linked on the projects PyPI page. Thatswhy the official and supported installation method is the one described on http://docs.turbogears.org/Install using the tgsetup.py script, which will install the correct current stable version. The last time we discussed this on here ( with Florent ) I'm pretty sure everyone agreed that easy_install should install the latest release, not the latest release candidate or beta. I haven't looked up the thread, but that is my recollection, possibly erroneous. Florent, do you recall? IMHO having it install a non release is really weird. I as a user would always expect easy_install to give me something known good and expect to have to ask specifically for a beta. Now I will defer to those in charge of course, but I really believe this is a case of bad packaging and does not contribute to our reputation in the marketing department. I'd like to humbly request that this be brought up on the main list to see what people actually are expecting. my two cents Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: Easy install is installing a beta again!
On Mon, 2008-22-09 at 22:07 -0700, iain duncan wrote: On Tue, 2008-23-09 at 02:06 +0200, Christopher Arndt wrote: iain duncan schrieb: Hey folks, dunno if this is intentional or not, but easy_install turbogears is now installing 1.1 beta. Shouldn't this default to 1.0.7? No, easy_install is always installing the latest version, that's available on the download page linked on the projects PyPI page. Thatswhy the official and supported installation method is the one described on http://docs.turbogears.org/Install using the tgsetup.py script, which will install the correct current stable version. The last time we discussed this on here ( with Florent ) I'm pretty sure everyone agreed that easy_install should install the latest release, not the latest release candidate or beta. I haven't looked up the thread, but that is my recollection, possibly erroneous. Florent, do you recall? Here is the thread I was thinking of. It sounded to me like Florent was agreeing in principal, but maybe a policy change never actually happened. http://groups.google.ca/group/turbogears-trunk/browse_thread/thread/657354f25d642c26 Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: quickstart: css framework evaluation
On Sun, 2008-21-09 at 12:50 -0700, Daniel Fetchinson wrote: None of them were really designed with the criteria in mind that we as programmers want. I think the reason is that css frameworks are used first and foremost by designers and not programmers. Most of the time the programmer doesn't even touch the templates let alone the css stuff. And the fact is that designers don't think the way programmers do so css frameworks most of the time are required to meet a different set of criteria. But if you come up with a css framework which is geared towards programmers I would be happy because in my (very) small scale projects I'm the programmer, template author and designer in one :) That's precisely what I'm thinking. Something where the html structure and id/classes are reflective of the kind of things we typically do when parsing and selecting elements for template generation/iteration, dom swapping, ajax submission, etc. I think in general designers have an understandable love of very minimal extra attributes, which makes sense for them. But structured attributes and extra layers with specific functionality is really useful to coders. It will no doubt take a few tries though! ;-) Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: Is anyone willing to champion this ticket?
On Sun, 2008-21-09 at 23:16 +0200, Florent Aide wrote: http://trac.turbogears.org/ticket/1860 to make it quick: this is a patch that adds (not tested) support for the DejaVu orm in TurboGears. Adding this would mean more support effort on our part, more quickstart templates to test, more tests to run each time. So I ask here if some people are interested to see this happen. And when I say interested I mean also interested to support it in the long run like we are doing for the whole TG stack. In concept, I like the idea, in that it makes TG's identity as a choose-your-components stack stronger. But I have no inkling of how much work that would be or whether it would be worth it. Now, maybe Robert Brewer would be interested if we are serious about CP3 support in 1.5? I can't blame him for losing interest in TG2. $CAN0.02 Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: quickstart: css framework evaluation
On Sun, 2008-21-09 at 18:14 -0500, Ian Bicking wrote: iain duncan wrote: I think I will spend some time evaluating the state of the various css frameworks for the quickstart templates. Thought I'd check first to see a) what people think are important criteria b) what people think are contenders or should be eliminated It seems to me it makes the most sense to use a set of id and class tags that are already being used by a good framework in order to add a level of pluggability. Thoughts? I'm curious what you'll come up with, as the idea of a good CSS framework is very compelling to me, in or out of TurboGears. For me the interest is more applying a common look-and-feel across systems, which requires some sanity in CSS, and all stylesheets will have some degree of insanity when they are developed organically from scratch. I'd like something that uses more semantically-oriented class names instead of some of the garbage names I've seen before. I think the reason for the garbage names is that there's lots of optional ways to lay out the page, and you use different ids or class names depending on the layout. It seems much preferable to have some kind of builder that creates a basic stylesheet based on layout preferences, and all layouts use the same ids or class names (though of course some will have more than others, e.g., 3-column will have classes a 2-column layout does not). A good template for a stylesheet would also have a template for a style guide. For any substantial site I've worked on with multiple people (including designers and programmers) some kind of style guide is really helpful. Generally a page that lists all the styles, i.e., all the recommended tags, any special classes, and advice on where to use them. Sounds like you're thinking on the same page as me, so I will certainly send you some alpha ideas. I forget how much I hate IE6 until I sit down to redesign things, aack. Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: auth, state of TG2 components
On Sun, 2008-21-09 at 22:01 -0700, Ademan wrote: And what would you have your army do? I'm not entirely sure how much time i'll have this week, nor how useful I can be, but I'm willing to contribute... heh. Oh you know, make soap, blow up data centers, and don't ask questions. ;-) (Sorry, can't resist the mixed image of Mark and Fight Club with a setup like that! ) Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: quickstart overhaul proposal and TG marketing
On Sat, 2008-20-09 at 11:06 +0200, Christoph Zwerschke wrote: http://trac.turbogears.org/ticket/1640. Makes sense, but I'm thinking I could work on the content of the examples prior to completion of that ticket eh? Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: quickstart overhaul proposal and TG marketing
On Sat, 2008-20-09 at 13:33 +0200, Florent Aide wrote: On Sat, Sep 20, 2008 at 11:17 AM, iain duncan [EMAIL PROTECTED] wrote: On Sat, 2008-20-09 at 11:06 +0200, Christoph Zwerschke wrote: http://trac.turbogears.org/ticket/1640. Makes sense, but I'm thinking I could work on the content of the examples prior to completion of that ticket eh? Iain Once we've worked out the administrative details, I hope you'll be able to begin hacking directly on the css and templates content. The ticket Chris talked about could be handled by me, chris*, deets or whoever else feels he wants to help on that subject. Should I perhaps make a branch for working on this? I expect to be trying several things out and showing them to the list and I'd rather not de-stabilize the trunk checkout while I do it. Thanks Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] quickstart: css framework evaluation
I think I will spend some time evaluating the state of the various css frameworks for the quickstart templates. Thought I'd check first to see a) what people think are important criteria b) what people think are contenders or should be eliminated It seems to me it makes the most sense to use a set of id and class tags that are already being used by a good framework in order to add a level of pluggability. Thoughts? Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: quickstart: css framework evaluation
On Sat, 2008-20-09 at 11:52 -0700, iain duncan wrote: I think I will spend some time evaluating the state of the various css frameworks for the quickstart templates. Thought I'd check first to see a) what people think are important criteria b) what people think are contenders or should be eliminated It seems to me it makes the most sense to use a set of id and class tags that are already being used by a good framework in order to add a level of pluggability. Thoughts? Well, I spent a good afternoon looking through the leading contenders, and pretty much ruled everyone one of them out for one reason or another. The only thing close was Boilerplate ( and to a lesser extent, Blueprint ) but that didn't seem to be coming with enough extras to warrant it.) None of them were really designed with the criteria in mind that we as programmers want. I think I'm going to spend some time polishing up the rough stuff I've been doing and publish it as a simple xhtml/css framework intended for programmers, where decisions are made to reflect that we will likely be using TAL templating, xml parsers, ajax dom swapping etc. So if no one hears from me on this front for a bit, that's what's up. Florent, how soon were you hoping to release a new welcome page? Thanks Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: New css for TG 1.1 quickstart template.
On Fri, 2008-19-09 at 08:58 -0500, Lukasz Szybalski wrote: On Fri, Sep 19, 2008 at 8:06 AM, Christopher Arndt [EMAIL PROTECTED] wrote: Ken Kuhlman schrieb: On Thu, Sep 18, 2008 at 6:45 PM, Florent Aide [EMAIL PROTECTED] wrote: I created a ticket #1992 in our trac and begun work on it. My concern with the original wording here was that it sounded a little bit defensive. A quickstarted template isn't the right place for that, since it's one of the first things a new TG customer sees. We should strive for warm, friendly, engaging. [...] Regardless, support timelines are a topic for blog posts perhaps the main webpage, but not a quickstart template. I'd also prefer that we didn't say 1.x in this context, but rather specify 1.0.x specifically. 1.x will live on as long as people are interested in it, just like any software project. (Obviously I'm biased, but I think 1.5 opens up a whole new world of possibilities for us.) I fully agree. Quickstart templates should show off the best of TurboGears (without being overly complicated and bloated) and give pointers where users can learn more, if they want to. While we are on this topic..would we be interested in having a build in menu? I have talked to a guy who created this menu: http://www.cssplay.co.uk/menus/final_drop2.html and if his name is listed and shows a copyright notice he would be willing to release it under BSD license for turbogears use. This was the only cascading menu I was able to find that works when you move the menu around in places, and it works on all browsers. I have one that does the above and can be used on all browsers. I'm happy to share that code. Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: New css for TG 1.1 quickstart template.
On Fri, 2008-19-09 at 01:45 +0200, Florent Aide wrote: Hi all, I created a ticket #1992 in our trac and begun work on it. Attached is a screen grab of how it looks like on my machine. Sorry for the file size but trac did not accept my attachement. The text is not finalized and Ken is working on it right now. Please don't hesitate to comment, propose, improve whatever... The most important thing for me is not that we keep this design or do something radically different... It is that TG gets a new quickstart template that make people like their first sight of it. Florent. Florent, looks good. I think it is a great plan, but perhaps the art could be chosen more thematically. I think we could find cheap stock photos of something more 'gear' related in the same a style that would look great in the same place as that black and white photo. Maybe ditto for the wood. I have some photographers with whom I work who are building stock photo portfolios. I could talk to them, they might be interested in donating photos for a credit on the site. Thoughts? Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: New css for TG 1.1 quickstart template.
On Thu, 2008-18-09 at 19:37 -0500, Lukasz Szybalski wrote: On Thu, Sep 18, 2008 at 7:02 PM, Kevin Horn [EMAIL PROTECTED] wrote: I think it looks great! Kevin Horn On Thu, Sep 18, 2008 at 6:45 PM, Florent Aide [EMAIL PROTECTED] wrote: Hi all, I created a ticket #1992 in our trac and begun work on it. Attached is a screen grab of how it looks like on my machine. Sorry for the file size but trac did not accept my attachement. The text is not finalized and Ken is working on it right now. Please don't hesitate to comment, propose, improve whatever... The most important thing for me is not that we keep this design or do something radically different... It is that TG gets a new quickstart template that make people like their first sight of it. My opinion is I think it is a little too much. I think you got some talent as far as web design and I think I would love to have a page looking like that but if I was to modify it and use it for my project website I think it would be easier to modify original css template, stick with same colors and replace tg specifics url with my project specifics url and I'm done. So I'm looking for most fit (will fit 70% of cases where you develop business apps) and easy of adaptation. So for graphically appealing you get A+, but for business usability and adaptation C. I think the original version of css has (B in first category, and A in second) I think your point is well taken, but I disagree on the original, it was not usable either. I do hard core css work for clients, and we'd never use the TG one as a starting point. A good solution would be to break the css into three files: layout.css - layout only, can be based on one of the css frameworks text.css - text formatting only ( fonts, letter spacing, etc ) turbogears.css - the stuff that pulls in the visually appealing bits, all images can be done as background images, colours as background colours. If we do the above, all people have to is delete turbogears.css and they wind up with what you are looking for with an A! Hey, this is actually something around here I'm qualified to do. Florent, if you want help with that I'd be happy to do so. Some of my xhtml/css work: www.momcafe.net rugsy1470.webfactional.com ( not yet launched obviously ) www.bradydahmer.com www.maynestay.com www.eatlocalfood.ca Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] vcs and ticketing and so on for new project
I am working on a new project that uses toscawidgets extensively, and will likely use Rum aswell down the road. It's a framework/scaffold for building custom CMS's, principally for TG2, but like rum/tosca, I intend to make it so that a fairly simple set of adapters will allow it to be used on other python web frameworks. I would like to make this available to others as well when it's ready. Sooo, I'm trying to figure out what the heck to do for version control, wiki, docs, tickets. TG was svn+trac and is now using sphinx, which i like. Do we know if TG2 is staying on svn? I think toscawidgets and rum will be the closest and most foundational related projects, so it makes sense to share as much of that as possible but I expect TG to be target platform for quite some time. mecurial? svn+trac? launchpad+bazaar? what the heck is the launchpad or trac equivalent for mercurial anyway? ( trac? ) thanks! Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: vcs and ticketing and so on for new project
On Thu, 2008-11-09 at 17:10 -0400, Mark Ramm wrote: svn+trac, mercurial+trac, bazaar+launchpad, and I guess bazaarr+trac is possible too. You can use sphinx in any of those contexts. IMHO. Definitely use sphinx. If it's a closed source project use trac. I you want DVCS use mercurial+trac, otherwise svn+trac. It's possible that TG2 could use bzr+launchpad (the idea has been raised at least). But, I'm not sure that it's something you'd want to emulate in that, since the main reason to use it is to get better bug-tracking across TG+upstream dependencies, and to get launchpad hosting for free. Also, launchpad will certainly be bazaar only correct? Which seems like a poor choice for me given that pylons and toscawidgets are using mercurial. I also like that trac uses genshi. thanks for the input Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: Mercurial for TG2 discussion
I'm not 100% sure I follow you here. What is your suggestion? I think it makes sense to maintain a svn repository that has reasonably current code for several months at least. The question is how often to merge changes over to that repository, and how fine-grained the history of that repository needs to be. Would it be good enough to just do a svn checkin nightly from the current mercurial tip? -- perferably only if all the tests pass. ;) Or should we try to automate it so every changeset is pushed over separately? If I were the user in question, I would not find it all unreasonable to have daily snapshots, and would probably prefer daily passing snaps. After all, if I *need* bleeding edge, I can get it via hg and merge myself. Yea, we should definitely document how the conversion is done, and how people can move their TG related projects to our new hg+trac system when they want to make that change. A big +1 on that. Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: Help, Did the identity template break in TG 1.0.6???
On Fri, 2008-05-09 at 08:12 +0200, Florent Aide wrote: On Fri, Sep 5, 2008 at 8:04 AM, Florent Aide [EMAIL PROTECTED] wrote: On Fri, Sep 5, 2008 at 4:04 AM, iain duncan [EMAIL PROTECTED] wrote: Hi folks, I just easy_installed up to TG 1.0.6. I have SA 0.4.3 installed, and a python shell importing SA definitely is getting that version. Now quickstarted projects with identity are producing old sa 0.3 code, with assign mapper and session.context. Weird... Let's look deeper into this... Well after testing I confirm that it works without error here. I suspect you have an old tg-admin somewhere in you path that was used instead of the new one. Maybe a tg-admin installed by your Linux distribution that is in /usr/sbin and you new easy_installed one in /usr/bin or something similar... Hey Florent, this is weird. I have verified that I have only one tg-admin, no extra in local/bin. When I run $ tg-admin In the shell, I get the usage message for tg-admin 1.0.6 But when I do $ tg-admin quickstart, still the old model. Would anything cause a different tg-admin or components to get used on only the quickstart? It's not a show stopper for me because I have other projects to copy the model over from, but I'm sure confused as to how and why it started doing this. Thanks for looking into it so quickly! Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Help, Did the identity template break in TG 1.0.6???
Hi folks, I just easy_installed up to TG 1.0.6. I have SA 0.4.3 installed, and a python shell importing SA definitely is getting that version. Now quickstarted projects with identity are producing old sa 0.3 code, with assign mapper and session.context. Anyone know what happened? Is there something that could be amiss on my end? thanks Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TurboGears-1.5 and transactions
On Fri, 2008-22-08 at 12:19 -0400, Mark Ramm wrote: But to get this refactoring moving we would need to have an easy to install tg1transaction manager. I am wondering if we could not use remoze.tm in tg 1.5 since CP3 is wsgi compliant... This would make us even more close to tg2. An alternative would be to make repoze.tm into a cp3 tool. This in some ways would be the best of all worlds, because it would allow for 1.5 code to use the same API as tg2 for managing transactions in controllers ( eg, killing a transaction with transaction.doom() ) and would take advantage of the the performance and flexibility that CP3 tools provide. +1 on that idea from a users perspective. Seems the most like putting the right tool in the right place. Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TG 1.x releases
On Thu, 2008-21-08 at 17:37 +0200, Florent Aide wrote: Ken, I fully agree with this. I have two questions here: 1°/ Is 1.5 ready for a beta release? How much work would still be required in it? 2°/ Does anyone else have an objection to release of the 1.1 branch (1.1beta1) in 24 hours? If anyone has some patches/pet tickets please say so now. 1.1 is pretty darn stable and really needs a release. I'll go for a beta because we'll inevitably have questions coming from our user base and I want to be able to release a real 1.1 after 2 weeks. In our first vision we wanted to have TW in the 1.1 release but it seems to be non realistic. I am completely ok with you to get this in the 1.5 branch instead of the 1.1 (which is a sine qua non condition to be able to release 1.1 beta). Last but not least: I'd like to warmly and publicly thank you Luke Macken for all the efforts you've put in TurboGears 1.x development! +1 million! I believe that having a supported stable branch and a transition branch with CP3 will really make a huge difference to TG adoption. It gives me confidence that the release schedule is being driven by a solid plan. Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: Controller differences between tg1 and 2
On Mon, 2008-07-07 at 00:14 -0400, Mark Ramm wrote:
It seems that some folks were actually using the feature of CherryPy
which turned ?name=Eduname=Rogername=Mark into a
name=['Roger','Mark] parameter.
I tend to think this feature is a little bit strange because if for
some reason I only wanted to pass up name=Mark I'd get a string not a
list as the name param.
In TG2 we're just passing along name=Roger in the above case but
other name elements are available from the request.GET multidict:
http://pythonpaste.org/webob/index.html#multidict
So you could do:
request.GET.getall('name')
Which will return the list ('Roger', 'Mark) and will *always* return a
tuple, so there's no ambiguity.
TG2 could add a compatibility mode that makes these things happen,
or we could use a decorator to give us a more backwards compatible way
of working, but I rather like the fact that I can predict what I'm
getting the current way, so I'm a bit hesitant to go too far down that
road without some more significant feedback from users.
I use the fact that cherrypy gives me a list when I have multiple inputs
in a form with the same name, and have found it really useful for
fileuploads by allowing one to send a delete current file flag to the
same validator. So I'd appreciate it sticking around in some form.
I found it handy because all the values for the model attribute
something_file can be in the same widget, share the same input name,
and one validator receiving one value ( a list ) sorts out whats
ultimately supposed to happen to the attribute of the model object based
on the combination of values. Specifically I have a file input for
uploading new, a hidden input with the old file name and a checkbox for
'delete the whole mess'. I'm not clear if this usage will be affected by
what your proposing though, as it's only with form inputs that I'm using
it.
So, I guess I vote for the backwards compatible decorator?
Thanks for listening!
Iain
Any thoughts?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
TurboGears Trunk group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---
[tg-trunk] Re: TG 1.x releases
On Sat, 2008-21-06 at 23:46 +0200, Florent Aide wrote: Hi all, I have discussed today with python developpers from other projects and one of the remarks I noted was that the version numbering we choose make them feel like TG is not evolving. While pondering this I felt like they were quite right. Why keep 1.1 as a number for our next iteration? I feel like the next big one should be 1.2 (1.1 head as it is now) and next next shinny one 1.5 (the one based on 1.1 branch but with all the goals we wanted -- no more tg widgets and all the fluff). I am prep'ing an 1.0.4.5 release for tomorrow, and would like to release an 1.2 (the head of the 1.1 branch). This would help maintain existing applications for people who cannot migrate to 1.2. And this would help people adopt our 1.2 technos a bit more. I tell you directly: you need really strong and based arguments to change/stop this, because we badly need some perceived movement on the TG scene and this is one of the ways to get some. +1 from me. Thanks for thinking about this stuff. Genshi, SA, and ToscaWidgets are really great libraries and we should make it clear that 1.whatever_that_makes is a big step forward. Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TG 1.x releases
On Sat, 2008-21-06 at 19:20 -0400, Mark Ramm wrote: I tell you directly: you need really strong and based arguments to change/stop this, because we badly need some perceived movement on the TG scene and this is one of the ways to get some. Sounds good to me.I'm also planning to do a 1.9.7 alpha 1 release this week. I cleaned up the look and feel of the quickstart template this afternoon, I'll be working through a review of the 1.9.7 docs tomorrow, and hopefully closing out all 1.9.7 related tickets tomorrow or monday. If you want to help out there are plenty of tickets you can work on here: http://tg2tickets.urlhash.com I want to try to get all preview 1 tickets finished before the first alpah, and all the preview 2 tickets before the second alpha. I'll blog about the reasoning behind this, but my tentative plan is to move the TG2 release process to a time based system, much like the system made popular by the Ubuntu project. The plan will be to have monthly alpha releases, and to have a tg 2.0 final release by a set date, probably sometime this fall. We'll do another release several months later, I'd like to have tg2 releases available for packaging in Ubuntu multiverse on a regular basis, so long term we may want to sync up our schedule with what's happening in the Ubuntu world. That sounds great Mark. As far as I can tell in my limited experience, Ubuntu server seems to be running away with the prize for most popular modern python web serving distro, so working tightly with that will IMHO significantly increase the attraction of TG. It would be sweet if we could get a dead easy out-of-box experience with TG2 and mod_wsgi on Apache happening down the line! my two cents Canuck Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TG2 status update
On Wed, 2008-18-06 at 20:53 +0100, Paul Johnston wrote: Hi, give me a bit of time for my SecureController stuff :) Mmmm... that sounds interesting. What is it? If it's a souped up TG2 version of SecureResource I will be a very happy camper! =) Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TG2 Install problems and fix notes
On Tue, 2008-17-06 at 09:34 -0400, Mark Ramm wrote: Could you make a ticket on Trac for this (trac.turbogears.org) and assign it to Milestone: 2.0-preview-1 ? Should I put each issue on it's own ticket or just make one ticket and attach the file? I am going to try very hard to get everything in 2.0-preview-1 cleaned up in the next 24 hours or so. Cool. Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TG2 Install problems and fix notes
On Tue, 2008-17-06 at 15:32 -0400, Mark Ramm wrote: Should I put each issue on it's own ticket or just make one ticket and attach the file? Either way is fine with me. If you make a doc-updates tickets with a bunch of attachements, that will probably go quicker for you, and for me. Hey folks, I just tried to create a ticket attaching the text file with the errors and corrections and got rejected as spam: Submission rejected as potential spam (Maximum number of external links per post exceeded, Akismet says content is spam) Can we change the threshold on that or should I just submit a wack of individual tickets? iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TG2 Config system rethought...
On Sun, 2008-15-06 at 23:10 -0400, Mark Ramm wrote: I removed a bunch of code from the TG2 project quickstart template. in the config directory we had middleware.py, which setup the entire middleware stack for your TG2 application. 90+ percent of the time people are not going to mess with this, but we've already changed it several times on users (in development), creating backwards compatibility issues inside their templates. So, I've now got it set up to configure the middleware that needs to be there automatically for you in the framework. Users who want to take on the responsibility of managing their own wsgi stack can do so easily enough, and beginning users don't have to worry about it at all. My plan is to setup the environment.py file in the same way if there are no objections. In both cases, there may be common configuration settings that we want to address in the framework setup. I think the identity stuff that's in there now provides a reasonably good example of what we can do. This should not break existing TG2 project's at all, because they will just not use the new automatic setup stuff. But for new project it will make upgrading from one TG version to another much simpler. Sounds like a great plan to me! It's easy to forget how scary the config stuff is to new users. Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] tg2 equiv of tg-admin sql create?
Is there or will there be a tg2 equivalent of sql create? I personally find that a really nice feature of tg1, much easier than making the script as noted in the tg2 wiki tutorial. thanks iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: tg2 equiv of tg-admin sql create?
On Mon, 2008-16-06 at 14:42 -0300, Laureano Arcanio wrote: You can run: paster setup-app development.ini That command should work much like the tg-admin sql create. And you can get more info here: http://turbogears.org/2.0/docs/main/SQLAlchemy.html#quick-database-creation Thanks! Perhaps we should add this to the doc page where the tg-admin command equivalents are listed? ( I haven't learnt how to use Sphinx yet, I'll get on that ...) Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] mistake in tg2 model template
I believe there is a mistake in the tg2 model template. The table uses the SA type names under the namespace 'types' but types is not imported in the header. I anticipate doing a bunch more tg2 and fun development over the next while, so what do I need to do to be able to correct things like this when I find them? thanks Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] dbmechanic in tg2
First off, yay Chris, the db mechanic catwalk replacement looks sweet! Second, um, it doesn't 'look' sweet per se, the css is pretty mucked up on my setup. Maybe I could help fix that, but I should check whether any one else is first. I've been doing a lot of gun-for-hire front end stuff lately. Thanks! Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] TG2 Install problems and fix notes
Hi folks, I compiled a list of problems and fixes for following the tg2
install instructions. I did an install into an empty virtual env, maybe
we could add ve instructions too.
I'm hoping someone can look over this and then I can help update the
install instructions if these get the stamp of approval. Or you might
now how to fix the issues!
thanks
Iain
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
TurboGears Trunk group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---
Notes on setting up TG2 in a virtual env:
- install virtualenv if not present
$ easy_install virtualenv
- make a virtualenv for tg2
$ virtualenv TG2
$ cd TG2
$ source bin/activate
- make a local python egg cache for the virtual env
( without doing this, my local python egg cache got used and caused problems )
mkdir .python-eggs
export PYTHON_EGG_CACHE=./.python-eggs
( the above should probably be added properly into bin/activate )
- install Pylons 0.9.7
$ easy_install -f http://pylonshq.com/download/0.9.7 -U Pylons
- install Paver
$ easy_install Paver
- get source for tgdev, tg2, tg.ext.repoze.who
$ svn co http://svn.turbogears.org/projects/tg.devtools/trunk tgdev
$ svn co http://svn.turbogears.org/trunk tg2
$ svn co https://tgtools.googlecode.com/svn/projects/tg.ext.repoze.who/trunk
tg.ext.repoze.who
- ERROR: username and password required
- FIX: use http instead of https
$ svn co http://tgtools.googlecode.com/svn/projects/tg.ext.repoze.who/trunk
tg.ext.repoze.who
build tg.repoze.who:
$ cd tgrepozewho
- ERROR, wrong file name, should be tg.repoze.who
- FIX: cd tg.repoze.who
$ python setup.py develop
- ERROR:
Searching for zope.interface==3.4dev-r73809
Reading http://pypi.python.org/simple/zope.interface/
Reading http://zope.org/Wikis/Interfaces/FrontPage
No local packages or download links found for zope.interface==3.4dev-r73809
error: Could not find suitable distribution for
Requirement.parse('zope.interface==3.4dev-r73809')
- FIX - install zope.interface first
$ easy_install zope.interface
- ERROR - no Paste==1.7.2dev-r7430
Reading http://pythonpaste.org
No local packages or download links found for Paste==1.7.2dev-r7430
error: Could not find suitable distribution for
Requirement.parse('Paste==1.7.2dev-r7430')
- FIX: - install dev of Paste first
$ easy_install Paste==dev
( repoze builds ok )
build tg2
$ cd ../tg2
$ python setup.py develop
- ERROR: no PasteScript==1.6.4dev-r7434
- FIX: install PasteScript==dev
$ easy_install PasteScript==dev
( TG2 builds ok )
build tgdev
$ cd ../tgdev
$ python setup.py develop
( builds ok )
validate install
$ paster --help
( yup, TurboGears2 is listed )
quickstart an app
$ paster quickstart testapp
$ cd testapp
$ paster server --reload development.ini
look at localhost:8080
( Tada! )
[tg-trunk] tg2 dependency issue
I got as far as installing tg2 seemingly successfully, and created a test app. I'm confused by this though: $ paster server --reload development.ini Traceback (most recent call last): File /usr/local/bin/paster, line 7, in ? sys.exit( File /usr/lib/python2.4/site-packages/PasteScript-1.6.4dev_r7434-py2.4.egg/paste/script/command.py, line 68, in run commands = get_commands() File /usr/lib/python2.4/site-packages/PasteScript-1.6.4dev_r7434-py2.4.egg/paste/script/command.py, line 110, in get_commands plugins = pluginlib.resolve_plugins(plugins) File /usr/lib/python2.4/site-packages/PasteScript-1.6.4dev_r7434-py2.4.egg/paste/script/pluginlib.py, line 81, in resolve_plugins pkg_resources.require(plugin) File /usr/local/src/Pylons/setuptools-0.6c8-py2.4.egg/pkg_resources.py, line 626, in require File /usr/local/src/Pylons/setuptools-0.6c8-py2.4.egg/pkg_resources.py, line 524, in resolve pkg_resources.DistributionNotFound: Not Found: tg.ext.geo (did you run python setup.py develop?) Is this supposed to to be this way? Should I need tg.ext.geo to start a sample app? Thanks! Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: tg2 dependency issue with tg.ext.geo
On Sat, 2008-14-06 at 14:53 -0700, iain duncan wrote: I got as far as installing tg2 seemingly successfully, and created a test app. I'm confused by this though: $ paster server --reload development.ini So I did a double check on this and indeed with checkouts of everything as of today, new projects are getting made with tg.ext.geo listed in the paster_plugins.txt file. Deleting the line fixed it. I'm guessing that's not really supposed to be there eh? Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: validation
On Thu, 2008-12-06 at 23:42 -0300, Laureano Arcanio wrote: Hi ! I'm building an app in TG2, but my question is about the validation mechanism, i've building some kind of web components that wraps a few widgets and locate them in a structured html, and the problem is that i don't return the forms directly, instead a compound widgets with forms and other stuff. I'm not sure of how tg2 validation mechanism works but i'm really interested on keeping my web components, is there any way i can make validation for it ? i mind, how i can catch those messages and manually put them in the form ? ( or something like that ) ( This web components are the vertebral column of lymon ) Any light on how it's work can help me too. Hi Laureano, if you can't get TG2 doing what you want ( yet! ) it's not difficult to do validation directly with formencode. Ian has improved the formencode docs substantially in the last year; I had to dig into it for a wxpython app that I was doing and trying to emulate the tg patterns and I got along quite well. HTH, Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: ANN: tg.ext.silverplate 0.1rc1
On Tue, 2008-03-06 at 20:04 -0700, percious wrote: Announcing the first release of tg.ext.silverplate. SilverPlate is the new user management/profile management system for TurboGears2. It provides a series of pages that allow developers to quickly build a site with Users, Groups, and Permissions. More information is here: http://code.google.com/p/tgtools/ Special thanks to Laureano Arcanio, amd Mark Ramm for their support. Does this use the repoze.who system then? That sounds pretty interesting. thanks Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] tg2 install problem with pylons from mecurial
Thought I'd get back on the TG2 again, but I get the following when I
try to check out Pylons from mecurial:
$ hg clone http://pylonshq.com/hg/pylons-dev Pylons
$ cd Pylons
$ sudo python setup.py develop
... ( lotsa stuff )
Processing dependencies for Pylons==0.9.7beta5dev-20080613
Searching for WebOb=0.9.2
Reading http://www.pylonshq.com/download/
Reading http://www.pylonshq.com/download/0.9.7
Reading http://pypi.python.org/simple/WebOb/
Reading http://pythonpaste.org/webob/
No local packages or download links found for WebOb=0.9.2
error: Could not find suitable distribution for
Requirement.parse('WebOb=0.9.2')
Anyone know what gives there? Should I be posting on pylons?
thanks
iain
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
TurboGears Trunk group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---
[tg-trunk] Re: tg2 install problem with pylons from mecurial
On Fri, 2008-13-06 at 10:10 +0200, Florent Aide wrote:
On Fri, Jun 13, 2008 at 10:03 AM, iain duncan [EMAIL PROTECTED] wrote:
No local packages or download links found for WebOb=0.9.2
error: Could not find suitable distribution for
Requirement.parse('WebOb=0.9.2')
Anyone know what gives there? Should I be posting on pylons?
Hmm, I just checked out WebOb from svn and installed it, it's there and
I can import it from a python shell. But I am still getting the above
error when trying to install Pylons.
I have the following webob in my site packages dir:
WebOb-0.9.2dev_r7404-py2.4.egg
0.9.2dev is 0.9.2
so technically speaking it cannot satisfy = 0.9.2
So are those instructions not supposed to be working right now? Or am I
missing some way of getting a WebOb that satisfies the requirements?
Thanks
Iain
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
TurboGears Trunk group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---
[tg-trunk] Re: tg2 install problem with pylons from mecurial
On Fri, 2008-13-06 at 01:36 -0700, iain duncan wrote:
On Fri, 2008-13-06 at 10:10 +0200, Florent Aide wrote:
On Fri, Jun 13, 2008 at 10:03 AM, iain duncan [EMAIL PROTECTED] wrote:
No local packages or download links found for WebOb=0.9.2
error: Could not find suitable distribution for
Requirement.parse('WebOb=0.9.2')
Anyone know what gives there? Should I be posting on pylons?
Hmm, I just checked out WebOb from svn and installed it, it's there and
I can import it from a python shell. But I am still getting the above
error when trying to install Pylons.
I have the following webob in my site packages dir:
WebOb-0.9.2dev_r7404-py2.4.egg
0.9.2dev is 0.9.2
so technically speaking it cannot satisfy = 0.9.2
So are those instructions not supposed to be working right now? Or am I
missing some way of getting a WebOb that satisfies the requirements?
I should clarify that I hit the same error installing Pylons from either
mercurial or easy install, so I'm not able to get past that at the
moment following the instructions on the tg2 doc page.
thanks!
Iain
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
TurboGears Trunk group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---
[tg-trunk] Re: tg2 install problem with pylons from mecurial
On Fri, 2008-13-06 at 13:08 -0400, Mark Ramm wrote:
BTW, this has been fixed in pylons mercurial, so hg pull -u should fix
the problem, and new hg checkouts will work.
--Mark Ramm
Thanks. I got a bit further this time, and now Pylons is giving me this:
Processing dependencies for Pylons==0.9.7beta5dev-20080613
Searching for WebHelpers=0.6dev-20080601
Reading http://www.pylonshq.com/download/
Reading http://www.pylonshq.com/download/0.9.7
Reading http://pypi.python.org/simple/WebHelpers/
Reading http://pylonshq.com/WebHelpers/
No local packages or download links found for
WebHelpers=0.6dev-20080601
error: Could not find suitable distribution for
Requirement.parse('WebHelpers=0.6dev-20080601')
I assume this is probably pre-0.9.7 release cleanup issues? I wonder if
perhaps a note should be added to the TG2 doc page indicating that? Is
it publically editable?
Thanks
Iain
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
TurboGears Trunk group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---
[tg-trunk] Re: TG2 landing page
- I personally don't like nextgen nextgen, a bit gimmicky True. But we need something concise and a bit catchy, and it was the best I came up with while writing the page. If you've got better test, I personally am not that attached to what we have now. Will ponder! It's important though for sure. For example Django's Web Development Done Right says a *lot* about the project, for better and for worse depending on your perspective. with the most powerful and flexible Object Relational Mapper (ORM) in the world, and sounds like hyperbole and will turn off people who disagree instantly. But it's the truth. ;) I can tone it down a bit though. Oh you're preaching to the choir there! ;-) This reminds of some of the old Django docs that really rubbed me the wrong way. SA doesn't need to be exagerrated This isn't docs, this is the marketing face of the project. There is a difference. But I agree that we may want to done down things a bit. I'm just thinking from a marketing perspective and reflecting back on my initial exposures to Django, TG, and Pylons. I am pretty much a TG target user, someone who doesn't need the lowlevel no frills basis of pylons, but likes to get my hands dirty and prefers many options of libraries over 1 Right Way. And I was turned off by the hyperbole of the Django docs because I know enough to recognize that there isn't one right way but too little to build it all myself. So IMHO, our target market does not need the same kind of GeeWhiz We Rock marketing. But it still needs marketing for sure! - I think the integration with Pylons should be more prominently mentioned, it's very important because whether we like it or not, TG is seen as languishing right now and the merge/build-over with pylons if a real life saver I agree somewhat. But I don;t want to emphasize the number of changes too much. The key here will be to highlight the tangible benefits of the pylons connection more. As to design concerns, I just used the existing design we had for TG. I'm looking at doing a new design, and that one will have more floating width so that we can make use of wider screens. yeah I figured that. Might be good to get more estate though. If css aid is needed that is somewhere I can pitch in easily. I've been doing a lot of that lately. Thanks for all the work put into the TG2 docs and public face, they are looking like they will be really good! Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TG2 landing page
On Sat, 2008-31-05 at 18:24 -0400, Mark Ramm wrote: I created a new TG2 landing page on turbogears.org: http://www.turbogears.org/2.0/index.html Ultimately I think we'll want to make this a bit more visually distinct from the main TG page. And when we do our first beta release (hopefully next week) I think we need to link to this page prominently from the TurboGears.org front page. A few comments re the marketing aspect, reject or use as you see fit ;-) - I personally don't like nextgen nextgen, a bit gimmicky - also this: with the most powerful and flexible Object Relational Mapper (ORM) in the world, and sounds like hyperbole and will turn off people who disagree instantly. This reminds of some of the old Django docs that really rubbed me the wrong way. SA doesn't need to be exagerrated - shouldn't pylons be in this sentence?: web frameworks including TurboGears 1 (of course), Django, and Rails. We - I think the integration with Pylons should be more prominently mentioned, it's very important because whether we like it or not, TG is seen as languishing right now and the merge/build-over with pylons if a real life saver - lastly, is there a reason we are using a width of 850px? as a front-ender for designers, I know they like space on the sides, but in this case I think we are too big for a dead old monitor and could have a more readable screen by taking it out to 950-1000px; thanks for listening! Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TG2 docs
On Sun, 2008-01-06 at 13:39 -0400, Mark Ramm wrote: How about a form that displays the ReST in an edit box and upon submitting it a patch is automatically generated and attached to a Trac ticket. I like it. Sounds like a very good solution, as long as we can manage the spammers effectively, so we don't end up with thousands of bogus trac tickets. We could do the same thing but have it go to a doc mailing list instead, if that would allow better spam filtering. Just a thought! Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: Google announces accepted students for GSoC 2008
On Mon, 2008-21-04 at 23:22 +0200, Christopher Arndt wrote: Hello everybody, Gogle has just announced [1] the projects and students that got accepted for this year's GSoC program. We, at the TurboGears project, feel priviledged that we can sponsor and mentor six (6) projects in our first year of GSoC participation! You can view all TG GSoC projects that have been accepted here: http://code.google.com/soc/2008/turbogears/about.html I'd like to congratulate all the students whose application was successful and thank *everybody* who submitted an application! We had a big number of very good proposals and we certainly would have liked (and been capable) to take on a few more projects, but as it is, we were happy (thanks to Mark Ramm's persuasion work) to wrestle 4 more projects from Google after we were assigned only 2 slots originally. Nice going Mark! ;-) Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: GSOC and website redesign
On Fri, 2008-28-03 at 16:43 +, Lee McFadden wrote: Hi Jorge, On Fri, Mar 28, 2008 at 1:31 PM, Jorge Vargas [EMAIL PROTECTED] wrote: my original idea was to build a job-seeking website for TG, but it can be molded into being merge with the main site. I actually already started a repository for this[1], although I am yet to upload any code. I will be coming out of my current heavy workload very soon and look to start making this gigboard app then. Maybe we could work together on this task? [1]: http://code.google.com/p/gigboard I'd be happy to kick in some templating/CSS'ing if that would help. I've been doing a lot of nit-picky front end lately and have all the major platforms set up at home for testing. I assume we'll use Genshi? Had you thought of what the javascript will be based on? jQuery anyone? ;-) Maybe we could even make sure the site (eventually) uses the layouts/css strategies that we were brainstorming including as examples or something. Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: GSOC and website redesign
On Fri, 2008-28-03 at 18:49 +, Lee McFadden wrote: On Fri, Mar 28, 2008 at 6:41 PM, iain duncan [EMAIL PROTECTED] wrote: I'd be happy to kick in some templating/CSS'ing if that would help. I've been doing a lot of nit-picky front end lately and have all the major platforms set up at home for testing. I assume we'll use Genshi? Had you thought of what the javascript will be based on? jQuery anyone? ;-) Any help will be appreciated of course :) I need to get the basic framework of the app up and running first though. For JS I prefer Mootools but I wouldn't complain too much if jQuery were used, it's still a really nice library. My main objection ( actually deal-killer ) for mootools was that the devs stated that they didn't care a niff about making it play well with others, while jQuery took the opposite approach. I've had no problems using jQuery plus mochikit, but Mootools was an all-or-nothing. To me that doesn't jive with the TG philosphy. ymmv! Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: CSS framework in TG2
On Mon, 2008-24-03 at 12:18 -0700, percious wrote: I personally dont think we should have a default css framework for TG2. I do a lot of CSS, and I agree. I just don't think the benefits of a framework are very much in comparison with other areas we can put work into. And I don't think it scales well across levels of expertise. I know plenty of advanced back end coders who use RoR, TG, Pylons, Django, Struts, etc, but no advanced front enders who use css frameworks. There are just way too many exceptions. my two cents! Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: CSS framework in TG2
On Mon, 2008-24-03 at 15:45 -0400, Mark Ramm wrote: I think we should make ToscaWidget for each of the css frameworks and then have good documentation about how to implement the widget site- wide. Site-wide implementation is not too hard, all a developer would need to do is modify their BaseController to use the widget, and then modify their master.html to display said widget. That makes good sense -- we should cover CSS frameworks like we do javascript frameworks -- by providing widgets and documentation. But if our user registration module, and form stuff could depend on a CSS framework, that might make it easier to have very good looking output by default. I don't know my way around the CSS framework world enough to pick one, thought he two I mentioned in my e-mail seem to be the most popular -- and they both provide web-based tools to customize the framework somewhat I think a library of sample/examples to go with the widgets would be more productive than a framework and I could actually contribute some best practices bologna to that. ;-) From what I've read/heard, the css frameworks just aren't that good, they're not like jQuery or Ext or anything. I don't think the relationship is the same or something, dunno. I could be wrong ... Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: Nitobi Survey Results on Ajax Development
On Tue, 2008-25-03 at 13:10 -0500, Kevin Horn wrote: On Tue, Mar 25, 2008 at 12:39 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Nitobi Survey Results on Ajax Development http://ajaxian.com/archives/nitobi-survey-results-on-ajax-development The result showed Mochikit got very low popularity. Maybe we should pick up a new best of breed js framework again in 1.1 or 2.0? -- Fred This amuses me to no end, since I just finished a project a couple of weeks ago where Mochikit was instrumental in working around the flaws and limitations of Nitobi's Grid software (which is pretty dismal...consider it anti-recommended). Irony much? This topic came up a couple of months ago (for TG2), and it seemed at the time that extjs was the most favored option, with jquery a close second. Of course, it wasn't a formal poll or anything, just a mailing list discussion. FWIW, jquery is gaining a lot of traction in related areas that I think feed into TG, for example Drupal. I personally think jQuery is a good fit on account of it's smaller size and more modular nature. But YMMV! ;-) Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TG 1.x and SA 0.4.3
On Thu, 2008-21-02 at 00:34 +0100, Florent Aide wrote: On Wed, Feb 20, 2008 at 11:42 PM, Christoph Zwerschke [EMAIL PROTECTED] wrote: Hi Florent, how is jour timing for the next release? I have just discussed a patch for the SA 0.4.3 issue and ticket #1721 with jek, and I think I have a very good patch now. I'd like to commit in an hour or so. I will also update the changelog. Hey Chris, this is good news. I'd like to release the next stable version during this week (end of ?) and as always I have found a lot of excuses to delay this release... but please fix this SA 0.4.3 issue... We need to notify every SA user of ours that now when updating an already existing entry in the database we need to use session.save_or_update() and not just session.save() Does session.flush() still work ok if we aren't worried about saving indiviudual objects? Thanks Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TG2 Identity (Authority)
Big things to do: - hook into the paste config system...probably will shamelessly swipe ideas from beaker (beaker's source is beautiful) - figure out all the setuptools magic I want to happen, though I guess it's not strictly necessary - fill out the infrastructure a bit to support what I want to do for the TG2 Scheme - write the TG2 scheme - write other schemes (httpbasic kinda works now, need httpdigest, OpenID, etc.) - write tests...not entirely sure how to go about testing this thing OMG, a question I can answer! ;-) Use Twill and import the twill commands into a nose test suite. Running functional tests with twill through nose is really easy and it does all your cookie stashing for you and let's you pretend to be different agents and stuff. Plus Titus and Gregio (sp?) are really helpful on the twill and testing python mailing lists. And there would be no reason you couldn't combine it with checks on what is in the raw db at the same time ( though I haven't quite figured out the best way to do this yet, baby steps for me). It is really easy to run long progressions of login and outs. I could actually help there, I've been writing twill tests of member sign up and status changing and editing ad nauseum for the last four days. Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: Flash
On Mon, 2008-04-02 at 19:27 +0100, Christopher Arndt wrote: Kevin Horn schrieb: On Feb 3, 2008 4:32 PM, Mark Ramm [EMAIL PROTECTED] wrote: But, I still like the idea of flash, and wold be happy to see it expanded upon, particlarly now that there's so little code.I seem to remember somebody doing a set of extensions to the tg_flash stuff in turbogears 1, does anybody remember where that was and weather it's worth including in tg2? The only thing I remember was Lee's article here: http://www.splee.co.uk/2005/11/23/fancy-status-messages-using-tg_flash/ A while ago, I took the idea from this article and built some general modules for an enhanced flash message display widget. The code is included in my CBlog application, but the newest version of this is not available for download atm. So, I took some time today, to build a proper TurboGears widget/extension package and now (*drum roll*) I present to you: TurboFancyFlash: http://pypi.python.org/pypi/TurboFancyFlash The package is for TG 1.x and it builds on the original turbogears.flash function. It also relies on the tg_include_widgets config option. I don't know if there's a similar mechanism for TG 2 and ToscaWidgets available. But in principle, the same technique should be easy to implement for TG 2 too. Here's my vote on just baking this right into the TG2 core. Yay! iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TG2 Identity (Authority)
I'll try to get the code up someplace in an SVN repos over the next couple of days, so that others can take a look. Please send your thoughts and opinions! This is much needed, go Kevin! My immediate thought is that when making the login methods for identity, we could make that code a lot easier to follow. I have to admit, I found figuring out how to get login/logout doing what I want in tg1 identity much more troublesome than I expected. That's a bit that could have a clearer api or maybe just way more comments in the code, or something! Thanks Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: identity docs got mucked up
On Sun, 2008-10-02 at 15:24 +0100, Christopher Arndt wrote: iain duncan schrieb: Hey everyone, dunno who's doc it is but http://docs.turbogears.org/1.0/IdentityManagement?highlight=%28identity% 29 got mangled up somehow! What do you mean? According to the page history, it got changed by me on 2007-12-17 the last time. Anyway, this is the old, one-page version of the identity docs. The starting page for the newer version is http://docs.turbogears.org/1.0/Identity. I should probably clean up this confusing, but I need to check for later changes to the old version first. Agreed, the identity docs index is confusing! What I meant is that the one I linked to is moin moin mucked. There are misformated tables and system error messages on the page. Thanks Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] identity docs got mucked up
Hey everyone, dunno who's doc it is but http://docs.turbogears.org/1.0/IdentityManagement?highlight=%28identity% 29 got mangled up somehow! Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: some thoughts on tg + javascript
On Sat, 2008-19-01 at 13:24 +0100, Alberto Valverde wrote: Hi Daniel, Daniel Fetchinson wrote: () 3. Let's pick a well-designed, robust and reliable javascript library and add functionally to tg that helps integrating it to any tg project. Users would have to write their javascript themselves but tg would automate some or most of the typical tasks that one needs to do in order to really make sure the client and server plays nicely together. This means that only minimal javascript code has to be maintained, only the basic API for client/server communication. I think the best choice would be the third one and as I have mentioned in an earlier post the Ext.js would be an excellent choice because it's a mature project, 2.0 was released some time ago. It's 100% documented and the documentation is top quality. It's very well-designed, unlike most of the other js libraries. It helps create maintainable and scalable code. It contains widgets for just about any use case and makes it easy to extend these widgets to create reusable new ones. The core size is not very big and it's possible to easily include only those modules which are actually needed. And last but not least it does not interfere with other js libraries. I've been very impressed lately with jquery. I remember reading something about an ext jquery project, is that a possibility? I'm not up on ext really, but jquery is very well documented and has good community support. And I think the author has a very TG compatible attitude. Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Help! TG + ToscaWidget + FormEncode upgrade breaking widgets
Hi all, I just upgraded by packages for the security fix, and now a
functioning piece of TG + ToscaWidgets doesn't work anymore. It appears
only to be happening with input widgets, my list and view widget are
still fine. Here is the traceback:
500 Internal error
The server encountered an unexpected condition which prevented it from
fulfilling the request.
Page handler: function _wrapper at 0x2ac06668
Traceback (most recent call last):
File
/usr/lib/python2.4/site-packages/CherryPy-2.3.0-py2.4.egg/cherrypy/_cphttptools.py,
line 121, in _run
self.main()
File
/usr/lib/python2.4/site-packages/CherryPy-2.3.0-py2.4.egg/cherrypy/_cphttptools.py,
line 264, in main
body = page_handler(*virtual_path, **self.params)
File
/usr/lib/python2.4/site-packages/TurboGears-1.0.4b6-py2.4.egg/turbogears/identity/conditions.py,
line 288, in _wrapper
return fn(*args, **kw)
File string, line 3, in default
File
/usr/lib/python2.4/site-packages/TurboGears-1.0.4b6-py2.4.egg/turbogears/controllers.py,
line 342, in expose
output = database.run_with_transaction(
File string, line 5, in run_with_transaction
File
/usr/lib/python2.4/site-packages/TurboGears-1.0.4b6-py2.4.egg/turbogears/database.py,
line 406, in sa_rwt
retval = func(*args, **kw)
File string, line 5, in _expose
File
/usr/lib/python2.4/site-packages/TurboGears-1.0.4b6-py2.4.egg/turbogears/controllers.py,
line 359, in lambda
mapping, fragment, args, kw)))
File
/usr/lib/python2.4/site-packages/TurboGears-1.0.4b6-py2.4.egg/turbogears/controllers.py,
line 386, in _execute_func
output = errorhandling.try_call(func, *args, **kw)
File
/usr/lib/python2.4/site-packages/TurboGears-1.0.4b6-py2.4.egg/turbogears/errorhandling.py,
line 72, in try_call
return func(self, *args, **kw)
File /home/cliffhanger/CliffVan/cms2/crudcontroller2.py, line 324, in
default
return method( id, **kwargs )
File /home/cliffhanger/CliffVan/cms2/image_admin_controller.py, line 240,
in edit
crud_widget = self.edit_widget( values, object=values, action=form_action,
parent_url=self.parent_url )
File
/usr/lib/python2.4/site-packages/ToscaWidgets-0.2rc3dev_r3795-py2.4.egg/toscawidgets/core.py,
line 467, in __call__
return self.display(value, **kw)
File
/usr/lib/python2.4/site-packages/ToscaWidgets-0.2rc3dev_r3795-py2.4.egg/toscawidgets/core.py,
line 463, in display
kw = self.prepare_dict(value, kw)
File
/usr/lib/python2.4/site-packages/twForms-0.2rc2dev_r3751-py2.4.egg/toscawidgets/widgets/forms/core.py,
line 200, in prepare_dict
kw = super(InputWidget, self).prepare_dict(value, kw, adapt=False)
File
/usr/lib/python2.4/site-packages/ToscaWidgets-0.2rc3dev_r3795-py2.4.egg/toscawidgets/core.py,
line 507, in prepare_dict
self.update_params(d)
File
/usr/lib/python2.4/site-packages/twForms-0.2rc2dev_r3751-py2.4.egg/toscawidgets/widgets/forms/fields.py,
line 239, in update_params
super(Form, self).update_params(d)
File
/usr/lib/python2.4/site-packages/twForms-0.2rc2dev_r3751-py2.4.egg/toscawidgets/widgets/forms/fields.py,
line 107, in update_params
super(FormField,self).update_params(d)
File
/usr/lib/python2.4/site-packages/twForms-0.2rc2dev_r3751-py2.4.egg/toscawidgets/widgets/forms/core.py,
line 216, in update_params
super(InputWidget, self).update_params(d)
File
/usr/lib/python2.4/site-packages/ToscaWidgets-0.2rc3dev_r3795-py2.4.egg/toscawidgets/core.py,
line 574, in update_params
attr = getattr(self,k,None)
File
/usr/lib/python2.4/site-packages/twForms-0.2rc2dev_r3751-py2.4.egg/toscawidgets/widgets/forms/fields.py,
line 89, in is_required
self.validate('', use_request_local=False)
File
/usr/lib/python2.4/site-packages/twForms-0.2rc2dev_r3751-py2.4.egg/toscawidgets/widgets/forms/core.py,
line 129, in validate
value = self.validator.to_python(value, state)
File
/usr/lib/python2.4/site-packages/FormEncode-0.9-py2.4.egg/formencode/api.py,
line 380, in to_python
value = tp(value, state)
File
/usr/lib/python2.4/site-packages/FormEncode-0.9-py2.4.egg/formencode/schema.py,
line 168, in _to_python
message = validator.message('missing', state)
TypeError: unbound method message() must be called with DefaultValidator
instance as first argument (got str instance instead)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
TurboGears Trunk group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---
[tg-trunk] Re: culprit is FormEncode=0.9
On Wed, 2008-16-01 at 22:32 -0800, iain duncan wrote: Hi all, I just upgraded by packages for the security fix, and now a functioning piece of TG + ToscaWidgets doesn't work anymore. It appears only to be happening with input widgets, my list and view widget are still fine. Ok, the culprit is FormEncode 0.9, which is the one we get now from easy_install FormEncode. Or at least reverting to 0.7x gets me running again, I dunno which package is Right. I also have no idea what to do with that information. ;-) Ian? Alberto? Thanks! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: TG2 status
On Sun, 2008-13-01 at 22:10 -0800, percious wrote: I say bring on 2.5 and let's not look back. Others may share my sentiment. hmm, I disagree here. Ditching 2.3, sure, but requiring 2.5 is not going to do our public relations any help. There are way too many linux hosting options for which upgrading to 2.5 is still a pain. my two cents Iain -chris ehem... http://code.google.com/p/dbsprockets/wiki/Primitives I just added a makeTable primitives. cheers. On Jan 13, 8:52 pm, Mark Ramm [EMAIL PROTECTED] wrote: The current version of the TG2 trunk is not Python 2.4 friendly due to the fact that Python 2.4 can't use new style classes as exceptions. And since we finally made everything work with webob (Hooray!!!) I discoverd this evening that webob's exceptions are all newstyle classes. :( But feel free to use 2.5, as it works like a champ there. I'll figure out what to do about all that tomorrow. I think the current TG2 code can be adapted to webob's 2.4 compatable exceptions, but i'm not too keen on exposing that API to TG2 users. In other news, DBSprockets has grown some super easy to use primitives, You can now generate forms and tables for you automatically from SQLAlchemy model objects. I'm loving it! And of course, Florent managed to put out a new TG1 release today, which I'll be using at work tomorrow. Thanks Florent! --Mark --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] 1.04 file upload encode problem, did it get resolved?
I've discovered that the problem I'm having with my toscawidget file upload field is this one: http://groups.google.com/group/turbogears/browse_thread/thread/fa9209cd044bc454 But the latest 1.04 in the cheeseshop does not seem to fix it. Did this get resolved? If I need this working pronto, should I revert to tg1.03? Thanks iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: 1.04 file upload issue, what happened? Urgent.
On Wed, 2008-09-01 at 20:26 -0800, iain duncan wrote: I've discovered that the problem I'm having with my toscawidget file upload field is this one: http://groups.google.com/group/turbogears/browse_thread/thread/fa9209cd044bc454 But the latest 1.04 in the cheeseshop does not seem to fix it. Did this get resolved? If I need this working pronto, should I revert to tg1.03? Responding to myself here, the latest beta version from the tgsetup-beta script or the cheeseshop is 1.04b3. In the thread above, a 1.04b4 was supposed to be coming to fix this issue. The problem was reported as known, breaking many apps, and ( apparently ) patched, on Dec 13, almost a month ago. But that is not what we are getting installing TG. IMHO, this is bad release management. There is no way we are going to impress anyone having the default install for TG be broken like this. If it doesn't work, and we know it, then please please, don't make an easy_install TurboGears or tg-setup.py install a broken beta! This is crazy. The default install should be tg1.03 until we know 1.04 is fine, and if we find out we need to revert, so be it. Sorry to rant, but these kind of issues do sooo much public image damage, I really think they need a lot more attention. This is the kind of area in which Django and Rails walk all over us. :/ Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: 1.04 file upload encode problem, did it get resolved?
On Thu, 2008-10-01 at 08:45 +0100, Florent Aide wrote: On Jan 10, 2008 5:26 AM, iain duncan [EMAIL PROTECTED] wrote: I've discovered that the problem I'm having with my toscawidget file upload field is this one: http://groups.google.com/group/turbogears/browse_thread/thread/fa9209cd044bc454 But the latest 1.04 in the cheeseshop does not seem to fix it. Did this get resolved? If I need this working pronto, should I revert to tg1.03? Should be fixed in SVN (head of 1.0 branch) It is, I found that out. And i hope you don't think I meant my comments personally. But I still maintain that is is a very bad situation that someone new comes to turbogears, uses easy_install TurboGears ( my default action for trying out any python library ) and gets a broken beta install that has been that way for month. If I were a new user, the experience would be a real turn off, know what I mean? I really appreciate all the work you have done, but that situation looks really bad to a new TG user. I've taught two new users to TG now, and the common theme is that it was way too hard to get it going. I think one should have to go out of one's way to install potentially broken versions. If we have a critical bug in a release, it should stay as a tag in svn only and not be something that someone could accidentally install via cheeshop. Sure that's just my opinion, but I do honestly think that this is an area where TG has consistently shot itself in the foot when it comes to marketing and public relations. my two cents iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: 1.04 file upload issue, what happened? Urgent.
On Thu, 2008-10-01 at 08:50 +0100, Florent Aide wrote: On Jan 10, 2008 5:44 AM, iain duncan [EMAIL PROTECTED] wrote: IMHO, this is bad release management. There is no way we are going to impress anyone having the default install for TG be broken like this. If it doesn't work, and we know it, then please please, don't make an easy_install TurboGears Yep. This is right. I am struggling with my time (or lack of...) to get to be able to work on tg ATM. But if you know a way we could have easy_install _not_ pick beta releases but only stable ones I would be grateful. As for the next release we are trying to sync up something with Chris Arndt to make this happen this week. Sorry for the inconvenience. Well, what if we keep beta releases out of the cheeseshop altogether and put clear instructions up on checking them out from svn? If it were me, I'd make beta candidates be tags, because if I go to a new project, and I check out a release candidate tag from svn, I *know* that it might not work right. But if I install something automagically, I get really annoyed if it isn't release quality because I don't really know what the heck that automated release is putting where. Thoughts? Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: Redirect, no dice
On Fri, 2008-04-01 at 23:43 -0500, Mark Ramm wrote: I did a fresh from scratch install according to the install instructions, so it has your altered middleware file in there. This line, right? # Stack httpexceptions middleware so redirect, abort, etc.. work # XXX: Why doesn't Pylons stack this internally? app = httpexceptions.make_middleware(app) Is this still not working? If so could you create a trac ticket for it, I think this needs to be working before next week's tg2 sprint and I'll do whatever I can to help make that happen. Hey Mark, thanks for following up. I have not had time to check on it or do any more testing of tg2 because of a tragic death of a friend over the holidays. I'm behind in the client work now and will get back to testing when I can, but I don't think it will be for a week or so. Thanks Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: [WARN] Possible breaking changes [WAS] Re: TG2, session vars not working out of the box
On Thu, 2007-27-12 at 10:38 -1000, Jonathan LaCour wrote:
Ian Bicking wrote:
Yeah, writing middleware with WebOb is much simpler in terms of code
flow. Ben redid paste.errordocument that way and was happy with it
(I'm not sure where the code landed, though). I haven't used AuthKit
myself, and don't have a particularly strong opinion. Except that
identifying a user has a pretty clear scope, but permissions are a bit
harder.
I can imagine loading the user data into, say,
environ['webauth.user_info'] (a dictionary, with at least a few
defined keys), and then permission checks are entirely separate code
that raises HTTPForbidden (or HTTPAuthenticationRequired), maybe based
on environ['webauth.user_info']['groups'], or... well, whatever.
Writing permission-checking code should be very easy.
FWIW, I'd be happy to polish up my code that I am using in my own TG 2
project, and contribute it as a starting point. It provides two things:
1. A simple WSGI middleware for authentication, which depends on beaker,
and places a validation that the user is authenticated into the
session. Right now, its directly tied to my SQLAlchemy/Elixir
model,
but it could easily be made more pluggable.
2. A base object-dispatching controller class called `SecuredController`
that provides a class method called `validate_permissions` that you
can override which returns `True` if the user has permissions to
view
this part of the subtree, and `False` if they do not.
Its not much, but thats what I like about it. Keep it simple, and put
the hooks in as code.
You're using SA0.4 right? ( elixir based I assume ... )
What about using SA;s Association Proxy on the identity handling object
to add permissions in a dead simple to use manner but clear manner, ie
something vaugely like:
if Identity.Role.get('admin') in Identity.user.groups:
I've found the syntax for association proxy to be really elegant for
that kind of stuff. It could make for very readable and traceable
following of the code, which I think is the biggest problem people have
with identity ( too much magic I mean ). I'd be interested in mucking
about with such a thing. Especially as I need to come up with a good
identity solution in the next month for a couple of projects ...
Could you post your code up somewhere Jonathan?
Thanks!
Iain
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
TurboGears Trunk group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---
[tg-trunk] Re: [WARN] Possible breaking changes [WAS] Re: TG2, session vars not working out of the box
On Thu, 2007-27-12 at 17:36 -1000, Jonathan LaCour wrote:
iain duncan wrote:
You're using SA0.4 right? ( elixir based I assume ... )
Yep, right on both counts.
What about using SA;s Association Proxy on the identity handling
object to add permissions in a dead simple to use manner but clear
manner, ie something vaugely like:
if Identity.Role.get('admin') in Identity.user.groups:
Actually, I think we should keep any sort of model-related
code or expectations out of the authentication/authorization
framework entirely. In my mind, this is one of the worst things
about identity in TurboGears 1.0, is that it makes all sorts of
assumptions about your model objects, and their associated API.
I'd prefer it if the authentication mechanism was a user-supplied
callable, which would allow the user to perform their authentication
in any way that they like.
I totally agree with that, I was meaning in the next layer down, as in
what one might do to tweak identity. But I guess I didn't make that
clear in the slightest. ;-)
To keep the Hit-The-Ground-Running (HTGR) experience as positive
as possible, it might be wise to include a simple authentication
function in the generated code within the template. It could
include a simple `User` model, including encryption, in either
SQLAlchemy or Elixir depending on the template, and a super-simple
callable that performs authentication using the generated model.
People who wanted to swap it out for something different, could very
easily do so, without worrying about digging into the framework, or
working around it. This is a huge positive, in my opinion.
Could you post your code up somewhere Jonathan?
Sure. It currently has some very application-specific code within
it, but it would be trivial for me to perform a little refactoring
to make it more general purpose. It might be good enough as an
identity replacement once I make the changes.
I am currently on vacation, so will be spending lots of time on the
beach, but I might find some time to do this before I get back ;)
I'll let you (and the rest of the list) know as soon as I get this
done, and post it somewhere for people to review.
Thanks, that sounds good!
Iain
( not-on-beach, not-in-snow, just gross December Vancouver rain. )
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
TurboGears Trunk group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---
[tg-trunk] Re: [WARN] Possible breaking changes [WAS] Re: TG2, session vars not working out of the box
What I really want (and the way I usually structure authorization for projects) is to pretty much only use the has permission condition, and then assign permissions to users/groups as needed. This keeps me from having to touch my source code every time I decide to add a new group or user type. It looks like this would be (barely) possible with AuthKit, but it would hackish and ugly. Also, the AuthKit docs are a mess (at least last week, haven't checked today). The original docs have disappeared and the book chapters are unfinished. So the dilemma...do we: 1) use AuthKit (wrap it or whatever), even though it has problems 2) write some kind of really extensive wrapper around AuthKit, that makes it look completely different 3) create something from scratch Ben mentioned some interest in 3, especially since WebOb makes middleware much easier to implement. Having mucked around with Webob a wee bit, it does seem like it would be ideal for making an identity middleware layer. ( Is that what Ben meant? ) I'm sorry to hear that Authkit isn't working out though. Ian, do you have any ideas on what you or Ben or thinking about for identity with Webob? Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: [WARN] Possible breaking changes [WAS] Re: TG2, session vars not working out of the box
I am glad someone is going to work on this, but I have a few requests,
since I use the `new_validate` decorator that we developed for
TurboGears 2.0 right now. It'd be nice if I can still have the
following features:
1. @validate(validators={...}) should still be a valid syntax, as its
a common idiom in TurboGears.
2. After validation, errors are placed onto
`tmpl_context.form_errors`
for convenience. This is a pattern that I use often, and have
found it to be very convenient. It would be great if it didn't go
away, or if there was an alternate way for me to get at the errors
without having to set up an error handler.
Agreed on 2. I think it would be great also to have a validate
*function* for calling within a method should we not want to use a
decorator. Something that did something along these lines:
tg_errors, values = validate_widget( widget, **kwargs )
Where the returned widget is the same widget repopulated with errors if
need be.
Thoughts? Total stab in the dark here. ;-)
Iain
Other than that, I am excited to see the direction you end up going!
identity
Well this is more of an announcement than a breaking change. If I
have some spare time I'd also like to take a go at implementing a
compatibility layer of the identity.require() decorator, or at least a
beginning-of-it, on top of AuthKit.
IMO, AuthKit is not something to build on top of. It hardly ever works
for me, is overcomplicated, and represents the weakest aspect of Pylons.
In fact I believe that all references to AuthKit have been removed from
the Pylons front page for these very reasons.
I'd encourage you to consider just making a new, simple piece of
middleware instead of getting mired in AuthKit's complexity. I am
currently using a very simple piece of middleware for authentication,
and have also implemented a `SecuredController` base class that will
lock down a part of your object dispatching hierarchy based upon a
customizable `validate_permissions` method. I am happy to share any
code if you want to take a look. The entire code base for both of
these tools is about 150 lines of code, making it extremely simple to
understand, debug, and maintain.
Also, its my opinion that identity was the weakest part of TurboGears
1.0, simply because it tried to do too much. I honestly think we'd be
better off shipping something simple, that was under 200 lines of total
code. This is just my opinion, and I'll be likely to continue using my
middleware unless the new `identity` is a heck of a lot simpler than
TG1's and isn't based upon AuthKit.
Certainly identity is an important issue. I would like it if whatever we
come up with allows the same easy protecting of resources as the old
one. ( ie SecureResource, identity_in, etc )
Iain
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
TurboGears Trunk group.
To post to this group, send email to turbogears-trunk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk?hl=en
-~--~~~~--~~--~--~---
