Chad Walstrom said he had been asked to replace some Workshop and Visitors Management software at his workplace. He wanted to tap into an existing project and add my resources rather than reinvent the wheel and was therefore keen to use GNUe. However, The particulars of the master/detail relationship in GNUe Forms eludes me. He gave his sample schema for contact management, using four tables (person, person_addr, address and address_type), asking In highly relational databases, how do I represent these complex ideas in your forms?. Derek Neighbors said that THis almost exact example is in our samples, I think some code changes have broken it slightly, I have a fixed version I will check in very soon, but you can get the general gist of it from the sample. This included postgres scripts to create the tables, and Forms to access them. He had started to take this sample and replace its structs with real structs from DCL and to make a contact_manager that is fully compataiable with DCL for use by the Free Software Foundation (FSF). He was keen to try iron out a common spec as much as possible and have a unified contact manager to help burden work load if you are interested. Chad agreed - I can see where your tables could benefit from a bit more normalization, and some of my tables could benefit from being less generic. He suggested Sounds like a package is brewing grin.

On IRC, Derek Neighbors (dneighbo) explained at one time i was employed by a health and fitness club (gym/personal trainers/sauna/spa) outfit - i started to do their membership management stuff with gnue - as some of the early proof of concept stuff. This was the origin of the sample Contact Management forms, which he also used to track assignments for GNUe to FSF. When he started using DCL at work he really disliked how it handled contacts - i talked to mdean and he needed better contact support in dcl as well - so we rewrote a contact spec (data dictionary) and he and Michael Dean (mdean) were now in process of modifying DCL to use the new schema for contacts. Also, the FSF needed donor management and some tracking software - they have decided to use DCL and as part of that im making some GNUe screens for contact management that will have items to do donation management etc - that is part of the fsf-contacts project on savannah - the modified sql stuff and forms are in its cvs. He explained how to create a database schema for a specific database from the XML definitions using sablotron and pysablot.

Derek wondered about writing up the contact management work as a case study/tutorial. He wondered if there was any free software that had a way to screen capture all my screen/voice while i worked - so i could do a demo - and capture as digital and we could post on website.

Chad (^chewie) said he had written a schema for contact management as well - he had normalised the data into a person table, an address table and a person_address table to link the two together. He said the idea is that there's less duplication of address data but ease of mgmt should probably win out for a less normalized schema. Jason said we had a long discussion about that exact example. Derek agreed - what you gain is used to little that the overhead it puts on UI design - not only kills the developer but ultimately confuses the user. Chad said he had also tried having one table for all phone, url, email, etc named comm - i.e. person_comm table w/a lookup for comm_type. Derek said he had tried this too - i think i spread back out for a. uncomplicating b. helping with size hopefully helping speed.

Chad said The one thing I disagree with on the DCL schema is the separate tables for accounts v.s. contact v.s. personel. Derek agreed in part - i think they need to be separate tables - but all shoudl use contact - i.e. you only enter people in a contact table. Chad noted that the Company/account table also had address and phone number fields. Derek said that this was designed to allow for company changes of address as well as contact changes of address - one could say sure change the company address and all employees change - but in theory its more likely sally sue moves from the denver to the san francisco branch - some yo yo goes in and changes her contact record - and viola now the whole denver branch has moved to the san francisco branch. Good user interface design could reduce the chances of this, but then it goes back to the a. complexity b. less data in specialized tables = better performance. In practice, it depended how many of your contacts/accounts/whatever were individuals and how many were (possibly mutli-site) companies. He said i STRONGLY believe in normalization thats what RDBMS were designed for - but i believe there is such a thing as over normalization as well.

Chad asked so, if we go about packaging a Contact Management package/module for GNUe, how should we go about it?. Derek said we need a way to do like 'base' module with add-on's - i.e. dcl would usge gnue-crm base module and the fsf contact system would use gnue-crm base model - for now i have basically been doing duplicate work :(. He was keen to start defining an "official" GNUe CRM package - the problem is to do that we need to probably use the module proposal template yada yada yada and put out for review and such - which is great and i want to do that, but i have time constraints for FSF - so im torn.

Later, Chad summarised the problem with address normalisation in databases - we were discussing the idea that an address record shared between personal and the company benefit from being edited once and changed everywhere, but if the UI is designed under the presumption that data is atonomous of eachother, then someone could open up the editor and change the data incorrectly. Possible solutions were:

