[tg-trunk] Re: Opinions requested re css framework and IE6
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. -- Lee McFadden blog: http://www.splee.co.uk rejaw: http://rejaw.com/splee twitter: http://twitter.com/splee --~--~-~--~~~---~--~~ 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] Re: Buffet and XHTML woes
Christoph Zwerschke schrieb: Christopher Arndt schrieb: - Should the Genshi Buffet plugin determine the doctype from the template format? Should this be reported as a bug to the Genshi project? I think Genshi should never send a doctype that is incompatible with the format (doctype=HTML and format=XHTML or vice versa), that should really be fixed in Genshi. But this will not solve the problem completely, because you may want to use compatible, but nevertheless different doctype variants for your pages. Yes, I forgot to mention that. You might want to choose between strict and transitional, for example. Btw, this is not a problem when you're using Kid, since Kid automatically chooses the right doctype. Also, if you want a different doctype, Kid provides subvariants of format (e.g. html-quirks instead of html) or custom serializer instances that can have any doctype in the format parameter, so this also works just fine with Kid. Yeah, thats why the problem only arises now when we are trying to get Genshi support properly done for all corner cases. - Is there any way to pass additional options to a Buffet engine after it has been instantiated, or do we need to change the Buffet API to allow this? As far as I can see, there are no provisions for passing additional parameters at render time in Buffet, and passing such parameters would break existing implementations. I.e. we would need to make adaptions to Genshi, TurboKid, TurboCheetah, TurboJson, etc. Is anybody using the Buffet API except TurboGears 1.x nowadays anyway? Except for Genshi, all of the above mentioned Buffet plugins are under our control, so we could change them easily. We can also make our own Genshi Buffet plugin, if we need to. Chris --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [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
Well, there are lots of tickets, including some documentation clean up tickets which need some love: http://trac.turbogears.org/query?status=newstatus=assignedstatus=reopenedgroup=milestonemilestone=2.0milestone=2.0-preview-1milestone=2.0-preview-2milestone=1.9.7a4milestone=1.9.7b1order=priority Of for those who have linebreak issues here's the tinyurl: http://tinyurl.com/3zvgol Also, there's a ModWSGI tg.repoze.who issue that was raised on the mailing list which needs a ticket, and investigation. A few small bugs that just need triaging are: http://trac.turbogears.org/ticket/1989 http://trac.turbogears.org/ticket/1921 http://trac.turbogears.org/ticket/1915 The most critical tickets are the SecureResource bug: http://trac.turbogears.org/ticket/1884 And the tg.ext.repoze.who namespace move. But really, anything that helps close any of the tickets or improve the docs would be much appreciated. :) On Mon, Sep 22, 2008 at 1:01 AM, Ademan [EMAIL PROTECTED] 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. On Sep 21, 7:40 pm, Mark Ramm [EMAIL PROTECTED] wrote: I have been out of touch most of last week, but I agree that having some better state-of-the-union docs would be good. I also agree that Authorization needs some documentation love, and I'll try to get started on both of those things this week. But I also really want to get another beta out the door this week, so any help from the TG2 army would be much appreciated :) --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] Re: Buffet and XHTML woes
TG2 is still using buffet at the moment, but will be moving away from it between 1.9.7 and 2.0. On Mon, Sep 22, 2008 at 2:42 PM, Christopher Arndt [EMAIL PROTECTED] wrote: Christoph Zwerschke schrieb: Christopher Arndt schrieb: - Should the Genshi Buffet plugin determine the doctype from the template format? Should this be reported as a bug to the Genshi project? I think Genshi should never send a doctype that is incompatible with the format (doctype=HTML and format=XHTML or vice versa), that should really be fixed in Genshi. But this will not solve the problem completely, because you may want to use compatible, but nevertheless different doctype variants for your pages. Yes, I forgot to mention that. You might want to choose between strict and transitional, for example. Btw, this is not a problem when you're using Kid, since Kid automatically chooses the right doctype. Also, if you want a different doctype, Kid provides subvariants of format (e.g. html-quirks instead of html) or custom serializer instances that can have any doctype in the format parameter, so this also works just fine with Kid. Yeah, thats why the problem only arises now when we are trying to get Genshi support properly done for all corner cases. - Is there any way to pass additional options to a Buffet engine after it has been instantiated, or do we need to change the Buffet API to allow this? As far as I can see, there are no provisions for passing additional parameters at render time in Buffet, and passing such parameters would break existing implementations. I.e. we would need to make adaptions to Genshi, TurboKid, TurboCheetah, TurboJson, etc. Is anybody using the Buffet API except TurboGears 1.x nowadays anyway? Except for Genshi, all of the above mentioned Buffet plugins are under our control, so we could change them easily. We can also make our own Genshi Buffet plugin, if we need to. Chris -- Mark Ramm-Christensen email: mark at compoundthinking dot com blog: www.compoundthinking.com/blog --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~--~~~~--~~--~--~---
[tg-trunk] Re: Buffet and XHTML woes
Christopher Arndt schrieb: Is anybody using the Buffet API except TurboGears 1.x nowadays anyway? Except for Genshi, all of the above mentioned Buffet plugins are under our control, so we could change them easily. We can also make our own Genshi Buffet plugin, if we need to. As far as I understand, TG is actually defining the Buffet API (http://docs.turbogears.org/1.0/TemplatePlugins is the reference), so we can change the API if we really want. There are a couple of fringe Buffet implementations (e.g. BuffetMyghty) that are not under our control. But as you already mentioned, TG is using adapt_call when calling engine.render anyway, so passing additional options does not harm if the interface does not support them. Btw, it doesn't seem like the mapping parameter to view.render hasn't been used anywhere, so I suggest renaming it to options. -- Christoph --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [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, Sep 22, 2008 at 8:15 PM, iain duncan [EMAIL PROTECTED] wrote: 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. Excellent news! (for the html layout, not you missing time) Looking forward to put my hands on your code to see how we make it fit in the next beta! Florent. --~--~-~--~~~---~--~~ 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 23/09/2008, at 10:06 AM, 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. I don't agree with this decision. I never use tgsetup.py (I forgot it existed TBH) and the reason is that I distribute and deploy my TG projects as eggs. The guys deploying the apps are instructed that all they need to do is easy_install the application eggs and the dependency requirements will install TurboGears/etc if necessary. My assumption is that setuptools will find the latest stable version of 1.0.x from pypi, but as you say this is incorrect. This should be made clear, as I (and others in the same position) will need to make sure we define the TG dependencies as turbogears 1.1a to ensure 1.0.x is used, until such a time as we've been able to test and verify 1.1 compatibility. I don't really understand why tgsetup.py should behave differently than easy_install turbogears. I thought tgsetup.py was simply a helper script for users unfamiliar with setuptools/etc to make their life easier. I would expect easy_install to be the standard installation method, given that TG deployment is based around setuptools/eggs. Cheers, Chris Miles --~--~-~--~~~---~--~~ 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: Easy install is installing a beta again!
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 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
