*** titopbs has quit IRC good morning *** dimas has joined #gnuenterprise good morning *** chillywilly has quit IRC good morning dimas hi rynik hi dimas. Do you know the difference betwen using gnue.appserver.language.App.App and GClientApp as a baseclass? Is there like an old syle and a new style or is it two different classes with different usage? *** kilo has joined #gnuenterprise Is there like an old syle and a new style or is it two different classes with different usage? (repost for kilo) hi kilo, Do you know the difference betwen using gnue.appserver.language.App.App and GClientApp as a baseclass? Is there like an old syle and a new style or is it two different classes with different usage? first seems like more new *** johannesV has joined #gnuenterprise good morning johannesV good morning rynik good morning rynik: dunno, never done that, ask johannesV johannesV, Do you know the difference betwen using gnue.appserver.language.App.App and GClientApp as a baseclass? Is there like an old syle and a new style or is it two different classes with different usage? language.App.App is derived from GClientApp rynik, does that answer your question ? GClientApp is a base class for all (client) applications this means it provides a framework for handling options, using connections and the like OK, I'll just look in the API and see what it adds. language.App.App adds another command-option, and provides access to appserver's sessionmanager as well as a lot of methods encapsulating access to appserver like newSession (), getFilters (), And I learned it adds command option in a new fasion. well, i'd say in the preferable fashion the base-class GBaseApp defines a method 'addCommandOption' to accomplish such an addition in derived classes one shouldn't modify COMMAND_OPTIONS sequence directly rynik, what are you trying to do ? Right, good to have you around jahannesV, I'm just pokeing around. *** btami has joined #gnuenterprise good morning btami good morning johannesV have you noticed the typo in win32.UILoginHandler.py ... -from gnue.forms.uidrivers.win32.dialog import InputDialog +from gnue.forms.uidrivers.win32.dialogs import InputDialog ah, thx and i've noticed the dropdowns not working properly ... (at least i've tried the sample-data included at the bottom) i mean dialogs.InputDialog of course not implemented yet, just a basic ah, ok, i've thought something like that it's a quite hard thing to accomplish, isn't it :) :) i'm about to change the concept of GLoginHandler i focused to implement logindialog with inputdialog this is why the UILoginHandler will get reduced to a few lines (if they provide a InputDialog) yes btami, right, but that's only a matter of having a single function implemented it's signature is: _askLogin (self, title, fields) yes, i know where title is the dialog-title and fields is a sequence of field-definitions as required by InputDialog all other code fades out i'v committed it to win32 UIdriver too yeah, that was what i've checked out yesterday ... i mean the getInput() ok so you can go on with that yeah, but i'll leave that win32 thing up to you .... :) *** holycow has joined #gnuenterprise the dropdown stuff? :) yeah, exactly ... :) ok :) *** reinhard has joined #gnuenterprise good morning all hi reinhard and all *** sjc has joined #gnuenterprise *** yure has joined #gnuenterprise Hi again, are these equivalent? COMMAND_OPTIONS = [ ['welcome_option','w','welcome',0,0,None, 'Display the welcome' ], ['lang_option','L','lang',1,'english','language', 'The language to use to print welcome '+ \ 'Valid values: english, maori' ] ] self.addCommandOption ('welcome', 'w', help = _("Display the welcome message.")) self.addCommandOption ('lang', 'L', argument = 'language', default = 'english', help = _("The language to print welcome " "Valid values: english, maori")) Or am I missing something? yes, should be equivalent thanks yes, also think so except that the latter would be prefered and of course the former is in the class body and the latter must be put within the __init__ procedure the former (if given that way) would *replace* all inherited command options !!! so they are *not* the same Yes I know, I was just interested in the effect of the assCommandOption Yes I know, I was just interested in the effect of theassCommandOption addCommandOption does nothing more than create a new CommandOption instance and add it to the COMMAND_OPTIONS sequence s/ass/add *** holycow has quit IRC Put it this way. Would my above calls to addCommandOption give me exactly the above addition to COMMAND_OPTIONS yes thanks btw: as we now have daily generated epydocs, we should use it: http://www.gnuenterprise.org/tools/common/docs/api/public/gnue.common.apps.CommandOption.CommandOption-class.php :) this is a list of parameters also for addCommandOption but it would need some more description, wouldn't it :) Yes, I'm not getting any wiser :) *** dimas has quit IRC *** ajmitch_ has quit IRC shortOption is before longOption is that saying ('w', 'welcome... is prefered? no, name is first 'welcome', 'w', 'welcome' means that you will access it with OPTON['welcome'] and it will be --welcome or -w right but you can also have 'foo', 'x', 'bar' meaning you have OPTION ['foo'] mapping to -x and --bar *** wendall911 has joined #gnuenterprise *** dimas has joined #gnuenterprise *** ajmitch_ has joined #gnuenterprise gack!!!!!! sarge is frozen planned release date may 30 wtf wow ajmitch_: if you read this - *please* fix the RC bug in appserver - gnue-appserver has already been removed from sarge due to this bug but otherwise I think it's ok (from gnue point of view) - we have quite usable releases in sarge now *** dcmwai has quit IRC *** sjc has quit IRC Does this hold for description of the argument of addCommandOption? acceptsArgument Does this option require a value to be assigned from the command line. Sounds correct although I usually would write something like "True if the option requires..." off for lunch What is this argument: argumentName And these two: category, action @list debian kilo: bug, file, incoming, new, and version *** tiredbones has quit IRC @debian.version tinyerp @debian version tinyerp kilo: No package found for tinyerp (all) *** tiredbones has joined #gnuenterprise back from lunch and off to customer... *** btami has quit IRC *** kilo has quit IRC *** jamest_ has joined #gnuenterprise *** chillywilly has joined #gnuenterprise reinhard, back to addCommandOption What is this argument: argumentName And these two: category, action rynik, argumentName is used for help-text-generation (when you call the script with --help) if you have an arugment 'foo' with an argumentName 'aFooValue' the help-text will look like "--foo " johannesV, argument==argumentName? rynik, if you give an argument too, this will override the argumentName hi, i have a trouble using dates as find conditions category is used to create groups of command options, where there are the groups "base", "dev", "connections" and "general" predefined there is an option --help-dev, --help-connections to give a special help-text for these groups of options DB000: InvalidParameter: datetime.date(2005, 3, 1) <--- but the field _is_ a date mnemoc_, i'm not sure if we already support datetime.date's in a find () ... johannesV: what should i give it then? since it's not very long ago we've upgraded our prerequisites to python2.3 ... this might take some time .. does that mean i can't search over a date field? mnemoc_, usually an mx.DateTime .... but i'll have a look about a fix ok :) mnemoc_, no, of course you should be able to search for date-fields mnemoc_, you are using packages or svn ? yes rynik, action is a function-pointer; if supplied this function will be called if the option is given on command line automatically oh.... DB000: sess.login (authentication ['user'], authentication ['password']) DB000: KeyError: 'user' i think this should be username, shouldn't it ? johannesV, Great, thank you. Still dont see the use for both argument and argumentName though. Can you clearify? johannesV: this is new rynik, there is none, just use 'argument' OK. mnemoc_, what are you doing, are you using language.App, can you give me some details ... yes, language.App and newSession should i use a dictionary now? def newSession (self, username, password, params = {}): uhm you call it like "session = app.newSession ('foobar', 'secret', {'base_company': 'demoa', ...}) but you might leave that params-thing away completely so nothing should change for old code (old *working* code of course) :) it worked yesterday, but not after my last svn up well, that's bad ... :) looks like i've broken something then ... :) :) where are you using 'authentication' here ? I have a patch that updates common/Dev.Guide with the use of addCommandOption. I would like it added to the guide. Anyone interested? rynik, i think kilo did that upload last time, did he ? mnemoc_, are you calling this script with a --connection= .... ? johannesV: yes ok, and that connection is using authentication, right ? in fact, that connection is appserver, isn't it ? one yes [gnue] is an appseerver but i also have 23 dbf-s mnemoc_, why do you have 23 dbf-s ? to import them using that script to the appserver ok, but you have only one connections.conf entry for the dbf no, one per file uhm, why ? because provider=dbf use file= [all dbfs] provider = dbffile dbname = /some/dir/%(table).dbf oh should do the trick ... (but let me check that) cool new feature just a sec no, it's common to *all* filebased drivers last week i asked and it wasn't there.... at least that was what i was told :) ok, it's a bit different then: dbname=/some/dir/%(table)s.dbf there are also these aliases %(home)s for the user's home-dir *** johannesV_ has joined #gnuenterprise and '%(configdir)s' for for gnue's configuration directory @seen kilo rynik: kilo was last seen here 3 hours, 0 minutes, and 45 seconds ago saying: @debian version tinyerp %(..)s right ok, but now I've to look why you get that exception ... can i set my own translations? ah, yes :) connections.conf is not my show stopper mnemoc_: last time you asked you were using debs IIRC %(...)s is only available in svn reinhard: .tgz but yes :) i moved to svn because dbf support was broken on 0.5.14 :) *** jcater has joined #gnuenterprise ah yeah exactly sorry that i forgot to tell you about this new feature then thanks for adding that new feature :) mnemoc_, can you give me the last few ines of the traceback ? *** johannesV has quit IRC s/ines/lines/ DB000: Traceback (most recent call last): DB000: File "/opt/gnue/lib/python2.4/site-packages/gnue/appserver/geasSessionManager.py", line 251, in open DB000: sess.login (authentication ['user'], authentication ['password']) DB000: KeyError: 'user' just that hm oops where is that still??? that's strange since my geasSessionManager.py looks quite different there ... ? should be '_username' and '_password' conn = GConnections.GConnections(location, loginHandler, loginOptions) sess = geasSession.geasSession (conn, self._authAdapter, self, authentication) sess.login (authentication.get ('_username'), authentication.get ('_password')) this is what should be there ... ?! you have appserver release with common svn? do you have local changes to geasSessionManager ? my running appserver is 0.4.1 shall i move it svn also? you have to or you have to give up on authentication for this newSession() <--- empty? yes and remove the authentication from gnue.conf on appserver side that should do it hmmm DB000: self.appserver = self.newSession() DB000: TypeError: newSession() takes at least 3 arguments (1 given) no no? err you were faster to notice I meant "no" to what I said above :) sorry, no luck you have to move to appserver svn :( ok btw, session.find() fails if condition has datetime.date() we have been doing no release for way too long mnemoc_: yep, I saw you talking with johannesV_ :) mnemoc_: we are still using mx.DateTime throughout can i convert? (as i've said before) convert from datetime to mx.DateTime? yes I think you could even *create* a mx.DateTime in the first place don't remember the function, but should have somehting quite similar to date() :( ah oh you get the datetime from dbf, right? :) johannesV_: you already looking at a possible fix? that datetime comes from a COMMAND_OPTION ah but i will use datetime from dbf also ok jcater, jamest_ are any of you interested in a patch for common/Dev.Guide or is it just kilo I should be talking to? >>> import mx.DateTime.ISO >>> import datetime >>> dt = datetime.date (2005, 04, 27) >>> x = mx.DateTime.ISO.ParseDate (dt.isoformat ()) mnemoc_, that should do it oh johannesV_: just in case, proper fix would go in xmlrpc/pw_xmlrpc/typeconv.python_to_rpc *** titopbs has joined #gnuenterprise reinhard: what about xmlrpc/pw_xmlrpc/typeconv.python_to_rpc ? support for datetime alternatively to mx.DateTime Can I just mail the patch to gnue-dev at gnu.org? rynik: please do, I hope somebody will take care of it reinhard: thanks rynik: yes *** titopbs has quit IRC reinhard, are you going to fix that datetime -> mx.DateTime in xmlrpc ? uhm? if you have time, i'm glad if you can otherwise I will later this evening ok, i'd like to finish that login-dialog for curses first :) so it looks like it has to wait a bit johannesV_: yes, it's more important that you can commit your forms changes before you leave oh, i've already commited all of that changes it looks like #gnue-commits and commit-emails are not working atm ah is a 'YYYY-MM-DD' string ok for mx.DateTime.ISO.ParseDate ? yes thanks do you plan to get rid of mx some day or you are happy depending on it? the former johannesV_: could you add a ":" to the login field labels for appserver? former=first? so "Benutzername:" instead of "Benutzername" mnemoc: yes thanks :) we plan to go datetime at some poinit but I fear it will cause some incompatibilities so the first possible chance will be 0.5 ic another question: there is a way to use self.foo as just foo smarter than setting foo = self.foo on every function? johannesV_: other than the ":", the new login dialog is *way* cool mnemoc: using self.* is just a matter of getting used to it reinhard, thanks :) reinhard: ok :) great to see you working on curses will pulldown be implemented soon? reinhard, i can add that colon to the loginFields of appserver and dbsig2 (although we have to re-translate them then) mnemoc: is already (in svn) yeah, did that this week ... johannesV_: no, I would mean reinhard: oh! cool add them at a later point one has to use Ctrl-W to call the list of valid options (to pick one) for all labels ah, ok also for the dropdown labels now i see yeah like "Fiscal Year:" hmm, let me check ... i could do it in the UI's InputDialog I *think* you already had that in the old login dialog version but then i have to do it multiple times (well there it was implemented in UILoginHandler) I'd prefer in GConnections or so let me look hmm, in GConnections ... ? no, maybe in GLoginHandler hmmm we're already iterating the fielddefs there yet-another-dumb-question: if i open a session on __init__, where should i close it? fields.append ((label, name, ftype, default, master, elements)) reinhard, just committed :) ok, so my guess was right :) thanks Index: GLoginHandler.py =================================================================== --- GLoginHandler.py (Revision 7523) +++ GLoginHandler.py (Arbeitskopie) @@ -93,6 +93,9 @@ fields = [] for (label, name, ftype, default, master, elements) in fielddefs: default = defaultData.get (name, default) + if not ftype in ['label', 'warning', 'image']: + label = "%s:" % label + fields.append ((label, name, ftype, default, master, elements)) yeah :) looks much better now ;-) bbl this evening hmm, but now i've to change the basicLoginHandler i think ... :) *** reinhard has quit IRC DB000: InvalidFormatError: Not a valid DBF file: Missing terminator flag johannesV_: can ---^ be due to your last changes on dbffile and friends? mnemoc, i've written gnue's own dbf.py do you have large dbf files ? and, yes it has :) :) Number of records.....: 7359 (00001cbfd) Length of header......: 610 (0262d) Record length.........: 365 (016dd) Columns in file.......: 18 Rows in file..........: 7359 that is the dbf producting the error can you send it to me by mail or can i download it from somewhere ? minute so i might check how to tweak our dbf.py url queried err mnemoc, please svn update your gnue-common --- your file should be readable now :D