[tg-trunk] default i18n setup

2008-01-13 Thread Max Ischenko
I went ahead and added default i18n (Babel) setup. So the quickstarted project will have pot/po files and the TurbogearsController contains logic to setup request language based on browser's preferences. http://docs.turbogears.org/2.0/RoughDocs/I18N -- Max http://maxischenko.in.ua // http://www.

[tg-trunk] modular validation

2008-01-12 Thread Max Ischenko
Hello, As Alberto said and as Mark and I discussed yesterday, current validation code is messy. I agree with Alberto that a plain decorator may be a better solution. Actually, I want the validation approach to be pluggable. Alberto/Mark wants wants FE, I want newforms. I think it's worth to try t

[tg-trunk] Re: The TurboGears 2 sprint weekend is here!

2008-01-12 Thread Max Ischenko
I'm here! ;) The sprint page somehow doesn't contain a pointer to where TG2 is and how to get started on coding. I'll try to update it if I find the info. Max. On Jan 12, 2008 7:07 AM, Mark Ramm <[EMAIL PROTECTED]> wrote: > > I'll be at the conference room in Primo Coffee in about 8 hours, but

[tg-trunk] Re: sprint planning

2008-01-11 Thread Max Ischenko
Hello, On Jan 5, 2008 4:47 AM, Mark Ramm <[EMAIL PROTECTED]> wrote: > > I'm planning to try to put a bunch of tasks into Trac+the > SprintOrganization wiki this weekend, so that we have a good list of > thngs to work on next week. > > I'd like to have a few more things finalized this weekend in t

[tg-trunk] Re: [WARN] Possible breaking changes [WAS] Re: TG2, session vars not working out of the box

2007-12-29 Thread Max Ischenko
On 12/28/07, Alberto Valverde <[EMAIL PROTECTED]> wrote: > > > I'll describe a way (among many) in how the good part of AuthKit can be > used along with our own port of Identity or whatever in an attempt to > convince you that it really rocks ;) > > 1) Stack and configure AuthKit's authenticate mid

[tg-trunk] Re: Database connectivity in tg2

2007-07-11 Thread Max Ischenko
On 7/11/07, Mark Ramm <[EMAIL PROTECTED]> wrote: > > > Ben recomends that we not depend on anything in pylons.database, and > use SAContext instead. > > If that's going to happen we'll probably need a third party package > SOContect which provides the connection code we need to support SO > users.

[tg-trunk] Re: TG2 progress and bugs

2007-07-04 Thread Max Ischenko
On 7/2/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > And here are some bugs I've investigated: > > 1. unknown links didn't dispatch to 'default' method > 2. pylons 'c', 'g' params need to be returned implicitly (return > dict(c=c, g=g)) > 3. need implement tg_flash FWIW, here is the implem

[tg-trunk] Re: Trunk status

2007-05-10 Thread Max Ischenko
On 5/10/07, Ori Avtalion <[EMAIL PROTECTED]> wrote: > > > > > The cp3 transition in Trunk needs some finalization (the config > system > > needs help) and we do need to get that done so that people can hack > on > > the trunk more easily. > > > > I just finished reading "Cherrypy Essent

[tg-trunk] Re: Trunk status