Jason said that a proper normalised solution meant that users needed to understand when to change the id, or when to change an address - and that is a tall order - /me has had this problem - repeatedly :(. Daniel Baumann (chillywilly) assertively suggested I see, so you want to make this more friendly to clueless people ;). Derek said if you have a rule that says the user can change the address BUT if the address belongs to more than one person it throws a message (hey dummy this is a shared address by X people) then either a. the user doesnt care and just hits ok b. the user panics and clicks no and tells the customer, sorry i cant change your address c. they create the new address (when there is no need). In practice, shared addresses should be the EXCEPTION not the rule.

Two days later Chad came up with another argument FOR normalized databases - they can actually reduce the number of dialogs/forms you need to create to enter data. Jason Cater (jcater) said nobody argued against normalization iirc - only the level of normalization. Chad agreed - it's just that the relationships between those forms are slightly more complicated.

Jan Ischebeck suggested names of tables and columnns should be quoted to allow names to contain a) special characters and b) non-ascii characters c) reserved words. This would make the forms client a bit more flexible in case of special fieldnames and special (non 100% ANSI SQL conform) data types (like the POSTGRESQL Numeric == Float issuse), as discussed in . However, Reinhard Müller pointed out not all DB backends support quoting (e.g. MySQL).

Derek Neighbors said that foreign key (FK) support in Forms was confusing - instead of <entry field="type_id" name="inpType" style="dropdown" width="10" x="11" y="5" foreign_key="dtsEvent_type.id" foreign_key_description="name"/> the syntax should be <entry field="type_id" name="inpType" style="dropdown" width="10" x="11" y="5" fk_datasource="dtsEvent_type" fk_key="id" fk_description="name"/> . The foreign key data source could then be selected in the Designer module. Jason Cater said I am fine with that. I always have to refer to a sample to remember the syntax, anyway :) However, to be consistent with other references to datasources, it may be better to have fk_source="" instead of fk_datasource. Derek agreed - Im not worried about naming, just moving the source to attribute regardless of what we call it..

Jason Cater (jcater) noted someone here suggested we do a wiki - /me is half-tempted to do that. Derek Neighbors (dneighbo) said he hates wiki, but i suppose like all things i would get used to it. Jason said well, I'm not big on it - but it might jump-start better documentation - as in, it makes it real easy for other ppl to contribute. Derek though it was better to fix docs than enter wiki info - and if its bug stuff it belongs in dcl and not wiki. Jason agreed if one of us are doing something doc related - then definitely do it properly in cvs.

Two days later, Peter Sullivan (psu) suggested that the #gnuenterprise IRC channel (plus the Kernel Cousins summaries) pretty much give us what we would get from a wikki anywya. The problem was that the more channels of comm we have the thinner they get spread - and the more work is involved in keeping an overall picture of the project. He said he actually likes the concept of wikki and is wondering about using it for project at work - not sure if it is a good fit for our org culture, however. Later, Nicholas Lee (esands) gave some web site references about How to Get Internal Buy In for TWiki and TWiki Sucess Stories.

Chad Walstrom, following through his own logic from , said that at the moment, users had to find foreign key values themselves and enter them. I would like to give them something that is a bit more user-friendly. It may be something as simple as a [SEARCH] button next to each input field that launches the appropriate search form. The trick is being able to populate the field with the result of the search. I know that triggers will be involved, but how would I go about something like this?.

Derek Neighbors (derek) said that converting a simple database with three main tables was probably a day of work. When challenged, he asked for the schema to be posted to him and had a look. Within a few minutes, he had written a form to look at the data, using the Designer wizard, and then cleaned it up by hand-editing. You needed to to check the connections.conf file, then make sure that he had a postgreSQL driver installed - i prefer pyscopg - but thast on debian - there were other alternatives that should also work if Red Hat used something different.

Derek asked can you give a screen shot of their working application? The application being converted needed Netscape 4.7x to access it, as it made heavy use of javascript. Derek found a copy of Netscape® Communicator 4.72 on a spare box, but this did not work. After a quick upgrade to 4.77, he logged in and had a look around. He concluded btw: i still dont think this is much more than a day or so work - he thought it was a pretty slick little environment. If they wanted to keep the application web-based rather than use the full-client GNUe Forms written in python, its quite possible the phpForms client would handle it - there is a demo on the gnue site.

