*** klasstek has quit IRC *** reinhard has joined #gnuenterprise good morning all *** johannesV has joined #gnuenterprise good morning *** btami has joined #gnuenterprise good morning hi btami hi btami did you see our discussion from the day before yesterday about requery after commit? *** yure has joined #gnuenterprise reinhard: yes, but can't remember if there was any conclusion yes, that's right actually I was hoping for your input i can summarize my complaints bbk erm bbl i mean complaints of our employee first question is but i have start from the beginning is the requery only wanted after a rollback, or also after a commit? hmm, i had no time to think about it let me describe our situation first ok we have an old dos based (foxpro) payroll app it works with only some hundreds of peops data in most cases so, all of my forms starts with all data opened something similar as prequery="Y" for all datasources and all form has two F keys one for browse, and one for seek 1 record by a key (name, etc.) all modification is happening on 1 record at a time after user modifies something, he can save or escape so in a new gnue based inhouse form the "clear form" button is misleading her koz she thinks it only will undo only the form she modified right now this was 1. complaint th 2. is after pressing this button, koz she did something wrong she lose prequery='Y' and the current record she worked on was this understandable ? yes ok :) both issues are actually related to the "undo" function, and not to commit in any way yes so commit behaviour could stay as it is now? i think so because at the original discussion we disgressed into thinking that after commit, changes from the backend should be refreshed and thinking more about this, it seemed a bad idea yep so the question is would the "undo" function revert to the state of the result set before any change was made or should it refresh data from the backend risking that, for example, the current record suddenly disappears because another user has just deleted it or records "jumping around" because somebody changed a record in a way relevant for the sort order seems the former is a bit better ok, I think this is something that would also fit jcater's and jamest's concepts but we might want to sleep over it once again :) you mean "undo" will take him to the state where he was after last "save" , arn'n you? right ok, cool or after the last query, whatever was last yep *** yure has quit IRC *** btami has quit IRC *** lupo__ has joined #gnuenterprise *** jamest has joined #gnuenterprise *** jcater has joined #gnuenterprise bbl *** reinhard has quit IRC *** johannesV has quit IRC *** johannesV has joined #gnuenterprise *** btami has joined #gnuenterprise *** klasstek has joined #gnuenterprise reinhard: I saw the unsed import commits if you're not using pylint yet, i'd suggest it as it catches those *** derek has joined #gnuenterprise *** sjc has joined #gnuenterprise *** SachaS has joined #gnuenterprise *** reinhard has joined #gnuenterprise do we have a decent configuration for pylint? seeing my fresh and beautiful actions.py rated with -40/10 makes me feel depressed ;-) wow I like this :) yes i have one at home ok there are only a few edits for example I would like to not require docstrings for __xxxx functions do you have a .pylintrc file in $HOME and if possible it should accept u_(), _(), gDebug() et al do you have a .pylintrc file in $HOME :) nope hmmmm I used pylint for the first time now do pylint --generate-rcfile would be nice if you could commit your .pylintrc in common/utils it's 2 edits atm iirc in [REPORTS] # Include message's id in output include-ids=yes in [VARIABLES] additional-builtins=u_,gDebug,gConfig ok that should do it as for the """""" on __XXXX functoins I'd be tempted to just do a one liner as I assume you're talking __get__ type things? no they are already excluded or __call__ no-docstring-rgx=__.*__ that msg-id on thing is nice I consider purely local functions (like __foo()) as non-docstringy I changed it to no-docstring-rgx=__.* as you can go to http://www.logilab.org/projects/pylint/documentation/features and get notes on why it flagged it also, in the masks stuff i've started doing things like # Copyright 2001-2006 Free Software Foundation # # pylint: disable-msg=R0903, # R0903 disabled as these classes represent placeholders and # as such don't have public methods as that's per module disable of pylint msgs disable-msg=R0903,C0103,ETC010 nice i figured we'd disable the msgs we were ok with in that module then occasionally replace the # pylint: disable-msg=R0903, with # pylint: enable-msg=R0903, and verify that the warnings are all what is expected then re-disable it i really like pylint it catches errors that would be a bear otherwise the only bad think about that disable of doc strings thing for me it's a great reminder that a method doesn't have a comment describing function I have a question about GTriggerCore there are reqirements to an object so it can have triggers attached and there are other requirements so the objects can be visible in the trigger namespace AFACT both things are implemented in GTriggerCore is there any reason why this is not separated? as there might be objects that can be seen in a trigger, but can't have a trigger themselves (for example a menu item, a toolbar, a label...) oh..... I just noticed that "can have triggers attached" would actually be GTriggerExtension so I don't understand why _localTriggerNamespace and _validTriggers are defined in GTriggerCore instead of GTriggerExtension they should be 2 classes i thought they were two eh, wait, you said that at the bottom didn't you :) jamest: just read the last two lines from me :) yes is the localTriggerNamespace the namespace from that instance down? at one time i think we could attach a triger to something (say a block) and self == ref to block self.field == ref to field in that block however I think this broken years before i went MIA this is exactly that AFAICT and so it would only make sense for objects that you *can* actually attach a trigger to I mean I could do the standard gnue evolutionary way: change it and look who screams but I figured I'd ask before :) i would think so ok *** chillywilly has quit IRC another question *** chillywilly has joined #gnuenterprise each object in the trigger namespace has a _parent property do you make use of that in any way? in my triggers? no i believe i always use absolute reference from form. form.block.field ok I figure that you also don't make use of the _object property of trigger objects that let you directly access the GObj object that should actually be hidden behind it i do not i *think* that was added for papo folks and was a horrible, horrible idea ok so you agree with removing it again yes good i see the trigger namespace as ideally being a restricted python environment with control over imports (not implemented and not sure if possible since we do javascript to IIRC) having no access to the GObjs, only to instances of the class that implements the namespace representation of that object in the trigger damn, could i have said that any more complicated I think I understand, and I agree with that concept there is a class that maps a var name in the trigger to an object and controlls access to that object via the exposed properties right methods, etc that's GObjNamespace that was to hide/protect the GObj based instances exactly the class I'm cleaning up, pep8ifying etc. right now :) thus all these questions :) so out of curiosity, did you get above the -40 in pylint :) yes it was mostly about undefined u_ it's always depressing to hit those also, i'm not sure if it's good form but I started doing __revision__ = "$Id$" to get rid of that warning about the missing __revision__ I have actions.py with only a few warnings left that I can't do anything about because they are based in the abstract base classes I removed the __revision__ from my .pylintrc :-) and added __all__ instead which I really consider useful to have what's __all__? * jamest recalls using it in __init__.py files at times documents what will go into "from foo import *" let me explain if you have foo.py: from bar import baz def frob(): pass ---- and then somewhere you do from foo import * it does not only import frob but also baz because baz is in foo's global namespace because of the import but if you have in foo.py an additional line __all__ = ['frob'] from foo import * will only import frob err I think that was a rather complicated explanation :) no, i got it, we've used it in common, i just haven't needed in a while so I followed *** johannesV has quit IRC *** btami has quit IRC *** jamest_ has joined #gnuenterprise *** jamest has quit IRC I'm now trying to understand what __properties__ is all about in triggers is it correct that I must do form.myBlock.__properties__.editable = True instead of iirc it was too allow you to set certain things form.myBlock.editable = True? yes it's poorly named but we were trying to avoid a namespace issue and that's done because I could be unlucky and have a field in that block with the name "editable"? right but there are better ways i'd imagine .setProperty('prop',value) I'm not sure I can think of any or setProperty(form.block.field, property, value) hmmm is this __properties__ in use at all? in a demo trigger somewhere :) so we could dare break it? i would think so actually hmmm..... I would prefer going to the most intuitive form.myBlock.editable = True because with the same argument, we could also say it's a problem that no block may have a field named "gotoRecord" because form.myBlock.gotoRecord is a function and I like to name stuff __ ____ too! jcater __a__, __x__, __j__ __q__ so what do you think? i think i'm ok with direct access ok *** jamest_ has quit IRC *** lupo__ has quit IRC *** sjc has quit IRC good night all *** reinhard has quit IRC *** klasstek has quit IRC *** derek has quit IRC