2007-05-09 Thread Max Ischenko
Hi, On 5/10/07, Mark Ramm <[EMAIL PROTECTED]> wrote: > > > > I think the trunk should be stable enough to run and not have > > show-stopper bugs. How else can developers test their changes before > > committing? > > The cp3 transition in Trunk needs some finalization (the config system > needs hel

[tg-trunk] Re: 1.0.1 users, please try out the 1.0 branch from SVN

2007-04-13 Thread Max Ischenko
Hello, I have had a fancy error (traceback below). I have figured out that latest formencode calls i18n gettext function which tries to look up a locale key on session. It fails because testutil.DummyRequest doesn't support a session. I have implemented a workaround in [2865] by adding a DummySes

[tg-trunk] Re: ToscaWidgets: options validatation

2007-04-05 Thread Max Ischenko
Alberto, On 4/5/07, Alberto Valverde <[EMAIL PROTECTED]> wrote: > > > > def test_options(): > > w = MultipleSelectField(options="Group1 Group2 Group3".split()) > > eq_(['Group3', 'Group1'], w.validate(['Group3', 'Group1'])) > > print w.validate(['GroupX']) > > assert 0, "formencode

[tg-trunk] ToscaWidgets: options validatation

2007-04-05 Thread Max Ischenko
Hello, I wonder why this test fails: def test_options(): w = MultipleSelectField(options="Group1 Group2 Group3".split()) eq_(['Group3', 'Group1'], w.validate(['Group3', 'Group1'])) print w.validate(['GroupX']) assert 0, "formencode.Invalid not raised" I was assuming that the sele

[tg-trunk] Re: TG 1.1

2007-03-29 Thread Max Ischenko
Alberto, On 3/29/07, Alberto Valverde <[EMAIL PROTECTED]> wrote: > > > I have re-enabled config.update() to use the module-global config > > var and re-wrote testutil.py to stub call/create_request so that > > these don't use cherrypy. As a result nosetests gives: > > Hmm, updating the global conf

[tg-trunk] TG 1.1

2007-03-29 Thread Max Ischenko
Hi, I have re-enabled config.update() to use the module-global config var and re-wrote testutil.py to stub call/create_request so that these don't use cherrypy. As a result nosetests gives: Ran 157 tests in 3.259s FAILED (failures=4, errors=105) I still don't understand how config.py should be

[tg-trunk] Re: CP3 for 1.1

2007-03-28 Thread Max Ischenko
Hi folks, I have looked Alberto's Turbogears2CP code as well as misc references from #1181 but I can't wrap my mind how to do all this. I am either too dumb or it's too big of a change to fit at once in my small head. :-/ I am going to "forget" about all the WSGI/paste stuff for a while and try s

[tg-trunk] Re: Next head up?

2007-03-27 Thread Max Ischenko
Hi Alberto, On 3/27/07, Alberto Valverde <[EMAIL PROTECTED]> wrote: > > Hi Max, > Welcome back to the trunk list :) > Thanks :) > The main task needing work is [...] > Thanks for the excellent write-up, I posted it as a comment to 1181 for a reference. Max. --~--~-~--~~-

[tg-trunk] Re: Next head up?

2007-03-27 Thread Max Ischenko
On 3/27/07, Alberto Valverde <[EMAIL PROTECTED]> wrote: > > > Those at the 1.0.2 milestone. However, they're not strictly needed > > to get 1.1 out (although they'll need to be merged when done) so if > > you just want to help for 1.1 don't bother about them. > > Of course, if you *do* want to help

[tg-trunk] Re: SQLObject and Kid for 1.1

2007-03-27 Thread Max Ischenko
On 3/27/07, Jorge Godoy <[EMAIL PROTECTED]> wrote: > > > "Max Ischenko" <[EMAIL PROTECTED]> writes: > > > Will TG 1.1 support the SQLObject and the Kid libararies? I am asking > > because there are quite a few tickets related to those on 1.1milestone

[tg-trunk] SQLObject and Kid for 1.1

2007-03-26 Thread Max Ischenko
Hello, Will TG 1.1 support the SQLObject and the Kid libararies? I am asking because there are quite a few tickets related to those on 1.1 milestone... will those be fixed before 1.1 release? Before 1.1alpha? 1.1beta? PS: Sorry for a lot of email I sent, just trying to get back into the flow. Ma

[tg-trunk] turbogears.extensions that don't work with TG 1.1 (CP3)

2007-03-26 Thread Max Ischenko
Hello, First thing I noticed when tried CherryPy 3 branch is that some extensions don't work. In particular, TurboZSI which depends on cherrypy's filters API. As a quick fix, I added code in r2803 to ignore such ImportErrors. The larger question is: while moving to CherryPy 3, is TurboGears res

[tg-trunk] Re: Next head up?

2007-03-26 Thread Max Ischenko
On 3/27/07, Max Ischenko <[EMAIL PROTECTED]> wrote: > > P.S.: I am in process of starting another TurboGears project and I want it > to be on 1.0.2 with SA, Genshi and CP3, just like the rest of us. ;) Sorry, I meant 1.1 I think. IIUC, cp3 will become 1.

[tg-trunk] Re: Next head up?

2007-03-26 Thread Max Ischenko
Alberto, On 3/26/07, Alberto Valverde <[EMAIL PROTECTED]> wrote: > > > I think we all agree on this. The port to CherryPy 3 is almost done > in the cp3 branch, just needs the tests adapted as the current ones > are too closely tied with CP2's internals (I'll give a shot at this > in a few days) an

[tg-trunk] Re: Pylons+TurboGears=????

2007-03-05 Thread Max Ischenko
Mark, On 3/5/07, Mark Ramm <[EMAIL PROTECTED]> wrote: > > > Reciently there have been some rumors about a TurboGears/Pylons > "merge." Perhaps sparked by a number of intense discussions on the > subject of working together more that I had with Ben Bangert at PyCon > last week. > > I think we all

[tg-trunk] Re: TG 2.0 update