Derek posted a simple sample form to show how the conversion would work - you will definitely need master/detail and foreign key entries for a full solution, but the other tables werent there to do that in the sample data he had.

To convert the tables from Sybase to PostgreSQL quickly, we have an xml schema for databases i.e. you define a database in XML - then use XSL and it creates the create_db.sql type file for any supported database. There was a sample output on the website, and the actual code was in DCL's CVS. This was useful not just within GNUe, but to anyone wanting to make create/insert scripts for more than one db - but not maintain files for every db vendor - and get a nice documented html file as well. At the moment, there was no way to automatically convert from a specific database to create the XML schema in the first place, but he had discussed doing this using common's drivers and introspection.

Marius Gedminas (mgedmin) asked is it possible to open a second form on a button click? He remembered seeing this discussed before - there were two solutions -- os.system() and some trigger/event/whatever. Andrew Mitchell (ajmitch) suggested maybe look at navigator code to see how it opens form, implement that in triggers? Navigator had got quite a bit better lately - it had not been included in the 0.3.0 group release but it's got a bit of luvin since then, as discussed in . Marius reported gnue-navigator uses the os.system("gnue-forms %s") approach. Jan Ischebeck (siesel) said for the other approach you have to look in UIwxpython.py. Marius asked can I do that in a trigger script? Andrew said you could try :) - looks like you have to tell it to parse form too - seems almost too simple... ;). Marius agreed - only 50 lines of Python code ;). Jan said there is a trigger solution too: look in forms/samples/location/forms/runform.gfd. Arturas Kriukovas (Arturas) noted this does open a new form, but is it possible to avoid that request window to enter username\password for the database? Jan said that Navigator did this - this code could be reused in the runforms method, or extracted to a separate function that both runforms and Navigator could use.

It was asked if GNUe supported grid widgets. Derek Neighbors (dneighbo) said well current we have highly portable home made grid widgets which were used by setting a rows="" attribute. Eventually we will with wxGrids as well - which will be no more functional, just prettier. Scrolling was not yet supported, but Marcos Dione (StyXman) was beefing up scrollbar support as discussed in . However, you can scroll with keys - so its not like its not usable - and with mouse you can do so as well - by the navigation bar for records. There was no reason why you could not troll through a grid to find record to edit - and that record shows up in a pretty half of the form for editing, but he was not sure that was ideal from a UI (user interface) perspective. James Thompson (jamest) said you can setup master/detail blocks w/ detail displaying same data as master but read only fields - i do that here - so that the editable part shows a school - and a rows= block shows all schools in that zipcode including the school above.

Keith Jagrs (Keith_Jagrs) asked are there any other Open Source ERP projects ongoing? besides gnuenterprise? Sacha Schlegel (SachaS) pointed to a web page that has some infos on finance applications on linux etc - might be a bit outdated but .... gives you some pointers. Keith asked How far do you think is GNUe to be an option like SAP, JDedwards and other ERP software? Sacha said this was the intention, but i guess you have to wait a couple of months, years or help yourself to boost it.

Marcos Dione posted a revised patch to support adds mainmenubar, maintoolbar and the new widget: scrollbox. He noted that the scrollwidget has the ability of containing widgets. which means that widgets declared inside <scrollbox> tags will be drawn *inside* the scrollbox (as one would expect). Co-ordinates of contained widgets were relative to the scrollbox left upper corner, and not the window's one.. He wonder if it would make sense for the <box> widget should also be a container - that would allow to make (I think) more modular forms. Jason Cater said he liked the concept of containers. However, he was worried about how user interfaces other than wxWindows would support scrollboxes - ideally, Forms definitions should be renderable in any supported UI. Marcos said that scrollboxes were not really wx-specific. A curses (text-only) version of the scrollbox might take some work, but the html can be easily be done with IFRAME. that allows you to show pages inside pages in a more flexible way than FRAME and more like this scrollbox thing does.

Later, Aditya Gilra raised some other problems with GNUe Forms. Derek Neighbors urged people to raise bugs via the productname-support@gnuenterprise.org e-mail addresses, as There are now so many developers, feature requests and bug submittal's it is too hard to address via email. He raised Aditya's bugs in DCL. Aditya also asked about developer documentation. Derek said In all the tools there is a directory called docs/ you can usually find goodies in there, docs, patches and the likes are always greatly appreciated. :).

