*** reinhard has joined #gnuenterprise good morning all *** btami has joined #gnuenterprise good morning *** johannesV has joined #gnuenterprise good morning good morning derek, did you see the "time to go to bed" signal? ;) *** johannesV_ has joined #gnuenterprise ping pong ah, it's no longer ignoring me .... :) well then... reinhard, in the function create_execution_context you did something like: language = str(lang.lower()) *** johannesV has quit IRC yes that will cause problems if lang contains non-ascii unicode characters btw. what's the intention of that line ? as there's a preceeding checktype(lang, basestring) it converts unicode to string hm, is it using the default-encoding ? well and is that default-encoding the one which will fit ? valid values for language are ['python'] anyway :) yes, of course ... i think instead of doing isinstance(foo, types.MethodType) we could do: callable(foo) I don't think so a class instance might happen to be callable, too but i might want to have it in the namespace as an object ok *** weex has joined #gnuenterprise *** weex has left #gnuenterprise *** sacha is now known as SachaZzz SachaZzz: i did see it going to bed now :) *** yure has joined #gnuenterprise *** kilo has joined #gnuenterprise good morning *** sacha_ has joined #gnuenterprise *** SachaZzz has quit IRC *** btami has quit IRC *** dimas has quit IRC hm, reinhard ... have you thought about asserts being removed by optimization (which is done on installation) ? that would mean there's no check of the trigger-functions after installation GTriggerCore.py, line 106 for example and a construct like if set_function is not None: assert isinstance(set_function, types.MethodType) ends up as if set_function is not None: (the other part is removed by optimizer) that's ok IMHO it's gnue internal code e.g. from gnue-forms or gnue-reports ok *** jamest has joined #gnuenterprise good morning jamest morning I wonder whether you use manually created GTrigger instances (i.e. not defined in an XML file) no never funny GTrigger.__init__ provides a way to directly initialize with type, name, text, language which would only make sense at all if an instance is created manually just looked in the svn log it was like that from the very beginning I guess you also don't manually reassign other functions to existing triggers? with GTrigger.setFunction(...) i don't iirc we wanted triggers to be useful outside of xml files we've just never documented the feature so no one does it I'd image ok I am not sure if it would be easy to use triggers outside XML files anyway as much of the trigger code is tightly connected with GObj et al yes i think we went a bit over on depending upon GObj at times 'we'.... name someone to be blamed :) um isn't we the abbreviation for Derek? lol reinhard: one thing that might prove useful for would be unit testing indeed didn't you volunteer for that? j/k yeah, i'll do unit tests as I work on stuff they find bugs :) *** jcater has joined #gnuenterprise bbl *** kilo has left #gnuenterprise fwiw pylint cvs head now has per block enable/disable of msgs 1 class foo: 2 # pylint: disable-msg=W1234 3 def bar(self): 4 # pylint: disable-msg=W4321 5 pass 6 def gnurz(self): 7 pass that is cool yet ugly :) cool - that's exactly what I thought a few times that it would be helpful FWIW, I would really appreciate any testing/feedback regarding my changes in the trigger system *** yure has quit IRC reinhard: i can try some today *** derek has quit IRC *** sacha_ has quit IRC *** johannesV__ has joined #gnuenterprise *** johannesV_ has quit IRC *** johannesV__ has quit IRC *** derek has joined #gnuenterprise *** lupo__ has joined #gnuenterprise *** johannesV has joined #gnuenterprise bbl *** dimas has joined #gnuenterprise *** jcater has quit IRC *** jcater has joined #gnuenterprise *** ajmitch has quit IRC *** klasstek has joined #gnuenterprise *** ajmitch has joined #gnuenterprise *** sjc has joined #gnuenterprise *** jamest has quit IRC *** jamest has joined #gnuenterprise *** johannesV has quit IRC *** jamest has left #gnuenterprise *** klasstek has quit IRC *** jamest has joined #gnuenterprise I'm not sure if jamest and jcater will beat me if I now start to approach gnue-common/src/definitions however I stumbled across GBinary and GParserMultiplexor which both seem to not be used currently and I wonder if they have turned out to be dead end streets, or if there are some plans for them hmmmm GBinary is good GParserMultiplexor is dead both were for reports GBinary is a way to store images, etc, in an XML file it would save an icon or whatever resource in mime64 (or whatever) ok that's all I wanted to know for now :) thanks python's new-style classes would've done what I was going to do with GParserMultiplexor so even if I got back around to that, it'd be done differently ok so I could remove that? yeah (just to keep our source clean) I would like to understand the concept behind GObj and ParserObject or, more specifically where ParserObject ends and where GObj starts I can't see the logic behind the way things are put into the one or the other class (not implying in any way that there *is* no logic, I just can't see it) I'm someone sure that johannes did a lot of that split but I *think*, based on looking at it ParserObj is anything that could be represented by XML including GObjects, text content, and xml comments and GObjects are strictly objects that are of concern to a GNUe document I could be wrong about the johannes part but I know I didn't add code to track XML comments as I see no advantage to that I'm not sure if I answered your question or not ParserObject and GObj existed before johannes let me back up originally, I did do ParserObj and Gobj ParserObj just held code that was shared by GObj and GContent ah but it seems to have grown in scope which is what I meant by I think someone else has been in there ok now i understand FWIW I think the XML comments thing was done for designer being able to preserve comments? anyway jcater: while you're describing the whys of things :) I have been playing with the idea of extracting some stuff from there into a new class hierarchy that might be reusable for other stuff reinhard: one thing I would love to see like a very generic base class for a tree structure input masks go like this is the separation of the document structure and the document storage logic text -> tokens -> different tokens -> lexicon config jcater: please explain right now GObjects are really xml-centric from their creation to the way data is stored in them I've always envisioned GNUe supporting storage "formats" other than XML such as storing in a database table (and I don't just mean storing marshalled XML) but even if we never did support more than XML I'd like GObject creation in Python scripts to be a little cleaner ok * jcater does't have specific ideas at the moment as I havne't been in that frame of mind for a while let me describe what I've been thinking about I just remember thinking this when working on designer and maybe we will meet somewhere I toyed with the thought of * jamest will hold off about the tokens for a bit jamest: you can ask I'll just ignore like i always do 1. a base class for a tree structure, providing everything that deals with the tree structure in principle, like getParent, getChildren, children iterators, walk(), findParentOfType etc 2. derived from that, a class that adds XML on top of it, adding things like parser magic, dumpXML, namespace magic etc 3. on top of that, a class that adds in other stuff used in gnue, like triggers, namespaces, events 4. a GObj to remain compatible with the old structure 1 & 2 could be completely independent of the rest of gnue so it might match your goal by at least having all XML related issues in a single place and it might also match jamest's long term idea of "decoupling" gnue-common parts from each other *** sjc has quit IRC does that make any sense, or has it just been too long since I've been trout slapped? so a GFForm would subclass #3 which subclasses #2 which subclasses #1 ? (or it could subclass #4 until migrated to not need #4's deprecated features?) or am I missing how #1 and #2 interact? i'd thought about 1 at the least as gobj is bloated jcater: exactly what you said before the "or" okay including the "subclass #4 until migrated" and I'd think it usefull for the base of menus and such if we go this route I have a laundry list of things I wish were done differntly with GObjects but couldn't change as it'd break stuff heh (but you're proposing a migration object, so I can wish out loud now :) so you would not generally be opposed? ;-) no one thing I would LOVE please note that I'm just thinking out loud not saying that I will change no matter what comes :) that's why I'm seeking input right now, GObjs support both .attribute and ['attribute'] style access yep (like GFForm.name or GFForm['name']) I saw the comment it has for a while I use the latter one exclusively now abou you preferring to only support dict access as to me it seems cleaner then .whatever would be used to denote things GNUe-specific (like the walk, type, parent, etc) s/GNUe/GObj/ and we wouldn't have to resort to ._type, etc also 2) I'd like to see ._type changed I like the idea of distinguishing clearly between attributes from the XML and instance variables to be some simpler name GFForm._type should be 'form', not 'GFForm', imho I think what is _type now could be a class variable f every class right as we have ._type[2:] in far too many places containing the clean type it worries me how we seem to agree on very basic issues ;-) yes form not GFform as that requires hacks 3) I would like more integration of GParser's Attributes= and teh GObject init logic if the GParser definition says the default value of 'required' is False then if in python, I do GFForm() err form = GFForm() then form.required should be false no kidding next_state = (i, j, ks+1) I right now hold a piece of paper with a note saying exactly the same :) and 4) well I can better explain this through example than trying to describe it class GFForm(GObject): pages = GObjChildTracker('page') triggers = GObjChildTracker('trigger') hehe then if I have a myform variable I should be able to do either print myform.pages[0] or myform.page['name'] good bye, pageDictionary, triggerDictionary, blockDicitionary, datasourceDictionary etc? yes so that made sense? I like it very much all your points let me add another one most of these wishes came when I wrote designer as this will be a nice log for psu :-) I would like objects to be more "self-contained" and "self-defined" for example err I mean actually s/for example/specifically/ classes could have class variables defining what we now have in getXMLelements oh, also... on that ChildTracker, I'd prefer it to be dynamic, not an __init__ thing.. that way triggers could change/expand a document :) class GFBlock(GObject): _xml_description_ = u_("Block allowing access to data") that makes sense and is probably the only clean way to make my #3 work _xml_attributes = {....} etc right I'm not sure I'd want to use _xml_ as the prefix, but I definitely agree with the concept yes ok I agree on not using _xml_ because of the plan to allow for other concepts in future :) well, and it would keep designer cleaner as designer uses those attributes a lot that should make the G*Parser unnecessary in most cases I would imagine at least the huge arse dict yeah and I finally understand why the directory in gnue-common is named "definitions" instaead of "xmlparser" ;-) because it's how you "define" a gnue document :) * jamest thwaps jcater if I were writing it today, I would've probably called it "documents" instead of "definitions" but that's only because that's what they're known as in designer * jcater isn't saying we have to call the new thing that in this one function i have i, j, k, ks, p, t, c, st, and ns vars jamest: you should use better names than that! shame on you * jamest thwaps jcater again ok, so I'll go for that reinhard: just so you know the history of why things are the way they are will work on building that from bottom up (such as Parser not enforcing a lot of the things in the Definition) originally, GParser was very simple and loaded and XML file and created GObjects not much else but the definition dicts were expanded to include parent information, requirements, defaults, etc because designer needed that information but GParser was never updated to enforce what the definition dict listed (I fully intended to, just never got around to it) FWIW, with my proposals I don't want to criticise anybody or anything I adore what you have built up and I'm aware that it's a system that has grown probably grown much over what it was designed for from the start in many aspects /msg jcater i think you were on crack personally and I'm proud that I'm the one to get the honor of restructuring these aspects to be clean again :-) so no need for finding excuses for the current code ;-) reinhard: just be glad you weren't dealing with a lot of this stuff whne I started jamest/derek gave me cvs commit access and BOOM! yeah that was funny well reinhard: I committed all that GParser stuff on my first commit, iirc put them into a panic, to say the least if you would have told me that day that you and jamest would become good friends and BOOOM! i would have laughed you off the planet at that time, IIRC I was dealing with andrewm's geas code jcater: im not sure that ANYTHING worked after that first commit derek: all my forms worked fine rofl no matter what *you* did, but that wasn't much better I guess ;-) lol I'm so glad appserver is python/gnue-common based now oh, and for the logs cx_Oracle + Oracle Instant Client work under Mac OS X (in case anyone googles) damn... you know that my first message to gnue@gnu.org was in 1999? I'm getting old with gnue... *** lupo__ has left #gnuenterprise lol the irony is that this message was me offering to adapt the German localization of the GNUe ERP to the differences between German and Austrian law... so, how's that coming? * jcater ducks (the - in my expectation of course existing - German localization) jcater: :) I'm so glad appserver is python/gnue-common based now <--- are you sure? I would probably never have touched gnue-common otherwise ;-) well that is true the one crappy part of changing GParser is that I have quite a few projects inhouse that use GParser to create object trees that I haven't looked at in ages (but just work) I guess I'll learn how jamest feels when datasources get changed :) seriously, that might generate usable feedback if these projects turn out to become easiser, more straightforward with the new classes, the it's good yeah I don't mind rewriting them if things get more complicated with the new classes, we have wrong design decisions it's just identifying them that'll suck :) lol FWIW I've already tried to make a soft break for the "logic" changes i.e. gnue-common should be 100% compatible for now I have planned to add depreciation warnings for old stuff with gnue-common 0.7 and remove depreciated stuff with 0.8 which will be not earlier than in a year or two so people really have time to convert their apps s/people/jamest/ ;-) and to get back to your question lately, jcater I think common is really approaching a state that I think calling it 1.0 would be justified (after all these changes we talked about now, of course) FWIW, in case you didn't notice self in named triggers now works fine it's always the object that fired the trigger hmm and I think what jcater said should also work that you can use a typed trigger like a named trigger if you just assign it a "name" property but have not tested that, just can't think of any reason why it shouldn't work those two statements are incompatable at least based on what I was thinking wait nevermind, I need to back off the crack wait, or do I hmm just ask I'm trying to think thru it what I was originally thinking was say I have a block.on-update trigger that basically just updates a "total" field that is the sum of several other fields in that block but in some cases there might be another field in another block that affects that total right now, one would create a named trigger and assign that named trigger to the block.on-update and field.on-update what I was thinking in terms of however with triggers being either bound or unbound, but namable regardless is in this case, this is really a "block" trigger but something else, as an exception, needs to trigger it so the trigger would be on the block but given a name of updateTotal then you could also bind a the block2.field.on-update to use the same trigger yes but as far as the trigger is concerned when it is fired that's what I was thinkint too it is being fired "by" the block thinking you wouldn't use "self" in such a case except for maybe okay then what I'd also propose print "this trigger was fired by %s", repr(self) (this is what zope does) is have two global variables zope calls it container and context where container == the parent context = what you're calling self maybe we could do the same thing (but we don't have to use those names... we could use self + something else) what would you use the "container" for? in the example I gave above the container would be the block that the trigger is defined in as this would be, in your example, either the other GFBlock or, in case of the block firing the trigger, the GFLogic ah where it is *defined* the trigger itself would be a style yeah so "self" would depend on the caller and "container" would always be the same, depending on where in the xml structure the trigger is defined yes just the GTrigger._parent basicall basically I understand though I'm not 100% sure I they shouldn't be swapped :) self == what the trigger is "bound" to context == what is calling the trigger but I don't have hard feelings either way my definition of "self" was actually my interpretation of the wishlist item honestly, though, I think this may be why zope doesn't use "self" as the name to avoid such confusion bah it took me 3 hours to figure out how to allow for a trigger code to get a parameter named "self" without having a name clash :-) lol that's just me thinking ... I'm not the majority because __call__(self, *args, **params) dies a horrible death if **params contains a 'self', too (though in most cases everyone would be best served to just agree with me ... I'm usually right) one thing that comes to my mind regarding this anybody writing the trigger code *knows* where he puts it so if he puts the inside the he can easily just use "blkFoo.do_bar()" instead of "container.do_bar()" but if the trigger can be fired from different objects there is no way of finding out from where it was fired except for "self" (or "context") this makes me feel that the varaible providing the context is much more important than the variable providing the container I wasn't disputing the (relative) importance at all just questioning whether "self" has a loaded meaning and would confuse those beginning to code gnue triggers and it was an open question, not really a statement as I haven't thought it all the way through reinhard: something else to think about "self" might also be better served as an "event" container self.name could be the trigger name, self.action could be the event causing the trigger to fire (just throwing that thought out) ok the cool part about that is if you have code that needs to happen both on a pre-insert and a pre-update but only a few lines of the code is different you could do a: if self.action == 'Pre-Insert': # .... else: # ..... # The rest of the common code I actually don't care that much about this, I just wanted to implement "support for "self" in named trigger" from the good ol' ROADMAP.in file from gnue-common but that could just as well be served with another namespace variable I wonder if I added that? I think I could pretty much live with whatever you and jamest agree on and, FWIW, I agree that it makes sense to define/redefine the meaning of "self" *now*, before people start to use it :) jcater: it was added Dec 17 2002 by you :-) I often disagree with myself along with "Finish format mask driver system" and "Complete GMenu system" as goals for the upcoming 0.5 release :) ah, I was probably migrating from TODO to ROADMAP.in so I'm not sure who actually requested it wow, that was in 2002? ah, let me look how many years have I been on a gnue haitus? jcater: it doesn't appear on TODO before that 2001-04-09 23:26:25 Rev 944 jamest * src/GFForm.py, src/drivers/oracle/__init__.py, README.oracle, src/drivers/oracle/DBdriver.py, INSTALL, src/drivers/oracle: Added Jason Cater's Oracle driver for gnuef Added Jason Cater's patch to get rid of my Argh! error report :) and I think before you were referring to 2001-04-13 05:32:35 Rev 959 jcater * src/GParser.py, src/GFParser2.py: Rewrite of XML Parsing Code rev 959 is not bad considering that we're on 8439 now :) have I done anything meaningful since 2002-2003 though? :-/ meaningful in gnue, I mean I know I haven't done anything meaningful outside of gnue :) at least you updated the copyright headers every year j/k lol must get some sleep good night all *** reinhard has quit IRC *** derek has quit IRC *** jamest has quit IRC *** ajmitch__ has joined #gnuenterprise *** ajmitch_1 has joined #gnuenterprise *** ajmitch_1 has quit IRC *** ajmitch_1 has joined #gnuenterprise *** ajmitch has quit IRC *** ajmitch_1 is now known as ajmitch *** ajmitch__ has quit IRC *** derek has joined #gnuenterprise *** ajmitch__ has joined #gnuenterprise *** ajmitch has quit IRC *** ajmitch__ is now known as ajmitch *** ajmitch__ has joined #gnuenterprise *** ajmitch has quit IRC *** ajmitch__ is now known as ajmitch *** ajmitch__ has joined #gnuenterprise *** ajmitch has quit IRC *** ajmitch__ is now known as ajmitch *** ajmitch__ has joined #gnuenterprise *** ajmitch has quit IRC *** ajmitch has joined #gnuenterprise *** ajmitch__ has quit IRC *** sacha has joined #gnuenterprise *** ajmitch__ has joined #gnuenterprise *** ajmitch has quit IRC *** ajmitch__ is now known as ajmitch