2007-01-26 Thread Max Ischenko
Hi, On 1/26/07, Alberto Valverde <[EMAIL PROTECTED]> wrote: > > Ok, open it when you want... It's true that Tosca and TG widgets docs > are pretty scarce so improving them will be good. > ... Where *are* they, for a start? ;) toscawidgets.org only shows integration examples and not even a hint

[tg-trunk] Re: ticket #1166 for TG 1.0b?

2006-12-22 Thread Max Ischenko
Hi, On 12/22/06, Jorge Vargas <[EMAIL PROTECTED]> wrote: > +1 from me. I'm about to commit #930 which will complement each > other... :) > yes indeed anything that makes tests more robust should go in Applied in 2258. Do I need to update any docs or ChangeLog? Basically, from the user API

[tg-trunk] ticket #1166 for TG 1.0b?

2006-12-22 Thread Max Ischenko
Hello, Can I apply patch from ticket #1166 to Turbogears stable branch so that it will appear in next 1.0 release? I have already applied it to tg trunk. Max. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Turbo

[tg-trunk] Re: ToscaWidgets to bundle jQuery

2006-12-10 Thread Max Ischenko
On 12/10/06, Ian Charnas <[EMAIL PROTECTED]> wrote: > > Is the accordion in jquery any better than > the accordion in mootools? Is scriptaculous' lightbox any better than > jquery's graybox? Because we can't provide them all so that people can > use whichever they want for their application, I th

[tg-trunk] Re: TurboGears 2.0

2006-12-01 Thread Max Ischenko
On 11/30/06, Kevin Dangoor <[EMAIL PROTECTED]> wrote: > > The new item for the list is: > > 6) Break out more of our code > > #6 is very important. After 0.8, TurboGears grew quite a bit of code and > features for 0.9. It made sense at the time to put them all in the > turbogears package, because t

[tg-trunk] Re: Support testing the code that uses identity

2006-11-02 Thread Max Ischenko
Hi Nadav,Your patch (and idea) is interesting but it addresses the problem on a different, higher level.The goal of my patch is to be able to test code that refers to identity.current variable. As it is now, the code under test that tries to access identity.current fails with IdentityNotEnabled ex

[tg-trunk] Re: Support testing the code that uses identity

2006-11-01 Thread Max Ischenko
Kevin,On 11/1/06, Kevin Dangoor <[EMAIL PROTECTED]> wrote: I have submitted a patch which should make it easier to test the code that uses identity, please see http://trac.turbogears.org/turbogears/ticket/1166 . If no one objects, I'll commit within a few days. Btw, if it is accepted, should I com

[tg-trunk] Support testing the code that uses identity

2006-10-31 Thread Max Ischenko
Hi,I have submitted a patch which should make it easier to test the code that uses identity, please see http://trac.turbogears.org/turbogears/ticket/1166 . If no one objects, I'll commit within a few days. Btw, if it is accepted, should I commit it to 1.1 branch only or to both 1.1 and 1.0 branches

[tg-trunk] Re: Widget API NG proposal

