GNUe Traffic #34 For 22 Jun 2002

"mommy im gonna cry - i had to click a license agreement - you know how long its been since i did that?" - "uh-oh. you probably agreed to be Steve Case's towelboy"

This Cousin covers the three main mailing lists for the GNU Enterprise project, gnue, gnue-dev and gnue-announce. It also covers the #gnuenterprise IRC channel. A great deal of development discussion for this project goes on in IRC. You can find #gnuenterprise on irc.openprojects.net:6667, or you can review the logs. For more information about the GNU Enterprise project, see their home page at http://www.gnuenterprise.org.

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:

even though the DB is normalized, you never let people share records between themselves or between companies
implement a before-commit trigger that counts references to a given address record and confirm with the user that it will indeed change for a number of users
de-normalize the database

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 Issue #33, Section #12 (9 Jun 2002: Problems with floating point fields in PostgreSQL) . 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 Issue #34, Section #1 (11 Jun 2002: Normalisation for Contact Management in GNUe/DCL) , 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 Issue #33, Section #5 (5 Jun 2002: GNUe Navigator development and testing) . 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 Issue #33, Section #15 (9 Jun 2002: Scrollbars for grids) . 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 Issue #33, Section #12 (9 Jun 2002: Problems with floating point fields in PostgreSQL) 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 Issue #34, Section #10 (14 Jun 2002: Scrollboxes and other queries) , 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 Issue #12, Section #4 (11 Jan 2002: GNUe Application Server meta-discussions) 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.


Kernel Traffic Latest \| Archives \| People \| Topics	Wine Latest \| Archives \| People \| Topics	GNUe Latest \| Archives \| People \| Topics
Czech

1.	11 Jun 2002 - 12 Jun 2002	(6 posts)	Normalisation for Contact Management in GNUe/DCL
2.	12 Jun 2002 - 13 Jun 2002	(3 posts)	Quoting table names in SQL queries
3.	12 Jun 2002 - 13 Jun 2002	(3 posts)	Foreign Key support in Forms
4.	11 Jun 2002 - 13 Jun 2002		WikiWiki for GNUe
5.	13 Jun 2002	(1 post)	Auto-populating look up fields in Forms
6.	12 Jun 2002		Converting applications to GNUe
7.	12 Jun 2002		Opening one form from within another
8.	12 Jun 2002		Grid support in GNUe Forms
9.	12 Jun 2002		'Open source' alternatives to GNUe
10.	14 Jun 2002	(5 posts)	Scrollboxes and other queries
11.	14 Jun 2002	(1 post)	Hindi support in Forms
12.	13 Jun 2002		Problems with PostgreSQL booleans using Forms checkboxes
13.	14 Jun 2002		Branching CVS to split bug fixes and new features
14.	16 Jun 2002		Loading CSV files into DCL
15.	18 Jun 2002	(4 posts)	Container widgets in Forms
16.	17 Jun 2002		License issues for applications using GNUe Application Server
17.	17 Jun 2002		DTD for GNUe XML
18.	17 Jun 2002		Login and security in Application Server
19.	17 Jun 2002		Using XML for Application Server definition files
20.	19 Jun 2002 - 18 Jun 2002	(2 posts)	Old GEAS (GNUe Application Server) now obsolete

GNUe Traffic #34 For 22 Jun 2002

By Peter Sullivan