Aditya Gilra attatched some files that allow us in India to enter data in Hindi (forms driver), which should work for a lot more locales.. He explained that wxWindows did not support the various context dependent ligatures required to display Hindi since it is based on gtk 1.2. However, gtk 2.0 uses pango 1.0 which renders Hindi quite well. Until wxgtk is based on gtk 2.0, we need to use pygtk2.0 (1.99.10) to be able to enter Hindi.. Therefore, I'm using utf-8 throughout - in database and in forms and in the ui driver. It's the easiest for Hindi as it is requires no modifications in postgresql and very simple modifications in forms.

Marius Gedminas (mgedmin) reported problems trying to use boolean fields in PostgreSQL with check boxes in GNUe Forms. Adding a boolean field to the form meant that it was being used in the WHERE clause for update queries, as discussed in However, comparing a boolean value 0/1 is not supported by PostgreSQL. He was getting similar problems with date/time fields, but with DATETIME it works for some records and fails for others. John Lenton (Chipaca) noted that PostgreSQL was very sensitive as to how numeric values were quoted - he suggested use 'true' and 'false' instead, by editing the checkboxTrueValue in gnue.conf. Marius said he would try this - problem is that it gets the value as 0 or 1 from the db - puts it into a text entry field - then tries to store it back. Later, Marius summarised 1. updating a boolean field through a checkbox does not work due to UI issues - 2. updating a boolean field through a text entry does not work because of typecasting issues. However, this latter problem was because of my fixes sigh, which he went on to re-fix. John felt that it was PostgreSQL that was at fault, not Marius' code.

Some days later, John Lenton (Chipaca) asked is there a 'cleaner' way to query the value of a field in the current recordset other than <datasource>._object._currentResultSet.current.getField('<field>') ? James Thompson (jamest) said not that I recall but it would be easy to extend the trigger namespace - and I did add a simpleQuery() to it - that returns a a list of dictionaries - based upon a query mask. John asked for more details, saying he was hacking a button to behave like a checkbox. James said we need to just fix the !@#!@ checkboxes :) - biggest problem there is how to handle queries - as a checkbox needs three states in a query. John agreed but noted checkboxes work in the query part, it seems to be the UI<=>data bid that fais. I mean, it displays whether the database has a 'y' or 'n' correctly with a check or no check - and I can change it from checked to unchecked no problem - it's that checkin/unchecking that never reaches the data.