2006-10-25 Thread Max Ischenko
Alberto,Here is a comment from PJE regarding TGWidget announcement I posted on my blog:"""Hm. This isn't compatible with having more than one framework in-process. So, if for example you have a CherryPy application embedded inside of Zope, let's say, then only one of those frameworks can have a Hos

[tg-trunk] Re: Widget API NG proposal

2006-10-23 Thread Max Ischenko
Hi Alberto,On 10/23/06, Alberto <[EMAIL PROTECTED]> wrote: First of all I'd like to mention that I've just comitted my work tohttp://www.turbogears/svn/turbogears/projects/TGWidgets. Somepre-eliminary pudge.generated docs are at http://tgwidgets.toscat.net/.There's a sample TG 1.0b1 project which

[tg-trunk] Re: how about adding view.py to quickstart projects?

2006-10-13 Thread Max Ischenko
+0 on this. There are lot of ways to structure the project source code and there are alot of factors that come into play. I am not very happy with the default TG layout but I don't think it's a problem - any non-trivial project will twisted it to suit there needs. That's why it's hard for me to jud

[tg-trunk] Re: ticket pruning

2006-10-12 Thread Max Ischenko
On 10/12/06, Jorge Vargas <[EMAIL PROTECTED]> wrote: svn blame ?or check the changelog in trac :)btw, am I supposed to update changelog? I have checked turbogears-1.0/CHANGELOG.txt but it contains nothing after 1.0b1 release. Therefore I didn't record my changes anywhere. --~--~-~--~---

[tg-trunk] Re: ticket pruning

2006-10-12 Thread Max Ischenko
On 10/12/06, Jorge Vargas <[EMAIL PROTECTED]> wrote: just one commentsaying the revision on which they where commited is better then "It isalready applied in SVN after 1.0b1."Okay, but in this particular case I have no idea who applied the change. I just checked trunk/1.0 and saw it contains the c

[tg-trunk] ticket pruning

2006-10-11 Thread Max Ischenko
Hi,I have purged some of the tickets with unassigned milestones on Trac. Hopefully I didn't go overboard with it.Max. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "TurboGears Trunk" group. To post to this group, se

[tg-trunk] turbogears.widgets egg?

2006-10-11 Thread Max Ischenko
Hi,I noticed Kevin created TGWidgets project in Subversion. Does this mean that turbogears.widgets will be extracted into a separate project (egg)? Or it's just for third-party widgets?IMO, widgets is one of the most innovative features of TurboGears and it would be great if other projects are able

[tg-trunk] Re: [patch] Wrap "nosetests" command to "tg-admin tests"

2006-09-22 Thread Max Ischenko
I am -0 on this becase, as Alberto pointed out, there is "setup.py test" command already.On 9/22/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:I opened a ticket on trac to ask is it good to have a  "tg-admin tests" command rather than "nosetests" command? (patch with it)http://trac.turbogears.or

[tg-trunk] Re: server.email_errors

2006-08-21 Thread Max Ischenko
> I noticed server.email_errors setting appears in dev.cfg template yet > searching source code > and site/google archives showed zero mentions of it. Nevermind this question, that was in old project of mine, not TG template. --~--~-~--~~~---~--~~ You received

[tg-trunk] server.email_errors

2006-08-21 Thread Max Ischenko
Hi, I noticed server.email_errors setting appears in dev.cfg template yet searching source code and site/google archives showed zero mentions of it. Is it a stub for future or there is external (WSGI?) component which automatically will make sense of this option? Max. --~--~-~--~---

[tg-trunk] Re: i18.run_template_filter doesnt work?

2006-08-21 Thread Max Ischenko
Hi, Works for me here on quickstarted project with TG 0.9a9. I can only suggest you try to quickstart a project and see if it works. If it does then examine differences between you app.cfg/dev.cfg and quickstarted ones. If it doesn't that means package problem with TG, Kid or else. Max. > I

[tg-trunk] Re: Rant agains SQLObject bugs, although I didn't close a lot ....

2006-08-07 Thread Max Ischenko
> > SQLObject is at rev 1800+ and we are at 1457 shouldn't we upgrade before we > > get into the 1.0 betas? > > Yes we should, The next version will have updated version of SO (im > running r1839 from bugfix here without problems). Note that easy_install "SQLObject==0.7.1dev_r1824" doesn't work

[tg-trunk] Re: New welcome page with css

2006-07-30 Thread Max Ischenko
> Thanks Mikkel Høgh and Kaan, you can checkout the new welcome page > candidate now in svn branch (svn>1695). Very nice, thanks! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "TurboGears Trunk" group. To post

[tg-trunk] Re: SelectionField.options called in ctor (backward-incompatible with 0.9a6)

2006-07-30 Thread Max Ischenko
Alberto, The thing is, in 0.9a6 if options parameter is callable AND validator is passed in everything worked fine. Now, in 0.9a8 it may give an error because options are actually called in ctor thanks to ParamDescriptor. I noticed you have just fixed it in 1692, thanks! And test_callable_opt

[tg-trunk] Re: SelectionField.options called in ctor (backward-incompatible with 0.9a6)

2006-07-29 Thread Max Ischenko
> On Jul 28, 2006, at 4:11 PM, Max Ischenko wrote: > > Looks like I stumbled upon another backward-incompatibility issue > > in 0.9a8: if options is callable it gets called at ctor time (it > > was not called before, unless no validator was also given). > > This is

[tg-trunk] SelectionField.options called in ctor (backward-incompatible with 0.9a6)

2006-07-28 Thread Max Ischenko
Hi folks, Looks like I stumbled upon another backward-incompatibility issue in 0.9a8: if options is callable it gets called at ctor time (it was not called before, unless no validator was also given). Please see test_callable_options_for_selection_field() in tests_forms.py. In my case, option

[tg-trunk] Re: Need a bit of help using fastdata as a plugin

2006-06-28 Thread Max Ischenko
> I'm trying to transition my project off of using fastdata, so I get get > a bit more flexibility in my forms. To do that, I need to run the > 'with-fastdata' version of my project so I can see how things look. I > haven't worked with fastdata since it became a plugin, and I'm having > trouble

[tg-trunk] Re: empty Toolbox?

2006-06-24 Thread Max Ischenko
; > > do you by any chance use setup.py develop and just svn up? if so try > rerun develop. The toolbox changed to entrypoints some revs ago so you > need to reinstall it for it to register those. > > On 6/24/06, Max Ischenko <[EMAIL PROTECTED]> wrote: > > > &g

[tg-trunk] empty Toolbox?

2006-06-24 Thread Max Ischenko
Hi, I'm using SVN and recently noticed that TG Toolbox displays empty page (header yet no content/links). Is it just me or Toolbox is broken? Max. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "TurboGears Trunk

[tg-trunk] RE: [Docudo] Re: add "file a ticket" link to Docudo instance at docs.turbogears.org?

2006-06-23 Thread Max Ischenko
> Docudo doesn't need "file a ticket" because it has comments on the > page. That's actually a more useful thing than "file a ticket" > because other people will see the comments inline. I see. Then how about adding a cookie so that visitor's name/email gets remembered and added automatically

[tg-trunk] add "file a ticket" link to Docudo instance at docs.turbogears.org?

2006-06-21 Thread Max Ischenko
Hi, I have been browsing docs.turbogears.org and noticed that nodes http://docs.turbogears.org/0.9/testing and http://docs.turbogears.org/0.9/deployment contains "Fail to extract the body content from the document. No Element Found: Line 1, Column 1" error message instead of content. I'd lik

[tg-trunk] Re: test failure

2006-06-20 Thread Max Ischenko
> > It looks like Max's change from a couple hours back might have had an > > unexpected side effect in the tests: Fixed. Now all tests passes except tests.test_catwalk.Browse. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the G

[tg-trunk] Re: test failure

2006-06-20 Thread Max Ischenko
Indeed. I'll fix that if you have not already. > -Original Message- > From: turbogears-trunk@googlegroups.com [mailto:[EMAIL PROTECTED] > On Behalf Of Kevin Dangoor > Sent: Tuesday, June 20, 2006 8:35 PM > To: turbogears-trunk@googlegroups.com > Subject: [tg-trunk] test failure > > > I

[tg-trunk] plans for 0.9a7 release?

2006-06-19 Thread Max Ischenko
Hi, Kevin, do you have any concrete plans regarding 0.9a7 release? Are there any chances to happen anytime soon? Max. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "TurboGears Trunk" group. To post to this grou

[tg-trunk] Re: simpler version of LocalizableJSLink

2006-06-19 Thread Max Ischenko
Roger, > Looking at the final code, I have just one comment: > > Should CalendarLangFileLinkDesc still exist ? After all, now it seems > to be very specific do CalendarWidgets... > > BUT, if it makes sense to preserve this WidgetDescription, its name > should be changed from "Localizable JS Lin

[tg-trunk] Re: simpler version of LocalizableJSLink

2006-06-14 Thread Max Ischenko
> Max, if you think the Calendar can and should use this version then go > ahead and do it, otherwise I think renaming your one to > LocalizableJSLink and the advanced one to CalendarLangFileLink makes a > lot of sense because ATM we have two things with almost the same name. > ;-) In Subversion

[tg-trunk] problem with dates <= 1900

2006-06-11 Thread Max Ischenko
Hi, I'm using DateTimePicker widget and it fails to work with dates <= 1900. Traceback: File "/home2/romanix/lib/python2.4/site-packages/TurboGears-0.9a6dev_r1341-py2 .4.egg/turbogears/widgets/base.py", line 235, in display params["value"] = to_unicode(self.adjust_value(value, **params)

[tg-trunk] Re: Choise of widget plugins repository

2006-06-11 Thread Max Ischenko
Hi,   I agree with Jorge. Full-blown project environment for a 50-200 lines of widget code is kind of overkill. We may want to copy wordpress/track-hacks model, when there is a single common environment with sliced for multiple projects.   From: turbogears-trunk@googlegroups.

[tg-trunk] Re: simpler version of LocalizableJSLink

2006-06-04 Thread Max Ischenko
> My situation: systems developed for Brazilian people must have dates > in dd/mm/ format... But there are many people (read *me*) who > likes to use SO and browsers with English language... that helps > finding solutions to errors that appear during development cycle > live... English is the

[tg-trunk] simpler version of LocalizableJSLink

2006-06-03 Thread Max Ischenko
Hello, I was trying to warp my head around LocalizableJSLink widget and instead come up with a much simpler implementation. May be it could be included into TG, renaming original LocalizableJSLink class into SophisticatedLocalizableJSLink or simply CalendarLangFileLink (I like the latter becau

[tg-trunk] Re: i18n.tests gives: IOError: [Errno 2] No translation file found for domain: 'messages'

2006-05-24 Thread Max Ischenko
Hi Roger, > Am I missing some update ? > I have already run "python setup.py develop", as usual That's my fault, forget to update path to locale directory. Fixed in SVN, r1510. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Go

[tg-trunk] non-ascii message catalog handling

2006-05-23 Thread Max Ischenko
Hi, I have made major overhaul of pygettext.py/catalog.py modules from turbogears.i18n package to make it work (better) with non-ascii characters. In particular, non-ascii msgids are fine now, in both escaped and un-escaped modes. I did test it with admi18n and tg-admin tool as well and thir

[tg-trunk] Re: non-ascii message catalog handling

2006-05-23 Thread Max Ischenko
> > I have made major overhaul of pygettext.py/catalog.py modules from > > turbogears.i18n > package to make it work (better) with non-ascii characters. In particular, > non-ascii msgids > are fine now, in both escaped and un-escaped modes. > > As long as the change is backwards compatible, the

[tg-trunk] Kid TypeError again (NoneType not callable)

2006-05-08 Thread Max Ischenko
I got this elusive error again. Hopefully the traceback and stack variables captured with fancy_traceback may help someone to figure out what's wrong. As usual, the problem disappears after server is restated. - traceback -- Module turbogears.view.base:131

[tg-trunk] Re: fastdata-incompatible change in widgets?

2006-05-05 Thread Max Ischenko
> I see, the problem is that the form is getting an SQLobject > instance instead of a dict as a value, when from_python is > executed on it it fails as it expects a dict. > > Since [1344] from_python is executed for conversion in > adjust_value for CompoundWidgets too, therefore this bug has

[tg-trunk] Re: fastdata-incompatible change in widgets?

2006-05-05 Thread Max Ischenko
> > > > One possible solution (or workaround) could be to so_to_dict SO > > instances in validators.Schema.from_python Though maybe a final > > solution would be to fix fastdata to send a "so_to_dicted" > SO to the > > form...Opinions? > > I vote for removing getattr use from retrieve_v

[tg-trunk] Re: fastdata-incompatible change in widgets?

2006-05-04 Thread Max Ischenko
> > Seem good, passing all tests and solving my problem... > I'm attaching a patch for it see if solves Max's other app too. Unfortunately that doesn't help either. My app is rather ... uh involved so it's not easy to extract a meaninful part of it. Basically, it goes like this: class MyDataCo

[tg-trunk] Re: fastdata-incompatible change in widgets?

2006-05-04 Thread Max Ischenko
Hi Alberto, > I'm experiencing this problem too ... seems that the Schema calls > from_python on every field and then adjust_value calls it again on > individual fields so vaue is double-from-pythonized... > > Can you try the attached patch see if it solves anything? It does in > my case (which

[tg-trunk] fastdata-incompatible change in widgets?

2006-05-04 Thread Max Ischenko
Hi, I get the following traceback with the latest 1.0 svn (rev. 1366): File "c:\python24\lib\site-packages\TGFastData-0.9a3-py2.4.egg\tgfastdata\datacontroller.py", line 61, in default return method(item, *vpath[1:], **params) File "", line 3, in edit ... File "C:\Python24\lib\site

[tg-trunk] Re: Do you remember how we solved this error? TypeError: argument x must be str not unicode

2006-05-03 Thread Max Ischenko
> > I can speculate that it works on other machines either because they do not > > have decoding_filter enabled or use different DB API driver. > > That's the same "everything" :-) This is a checkout from my own repository, > so all configurations are the same, so this is not in my code or > con

[tg-trunk] Re: Do you remember how we solved this error? TypeError: argument x must be str not unicode

2006-05-03 Thread Max Ischenko
Hi Jorge, You're passing unicode string to SQLObject which it (underlying db driver, to be precise) cannot handle. Here: user= user_class.by_user_name( user_name ) user_name must be encoded string here. I can speculate that it works on other machines either because they do not have decoding

[tg-trunk] Re: MultipleSelectField problem with latest svn

2006-05-01 Thread Max Ischenko
Michele, > PS > Is there a good reason you reverted patch #785 here: > http://trac.turbogears.org/turbogears/changeset/1340 > > when you already committed it to both branch in: > > http://trac.turbogears.org/turbogears/changeset/1242 > http://trac.turbogears.org/turbogears/changeset/1243 Oh, s

[tg-trunk] MultipleSelectField problem with latest svn

2006-05-01 Thread Max Ischenko
Hi, I have a TableForm widget which uses MultipleSelectField. After recent updates I discovered that it no longer displays currently selected options properly. It used to work OK so I’m not sure whether the error is in my code or there is (introduced) bug in widgets code. The problem, as I s

[tg-trunk] MultipleSelectField problem with latest svn

2006-05-01 Thread Max Ischenko
Hi, I have a TableForm widget which uses MultipleSelectField. After recent updates I discovered that it no longer displays currently selected options properly. It used to work OK so I’m not sure whether the error is in my code or there is (introduced) bug in widgets code. The problem, as I s

[tg-trunk] Re: new logging cfg

2006-05-01 Thread Max Ischenko
Yet another error. My dev.cfg contains: [logging] [[handlers]] [[[debug_out]]] class='FileHandler' level='DEBUG' args=('spaca-tg.log', 'at+') Results in: D:\Projects\Spaca>start-spaca.py Traceback (most recent call last): File "D:\Projects\Spaca\start-spaca.py", line 23, in ? modulenam

[tg-trunk] Re: new logging cfg

2006-05-01 Thread Max Ischenko
Kevin, > Note that this is specifically saying to use spaca.config.app. If you > change it to spaca.config, it will use the whole package. Oh, haven't noticed that. Thanks! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Goog

[tg-trunk] new logging cfg

2006-05-01 Thread Max Ischenko
I'm trying to update my project's configuration file to new logging configuration and I get this error: Traceback (most recent call last): File "D:\Projects\Spaca\start-spaca.py", line 21, in ? modulename="spaca.config.app") File "d:\projects\3rd-party\turbogears-1.0\turbogears\config.p

[tg-trunk] Re: Issues with kidutils.py:translate

2006-04-28 Thread Max Ischenko
> > Issue #1. DIV inside the BODY is not translated unless lang='' added to the > > BODY tag. > Shoudn't translate function be able to find div automatically? Attempt to put > > tag inside BODY had no effect. As it is, I have to add lang='' to the BODY > attribute which > basically forces _ent

[tg-trunk] Re: logical logging - at last!

2006-04-27 Thread Max Ischenko
> I just committed a big change to how logging is configured so that > everything is now piped through Python's logging module and is very > flexibly configurable via the config files. You can reroute access > logs with the "turbogears.access" logger. Great. > If you look at a brand new quicks

[tg-trunk] Re: TypeError: 'NoneType' object is not callable

2006-04-26 Thread Max Ischenko
> > [EMAIL PROTECTED]:~/Progetti/TurboGears/svn/1.0/turbogears$ nosetests > > -- > > Ran 203 tests in 17.479s Funny thing, but when I run nosetests from top-level 1.0 dir I had only 2 failures (for missed sqlalchemy/jsonify modu

[tg-trunk] TypeError: 'NoneType' object is not callable

2006-04-26 Thread Max Ischenko
Is it just me who gets this error when trying to run nosetests on trunk/1.0-branch? I got 31 errors trying to run nosetests on 1.0 branch. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "TurboGears Trunk" group.

[tg-trunk] Re: a5 tomorrow, hopefully

2006-04-26 Thread Max Ischenko
How about #785? I think this covers important bug unless I miss something. I can apply it if you OK the patch. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "TurboGears Trunk" group. To post to this group, send

[tg-trunk] Issues with kidutils.py:translate

2006-04-25 Thread Max Ischenko
Hi, IIUC, there are two approaches: use "i18n.runTemplateFilter" configuration setting to translate every bit of text or use kidutils.py:translate function to translate certain nodes only. I was experimenting with the latter and discovered some issues with it. Not sure if the problem in my mis

[tg-trunk] i18n issues

2006-04-21 Thread Max Ischenko
Hi, I'm trying to help Mark Ramm with i18n chapter for his book and would like to discuss some i18n issues. 1. I18N command dichotomy. In TurboGears we currently have two approaches to manage i18n data: first, more popular, is admi18n and second, which I contributed, via "tg-admin i18n" comm

[tg-trunk] more usable turbogears.view.render?

2006-04-18 Thread Max Ischenko
Hi, I'm adding _cp_on_error method to my Root controller and I'd like to display a custom error page to the user from it. Page is Kid template, as usual. So far I ended up with this code: data = dict(...) t = dict(data=data, form=feedback_form, tg_css=[], tg_js_

[tg-trunk] Re: DictObj, DictWrapper, Bunch

2006-04-18 Thread Max Ischenko
> Simon Belak wrote: > > My vote goes to Bunch as it is the only NIH. > +1 ;-) > PS > I think in the Bunch's ASPN Cookbook page there are more featured (only > some more lines) Bunch classes. Can we/I add a __repr__ method, e.g: def __repr__(self): return repr(self.__dict__) --~-

[tg-trunk] Re: Widgets: template_vars, retrieve_javascript/css and validate...

2006-04-16 Thread Max Ischenko
> > So really, you're just going to rename the template_vars variable > > because it's going to do exactly the same thing... > Yep in the end that's just what will happen. ;-) I skipped this whole thread but now want to add my 2 kopecs. > I think on Thursday I will do these thing: > > - temp

[tg-trunk] Re: Any fail-safe mechanism users?

2006-04-13 Thread Max Ischenko
> I am thinking of changing the fail-safe mechanism of error handling [1], > making it independent of the rest of the validation process, with > continuations as the new recommended pattern: > >def failsafe(controller, schema, tg_source, tg_errors, tg_exception, > *args, **kw) > return

[tg-trunk] calendar lang files

2006-04-13 Thread Max Ischenko
I was looking into recent patch to Polish calendar lang file to figure out if I can patch Russian calendar file, which didn't display correctly as well. As it turns out, adding "Calendar._FD = 1;" helped to solve the problem. I have no idea what that means but running a grep shows: > grep -l

[tg-trunk] Re: fastdata error

2006-04-12 Thread Max Ischenko
> On 4/5/06, Max Ischenko <[EMAIL PROTECTED]> wrote: > > The fastdata has been removed but my code depends on it and I got a weird > > error. Can > original fastdata author help? > > I'm the original FastData author, but this wasn't looking familiar. >

[tg-trunk] Re: r1126: to_unicode removed from Widget

2006-04-11 Thread Max Ischenko
Michele, > It's great to have you watching unicode related things as I'm not > experienced on this camp, thanks for the test, as I said there is not > problem, I'm going to put to_unicode back into the game! ;-) I'm all for removing monkeypatching code. In this specific case, leaving to_unicode

[tg-trunk] Re: providing default error handler: how to get the traceback?

2006-04-11 Thread Max Ischenko
> I'll look into it. However the main problem is the traceback is not a > property of the exception but a completely separate entity. That's true. But the error handling code seems to be messing it up. > What I will probably do is wait for First Class (to become trunk) and > than change [each

[tg-trunk] Re: r1126: to_unicode removed from Widget

2006-04-11 Thread Max Ischenko
Michele, > In r1126 [1] I've removed the use of to_unicode from adjust_value, it > should work all right since we are now using the CP decoding filter, > anyway if you (for example Max and Jorge that I think need this > feature) start experiencing problems we will just revert this change, > it's

[tg-trunk] providing default error handler: how to get the traceback?

2006-04-11 Thread Max Ischenko
Hi, My post is mostly for Simon. I want to intercept all application errors that normally results in CherryPy's 500 Internal Error page to save error info and display it differently. My error handler defined like this: @dispatch_error.when("tg_exceptions is not None") def notify_on_error(con

[tg-trunk] Re: abstracting cherrypy further

2006-04-11 Thread Max Ischenko
Kevin, Fine, I got it. > On 4/11/06, Max Ischenko <[EMAIL PROTECTED]> wrote: > > But what about "simpler"/more common things like request, response and > > error classes > (HTTPError and NotFound)? I'd say promoting them is OK. After all, w

[tg-trunk] Re: r1126: to_unicode removed from Widget

2006-04-11 Thread Max Ischenko
> > In r1126 [1] I've removed the use of to_unicode from adjust_value, it > > should work all right since we are now using the CP decoding filter, > > anyway if you (for example Max and Jorge that I think need this > > feature) start experiencing problems we will just revert this change, > > it's

[tg-trunk] error_handling dispatch problem?

2006-04-11 Thread Max Ischenko
I updated to r1122 and now when an exception occurs inside my controller I got this error instead of plain traceback. Can anyone confirm? Page handler: > Traceback (most recent call last): File "c:\python24\lib\site-packages\cherrypy-2.2.0-py2.4.egg\cherrypy\_cphttptools.py", line 106, in

[tg-trunk] Re: abstracting cherrypy further

2006-04-11 Thread Max Ischenko
> > What I propose is to make these names available through the TurboGears > > namespace so > that we'll be future-safe. I know about YAGNI, but the transition already > started so we > shouldn't stop halfway, IMO. > > I'd rather take this action during the First Class work itself. > Because, f

[tg-trunk] Re: turbogears.flash() inconsitency

2006-04-10 Thread Max Ischenko
Andrey, > In current turbogears trunk turbogears.flash() function works a bit > inconsistently: flash message is displayed only on next request after a > message was set. This is because flash message is implemented via > cookies and cookie is not accessible on the same request (before it is > se

  1   2   >