After a long discussion about using pylint to help enforce coding standards for GNUe (and hence minimise the number of bugs), Reinhard Müller (reinhard) asked about trigger namespace, as previously discussed in . He had originally changed the code to require references to trigger objects in the current Form to be in the format 'formname.object()' or 'self.object()', rather than just 'object()'. But he had changed this back again pending further discussion, for fear of breaking all of James Thompson's (jamest) existing form designs. James said that, in forms that he had designed, he normally used the fully-qualified 'formname.object()' syntax anyway, not either 'self.object()' or 'object()' - he had found that these last two had proved problematical in the past. Reinhard noted any feedback welcome - I think nobody uses triggers as much as you do. James confessed i luvs my triggers.

The next day, Reinhard noted that self in named triggers now works fine - it's always the object that fired the trigger. Jason Cater (jcater) gave an example where the same trigger code might be fired from different objects in different blocks. Reinhard agreed that you wouldn't use "self" in such a case - except for maybe debugging-like purposes (i.e. to find out which object had called the trigger). Jason suggested using an idea from Zope, and having both self == what the trigger is "bound" to and context == what is calling the trigger. Reinhard felt 'self' might be better to refer to the object calling the trigger, not the object containing the trigger code - anybody writing the trigger code *knows* where he puts it but if the trigger can be fired from different objects - there is no way of finding out from where it was fired except by checking. Jason was not disputing that knowing what called the trigger was typically more important, he was just questioning whether "self" has a loaded meaning and would confuse those beginning to code gnue triggers.

Jason also noted that 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 have one block of trigger code that used self.action to find out why it had been called and branch accordingly.

The next day, James noted that in the old forms namespace - you could do a startup trigger that declared a global object and used it to import a module of trigger code, which was then available globally to any other trigger in the form. that no longer works - which will break a ton of stuff for me :) Reinhard said it actually works for me - I wonder, does your case invove any dialogs? As he wondered if James' problems could be a side-effect of when dialogs got their own global namespace.

Reinhard Müller (reinhard) asked I wonder whether you use manually created GTrigger instances - (i.e. not defined in an XML file such as a .gfd GNUe Form Definition or .grd GNUe Report definition), noting that 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. James Thompson (jamest) said that 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 imagine. Reinhard was 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. James noted that one possible use for triggers not in an XML file would be unit testing, as discussed in .

Reinhard Müller (reinhard) asked what the GBinary and GParserMultiplexor code in GNUe Common was for. Jason Cater (jcater) explained that GBinary is a way to store images, etc, in an XML file - it would save an icon or whatever resource in mime64 (or whatever) - for example, for use in GNUe Reports. However, GParserMultiplexor was now redundant - 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. Reinhard volunteered to remove this.

Reinhard Müller (reinhard) asked about the concept behind GObj and ParserObject - or, more specifically - where ParserObject ends and where GObj starts. Jason Cater (jcater) said that the basic principle was that 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. He clarified that originally ParserObj just held code that was shared by GObj and GContent - but it seems to have grown in scope since.

Reinhard explained that his reason for asking was that 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. Jason said that he would love to see the separation of the document structure and the document storage logic - right now GObjects are really xml-centric, from their creation to the way data is stored in them. But 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 and less XML-specific.

Reinhard explained what he had been thinking about - 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. He noted 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.

James Thompson (jamest) said that i'd thought about 1 at the least - as gobj is bloated - and I'd think it usefull for the base of menus and such. Reinhard noted that including item 4 would allow for backwards-compatability, at least in the medium term. Jason noted I have a laundry list of things I wish were done differntly with GObjects - but couldn't change as it'd break stuff - (but you're proposing a migration object, so I can wish out loud now :). Reinhard and Jason discussed some detailed tidying-up that they would like to do, now that breaking compatability with the old GObject was not an issue, finding that they had very similar ideas in most cases.

Reinhard added that he would like objects to be more "self-contained" and "self-defined", in that classes could have class variables defining what we now have in getXMLelements. Jason agreed - it would keep designer cleaner - as designer uses those attributes a lot. James felt that should make the G*Parser unnecessary in most cases I would imagine - at least the huge arse dict. Jason noted that 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). Reinhard fully appreciated that it's a system that has grown - probably grown much over what it was designed for from the start in many aspects - and I'm proud that I'm the one to get the honor of restructuring these aspects to be clean again.

Jason was so glad appserver is python/gnue-common based now, in line with the other GNUe Tools - it had originally been a stand-alone tool written in C. Reinhard asked are you sure? I would probably never have touched gnue-common otherwise ;-) Jason admitted that 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). Reinhard said that these might generate usable feedback - if these projects turn out to become easiser, more straightforward with the new classes, the it's good - if things get more complicated with the new classes, we have wrong design decisions. In any case, having a GObj to remain compatible with the old structure, as discussed above, should 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.

Following on from , Reinhard thought that 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).

James Thompson (jamest) asked if GNUe Forms was now validating the typecasts in fields as he was now getting an XML markup error - 'datetime' is not valid for typecast-attribute which allows these values only: 'Default', 'Description', 'ValueSet', 'Typecase', 'Label'. Johannes Vetter (johannesV) said this is because the options defined in a ValueSet will be checked now. James agreed, but said that the error message was wrong - the list of allowed values look more like gparse dict keys than a list of valid data types. Johannes found and fixed this bug.

Later, James noted that the list of valid data types was just date, text, number, adding i thought we did a datetime too. And what about boolean - i swore boolean worked?

Reinhard Müller (reinhard) asked if a trigger is defined within a <dialog>, what should "form" point to in your opinion? the main form, or the dialog? James Thompson (jamest) said it should point to the dialog form - all <dialog> is is an alias for <form type="dialog"> or some such. Reinhard noted that this would mean there would be no way to access the main form from within a dialog. James said that the proper way for a dialog box to communicate with the form that called it was via the activateDialog() function. This was so that dialogs would be self contained with a standard API. That way, the same dialog could easily be hooked into multiple forms if required.