Jason Cater (jcater) announced that he was branching CVS today for 0.3.x stable branch for Forms, Designer and Common if no one has any objections (we have too many feature requests in DCL now :( Derek Neighbors (dneighbo) agreed - he would like to see DCL organised so that tickets for bugs stayed as tickets, but tickets for new features were assigned as work orders. This would help to make it clear what needed to be applied to which branch in CVS. He also thought we need to go to model of NO cvs commit is done without a DIRECT reference to a ticket or a workorder. Jason agreed but only for the stable branches - at least for now. Derek said i think for everything - as we really need better roadmaps and planning, using DCL as the 'todo' list. Jason said there was no need to branch the tools (such as AppServer and Reports) that were still at version 0.0.1. Derek agreed.

Derek Neighbors (dneighbo) asked about problems he was having with the CSV (Comma Separated Values) upload into DCL - i put same code i do elsewhere for uploads and for whatever reason php behaves differently. He basically had to verify if file was coming from http upload or if file name was being 'spoofed' - i fixed everywhere except workorder csv uploads - as it appeared to be being 'spoofed' even when not 'spoofing'. Michael Dean (mdean) asked I thought the is_upload_file (or whatever) was available in version 3 of php? Derek said it was only available in like 3.0.17 or something (a rather new version) - i figured if the other method was just as valid, but would work on ANY version we were better off using that. Michael said that anything older than 3.0.18 has some security holes, IIRC and was hence depreciated. Derek said he would try it again the other way.

Jason Cater (jcater) liked the idea of being able to do bulk uploads into DCL - /me needs to try that out. Derek said its how i planned to give FSF command line batch process. Derek and Michael did some more debugging on the spoof protection part of the code.

Continuing , Marcos Dione said he thought that scrollboxes are the first step to make a good grid available. and are generic enough to support other specific requirements, like forms that would not fit in one screen (think in curses). Derek suggested a more generic solution of containers of some sort or bind to a block. I think concept is right and that we need scrollbars to bind so that we can do a 'grid'. Marcos suggested that a generic container widget that could have the scrollbar switched on or off on demand might be better. Jason Cater felt this was the wrong approach. He liked introducing container elements to ease importing. However, he felt that the current suggestion would break existing forms, and (more importantly) 3 is very GUI specific and has no place in our forms definitions.

Andrew Mitchell asked what issues will you have with methods that fall under different licenses to the GNU Public License (GPL) that GNUe Application Server was licensed under? Reinhard Müller (reinhard) said that the GNUe applications would not use any methods that were not GPL. If other companies wanted to write, sell and distribute applications using the Applications Server under different licences, that would be ok - however we would of course recommend to release GNUe apps under a free license. In any case, it could be hard to write "closed-source" software in python, as it is an interpreted language :). Andrew said that people could compile to bytecode. Jan Ischebeck (siesel) asked whether is bytecode compatible over different python versions?. Andrew said i think it can be, just not sure.

Charlie Navarro (yogurt2unge) said he had been working with the GNUe DTD (XML Document Type Definition) and discovered a few errors. James Thompson (jamest) confirmed that the DTD isn't in use yet. Jason Cater (jcater) said gnuedtd is a hack script that isn't actually supported - it's something I did overnight - I think it has an infinite loop issue hat I haven't had a chance to look at. Charlie supported the idea of using a DTD.

Alejandro Pronotti (aprono) asked where to set the username to test appserver example?. Reinhard Müller (reinhard) said that, as of time of writing, the default username is your login name you started appserver with - i think when starting test.py directly you have some options. You could also change the source code to hard-wire the user name directly. Later, he confirmed that test/test is username/password to log into the appserver for the test example.

Earlier, Reinhard said that Jan Ischebeck's (siesel) geasAuthAgent code was much like what i was thinking about - but i believe we need something more flexible - not only access to tables/classes - but also access to fields, methods - and maybe even to instances depending on conditions. Jan said his proposal was just for the "SIMPLE" auth agent for geas 0.0.4 or so - further functionality could be added later. Reinhard agreed, as did Derek Neighbors, who said role based access control should be high priority just not immediately :), referring to the proposals already done in this area by Stan Klein (sklein) and Michael Dean (mdean).

Earlier, Reinhard asked btw could it be this auth stuff breaks test.py? Jan re-tested it, and noted its quite strange, it works if I'm in the appserver directory but if I'm out it stops working. Later, he confirmed if I remeber right test.py uses a default authAgent which lets everybody in.. Earlier, he said that the next big step will be that GEOR stuff I think, to start implementing the GNUe Object Repository within AppServer.

Jan Ischebeck (siesel) summed up Derek Neighbors' (dneighbo) short-term goals for an initial non-object orientated Application Server, as previously discussed in and other occasions, saying for that we should 1. define a new XML format for appserver triggers and table descriptions 2. a GParser tranforming files like this into an object tree 3. GTrigger objects in that object tree listening to events on 4. GDatasource/GField objects also in the object tree.. Reinhard Müller (reinhard) felt that we shouldn't _base_ appserver on that xml stuff - like forms is totally based on the xml - because i am 100% positive we will support other formats of object definitions than xml. Jan agreed but if we want to use GTrigger from common without many modifications we have to go that way. Reinhard said that trigger definitions (and later object definitions) should be a separate module, in order to allow a more dynamic approach instead of just using static XML file definitions. Daniel Baumann (chillywilly) suggested using ODL (Object Definition Languague) as the basis - you can make some xml markup based on it or support it outright.

Sukotjo S. Bambang reported a problem with GEAS - I have always get a message error UUID header.. Reinhard Müller said that The geas package is obsolete, noting The appserver package replaces geas..

On IRC, Reinhard asked is it possible to remove geas tarballs from the download section? Derek Neighbors (derek) said it would be nice to get it out of cvs some how too - well i would like to keep it in cvs just somewhere where it doesnt get downloaded with cvs update or cvs co of gnue - only to lessen the bloat of cvs (i would like to have docs be separate module as well). Reinhard said for now i added some comments to README and autogen.sh that one shouldn't try to build this program - my concern is not primarly bloat of cvs but the regular questions on the mailing list.