*** cilkay has joined #gnuenterprise
*** btami has joined #gnuenterprise
*** sjc has joined #gnuenterprise
*** johannesV has joined #gnuenterprise
*** reinhard has joined #gnuenterprise
*** lekma has joined #gnuenterprise
<lekma> morning all
<reinhard> good morning lekma
<lekma> hi reinhard
<johannesV> hi lekma
<lekma> morning johannesV
<lekma> need coffee
<lekma> back in 5 min
*** kilo has joined #gnuenterprise
<kilo> good morning
<johannesV> hi kilo
<lekma> hi kilo
<kilo> hi johannesV, lekma
<johannesV> kilo, i assume you've looked at foo.gfd ?
<kilo> errrr not really, i spent half night with a whisky bottle, fighting illness...
<johannesV> :)
<kilo> but i brought it with me, so will check it soon
<kilo> hmmm, i mean the gfd, not the whisky...
<reinhard> lol
<kilo> johannesV: great, it works.
<ajmitch_> hi
<reinhard> ajmitch_: thanks for debs!
<johannesV> kilo, there's still a problem when pressing F11 (rollback)
<kilo> what use blkPerson has?
<kilo> line 68
<johannesV> blkPerson is used so the master-detail-stuff works !
<johannesV> it took me some time to find this out :)
<johannesV> just comment it and try again ! you'll get some mysterious errors ...
<kilo> so you got to define a dummy, empty block to make the MD work?
<johannesV> well, i wouldn't say dummy
<johannesV> it is needed so some magic stuff happens in GF* and common
<johannesV> (like master-detail-sync and the like)
<kilo> ok, we are the knights who say ekiekiekiekiboinboomchang
<johannesV> an interessting question remains: if we set the static condition of the master record (person) using setCondition ()
<johannesV> why does this condition get lost on a rollback !
<johannesV> i've tried the same with appserver's sample.gfd and there the static condition remains active even on a rollback
<johannesV> if you can fix this problem, the form should work in all circumstances ...
<reinhard> kilo: *it*
<johannesV> anyway, you'd have to keep track of duplicates and the like too
<johannesV> didn't they say always *never* ?
<kilo> nii
<kilo> http://bau2.uibk.ac.at/sg/python/Scripts/HolyGrail/grail-13.html
<kilo> and
<kilo> http://bau2.uibk.ac.at/sg/python/Scripts/HolyGrail/grail-19.html
<johannesV> ah, i knew how to pronounce it
<johannesV> but i didn't know how to spell in english :)
<kilo> and the word you should have not used is, as reinhard said, 'it'
<kilo> so, well, it works, but...
<johannesV> reinhard, how do we call the module that defines a class ?
<kilo> looks ugly
<kilo> and contains business logic
<johannesV> right, but a listbox is definitely the wrong widget
<kilo> which i would like to delegate to appserver
<johannesV> for example: you always have a 'NONE' entry in there
<johannesV> kilo, what kind of business logic ? that creation of a new record ?
<kilo> aye
<johannesV> i don't think this should go into appserver ...
<reinhard> johannesV: we haven't yet invented a special word for that
<reinhard> usually I say "the module that originally defined that class"
<johannesV> damn ... obviously documenting in german isn't much easier than in english ...
<reinhard> but please be aware that the devguide hasn't explained class extension yet
<johannesV> no ?
<johannesV> i thought i've read it
<reinhard> just a short mention that there *is* class extension
<johannesV> ah
<johannesV> s2t
<johannesV> or should i say b6t
<johannesV> don't we have some bugs to fix ?
<kilo>  /msg reinhard he wants to hack, he wants to code, not write blo.dy documentation...
<johannesV> kilo, yeah, yeah ... !
<kilo> lol
<kilo> in a gcd, can a parameter of a proc have default value?
<johannesV> kilo, no it cannot
<kilo> so i should set it in the code
<johannesV> kilo, where should this default be stored and of which type should the column be to store the default ?
<johannesV> kilo, yes set it in the code
<kilo> johannesV: dunno
<johannesV> well, that's the main problem
<kilo> that i dunno? 8-)))))
<johannesV> no, *lol*
<johannesV> the main problem is "how to store default values" (of different types)
<kilo> but that IS a problem 8-)))
<kilo> but i have an appropriate answer (from a customer): store it on the computer
<kilo> 8-)))
<reinhard> "now I have a hard disk with 80 GB and I cannot store a simple number???"
<reinhard> ;-)
<kilo> yes, exactly
<reinhard> lekma: are there any appserver side problems you need solved?
<lekma> a few (at least one), could you give me half an hour i need to check things with other consultants/devs
<reinhard> ok
<lekma> thx
<reinhard> johannesV will be happy to fix things ;-)
<reinhard> as he will have to stop documenting then
<kilo> reinhard: reloading a gcd while appserver is running
<johannesV> lekma can do this right now :)
<johannesV> since he has an rpc method for this
<johannesV> but it's unofficial atm
<kilo> but he is 2000 km from here...
<kilo> and rpc can not stretch this far 8-)))
<johannesV> reinhard, have you tried the hotline.gfd ?
<reinhard> ah no
<reinhard> forgot that
<reinhard> let me try
<lekma> the following list is just things that we think we need, in general.
<lekma> most of these issues we didn't even have time to have a look at atm,
<lekma> so take it all with a grain of salt.
<lekma> - server side logs
<lekma> - global authentication (a find/request should return access level rw, ro, no access)
<lekma> - global proc (this one is the important one atm, i think i can simulate it by creating an object, let run a bound proc, and then delete the object. all from rpc calls)
<lekma> - a way to pass a session object to gnue-reports (maybe it is already posssible)
<lekma> - case insensitive find/request (or a way to specify when you need case insensitive search)
<lekma> - a data type for full-text search (i think it can be used at least with mysql and pgsql, they both have a specific data type for fields needed by a full-text search)
<lekma> kilo: i can send reload.diff
<lekma> if you want
<lekma> ie reloadClass
<reinhard> johannesV: svn up and restarted appserver, still works perfectly AFAICT
<kilo> lekma: thx, plz send it in email: kilo att gnuente... org
<johannesV> harr, i've just added a fix ...
<johannesV> so you have downloaded the fix ..
<lekma> kilo: ok
<reinhard> ok
<kilo> this firewall filters out everything...
<reinhard> lekma: thanks for the list
<reinhard> lekma: so actually no real show-stoppers for you there?
<lekma> reinhard: maybe the global proc (as long as i don't try the possible solution)
<lekma> reinhard: i have to test it today
<lekma> sales consultant need it
<reinhard> lekma: what I would do for global procedure
<reinhard> most systems have a kind of "parameter" table (class)
<reinhard> where only a single instance exists
<reinhard> you could make the procedure a proc of that class
<reinhard> johannesV: could you somehow add lekma's list to svn?
<reinhard> (the items that aren't in the ROADMAP.in yet)
<reinhard> maybe in ROADMAP.in
<lekma> reinhard: i see what you mean i'll try it later today
<johannesV> reinhard, for which version ?
<reinhard> where it fits
<johannesV> authentication is already listed, as well as that management-interface stuff
<reinhard> i'd say server side logs would fit the management interface
<johannesV> case-insensitive search/fulltext-search is something completely new
<johannesV> so these logs have nothing to do with the debug-file i think ?
<reinhard> yeah we could add these search things to BUGS
<reinhard> because it would match the other "has to be implemented in common"
<reinhard> :-)
<reinhard> I would like lekma to tell more about what kind of logs would be useful
<reinhard> but I guess he is too busy at the moment
<reinhard> :-)
<reinhard> lekma: maybe you want to write a short email on what kind of logs you would like to see when you have time
<reinhard> and we keep it out of our TODO list until then
<reinhard> also for the global procedures I'd like to wait how it works out with the parameter class
<johannesV> i think there should be a mechanism for this *without a fake-class*
<reinhard> and I have no idea what is needed for the gnue-report thing
<reinhard> so actually there's not much left anyway
<johannesV> well, i had that case-insensitive search problem in gnue-cddb
<johannesV> and i've solved it using a calculated field, doing a string.upper ()
<lekma> i need to enter a meeting right now, i'll try to be more specific about all these points a bit later, (and anyway thx for all your help)
<kilo> lekma: thx for the mail
<reinhard> lekma: you're wolcome
<reinhard> welcome
<reinhard> and I wish you luck for the meeting :)
<kilo> johannesV: still in need of something to hack?
<btami> bbl
*** btami has quit IRC
*** wayneg has quit IRC
<johannesV> kilo ... of course :)
*** wayneg has joined #gnuenterprise
<kilo> great
<kilo> hmm, first of all, dont svn update gnue-contrib...
<kilo> but delete the invoice db, then bulid it up, but dont let gsscvs add any data to it
<kilo> now start LOC_Region.gfd. there is no country of course. Click edit, add a country (or more, if you like).
<kilo> exit the Country form, click away from the dropdown, then drop it down, you see the newly inserted countries.
<kilo> try to add a region with any of the countries. when you want to commit, it will produce an error
<johannesV> saying what ?
<kilo> errr, well, i have to delete my db again...
*** dimas has quit IRC
<kilo> Traceback (most recent call last):
<kilo>    File "/home/gabor/SVN/gnue/.cvsdevelbase/gnue/appserver/geasSessionManager.py", line 139, in commit
<kilo>     s.commit ()
<kilo>    File "/home/gabor/SVN/gnue/.cvsdevelbase/gnue/appserver/geasSession.py", line 288, in commit
<kilo>     self.__connection.commit ()
<kilo>    File "/home/gabor/SVN/gnue/.cvsdevelbase/gnue/appserver/data.py", line 670, in commit
<kilo>     resultSet.current.setField (field, value)
<kilo>  AttributeError: 'NoneType' object has no attribute 'setField'
<johannesV> ok, so this is the other side now ...
<johannesV> btw. there's no item_item class anymore ?
<kilo> svn up now, so all gets back to normal.
<johannesV> ok
<kilo> svn up both gnue and gnue-contrib
<kilo> i've merged invoice's gcd files back to gnue packages
<kilo> and the above behaviour is the same for any form that has a dropdown whose valueset one extends from empty state
<johannesV> ?
<kilo> i mean the error above can be produced on several forms, those that have a dropdown
<johannesV> but only if you call resetForeignKey (), right ?
<johannesV> hmm, no it's the commit in the other form ...
<johannesV> kilo, maybe it's the commit in the other form, which does *not* reload the right classes ... (still searching)
<kilo> well i dont know
<johannesV> hmm, this is interesting
<johannesV> the region record has a state 'changed' in data.py ... although it has been commited by the other form
<kilo> ah, so you are n track now
<johannesV> well, the main problem here is a bit tricky
<johannesV> you start the Region form, so you have an empty region record
<johannesV> say you press edit then, starting the country-form
<johannesV> you add a new country and press commit
<johannesV> this commit saves the newly added country, but since you're in the same session as before (where you've added a new region) this new region get's commited too
<johannesV> the question remaining is now, why has this new (and commited region) still the state 'changed' and why is it still in appserver's cache
<johannesV> since a commit should clear the cache
<johannesV> i think it's not a problem regarding dropdowns but much more general
<johannesV> like having another transaction (second form) which interferes the first one
<kilo> maybe it is general, it is only here that i have seen it happen
<johannesV> well, in real both forms do run in the same transaction
<johannesV> as i've talked to reinhard last week about a similar problem
<johannesV> ah
<johannesV> now i've found something else ...
<johannesV> stand by ...
<johannesV> ok
<johannesV> problem is fixed!
<johannesV> kilo, you'd have to add another line to your gfd
<johannesV> :)
<kilo> johannesV, the hacker masta
<johannesV> but, still, the problem is difficult with that two forms
<johannesV> i'll explain the situation again:
*** dimas has joined #gnuenterprise
<johannesV> form A creates a REGION record
<johannesV> then the form B is called in which we create a COUNTRY record
<johannesV> now this country record get's commited
<johannesV> so what is in the appserver's cache now?
<reinhard> nothing
<johannesV> the region record has not yet been posted to the appserver
<johannesV> so the call of the commit *siltently* drops the region
* reinhard doesn't behave well as a pupil ;-)
<johannesV> but the next *store* of the region does not find it anymore
<johannesV> exactly !
<johannesV> so if you add a "blk.update  ()" in your edit-trigger code *before* runForm ('...')
<kilo> as in the wiki: Topic: HowAppServerWorks
<kilo> Only God, Reinhard and Johannes knows about it.
<kilo> Hmmm, maybe God only knows their phone number... :-)))
<johannesV> the region-rec get's posted
<johannesV> :)
<johannesV> but be aware that a commit in the country-form also posts you pending REGION record
<kilo> then it is not the best solution
<johannesV> as i've mentioned before, there should be a mechanism to start another transaction for such things
<johannesV> or something similar
<reinhard> I think what you really would want in such a case would be the dialog to open it's own session
<johannesV> right
<kilo> yes
<reinhard> however that's something IMHO jamest/jcater would have to decide how to implement
<reinhard> as it's one of the basics of forms AFAICT that connections are reused
<kilo> hmm, imho as it CAN result in an error, it should be changed somehow
<kilo> but now got to leave, bbl
*** kilo has quit IRC
*** jamest has joined #gnuenterprise
*** johannesV_ has joined #gnuenterprise
*** johannesV has quit IRC
<reinhard> l8r all
*** reinhard has quit IRC
*** wendall911 has joined #gnuenterprise
*** reinhard has joined #gnuenterprise
*** reinhard has quit IRC
*** SachaS has joined #gnuenterprise
*** kilo has joined #gnuenterprise
*** sjc has quit IRC
*** johannesV_ has quit IRC
*** btami has joined #gnuenterprise
*** titopbs has quit IRC
*** lekma has quit IRC
*** johannesV has joined #gnuenterprise
<jamest> before I go mucking about in forms
<jamest> i need to do the following
<jamest> press a button and have it fill out a value in the currenly active block   (2 blocks shown on screen)
<jamest> since it's be ages since I've been in forms code i wanted to see if some way of getting active block already exists
<jamest> and if not then I'm wondering if people would think a form level trigger function along the lines of getActiveBlockName() would be the way to go
<jamest> or
<jamest> a block level trigger function  .isActive() would be better
<jamest> or both :)
*** holycow has joined #gnuenterprise
*** sjc has joined #gnuenterprise
*** jcater has joined #gnuenterprise
*** johannesV has quit IRC
*** SachaS has quit IRC
*** Vee has quit IRC
*** Vee has joined #gnuenterprise
*** SachaS has joined #gnuenterprise
*** SachaS has quit IRC
*** reinhard has joined #gnuenterprise
*** jcater has quit IRC
*** holycow has quit IRC
*** cilkay has quit IRC
<reinhard> jamest: not that i am aware of any solution to this
<reinhard> so please don't hold back your m4d cod1ng sk1llz
<jamest> s/m/s/
<jamest> i did #1
<jamest> i wish there was a way to get a handle to the trigger wrapper
<jamest> as now my form does
<jamest> if func() = "block1":
<jamest>   block1.foo.get()
<jamest> elif func() == "block2":
<jamest>   block2.foo.get()
<jamest> i'd rather do
<jamest> func().foo.get()
*** cilkay has joined #gnuenterprise
<reinhard> night all
*** reinhard has quit IRC
*** jcater has joined #gnuenterprise
*** holycow has joined #gnuenterprise
*** btami has quit IRC
*** sjc_ has joined #gnuenterprise
*** sjc has quit IRC
*** sjc_ has quit IRC
*** cilkay has quit IRC
*** sjc has joined #gnuenterprise
*** cilkay has joined #gnuenterprise
*** SachaS has joined #gnuenterprise
<kilo> hi SachaS
<SachaS> hi kilo, how are you?
*** jamest has left #gnuenterprise
<kilo> got to cure my cold with whisky
<SachaS> hehe
<kilo> and you?
*** jcater has quit IRC
<SachaS> me chatting away instead of working
<SachaS> at least its ebXML chat ;)
*** ajmitch_ has quit IRC
*** kilo has quit IRC
*** cilkay has quit IRC
*** ajmitch_ has joined #gnuenterprise
*** sjc has quit IRC
*** titopbs has joined #gnuenterprise
*** sjc has joined #gnuenterprise
*** cilkay has joined #gnuenterprise
*** titopbs has quit IRC
*** sjc has quit IRC
*** jamest has joined #gnuenterprise
*** titopbs has joined #gnuenterprise
*** jcater has joined #gnuenterprise
*** holycow has quit IRC
*** holycow has joined #gnuenterprise
*** nickr has quit IRC
*** nickr has joined #gnuenterprise
<chillywilly> hello
<chillywilly> ppl of the GNUe
*** wendall911 has left #gnuenterprise
<jcater> how now sir chilly
*** nickr has quit IRC
<chillywilly> my quest is long but my will endures
*** nickr has joined #gnuenterprise
<chillywilly> where do I get a cool hostmask like that?
<ajmitch_> give lots of $$
<jcater> to jcater
<ajmitch_> yes
*** jamest has quit IRC
*** jcater has quit IRC
*** titopbs has quit IRC
*** SachaS has quit IRC