GNUe Traffic #69 For 22 Feb 2003 Editor: Peter Sullivan By Arturas Kriukovas and Peter Sullivan "/me thinks possibly the only thing more daunting than configuring oracle is uninstalling microsoft internet explorer from windows" - "isn't that done by installing linux?" Table Of Contents * Standard Format * Text Format * XML Source * Introduction * Threads Covered 1. 12 Feb 2003 How User Interface drivers interact with Forms 2. 15 Feb 2003 HTML User Interface for Forms 3. 16 Feb 2003 Stock Keeping Units 4. 17 Feb 2003 Improvements to Common 5. 18 Feb 2003 Using wikiwikiweb in DCL 6. 19 Feb 2003 Converting GNUe Small Business to use CVS (0.5.x) version of Forms Introduction This Cousin covers the three main mailing lists for the GNU Enterprise (http:// www.gnuenterprise.org) project, plus the #gnuenterprise IRC channel. Kernel Cousins GNUe is now group-authored: if you'd like to join the team, let us know (mailto:psu@burdonvale.co.uk) 1. How User Interface drivers interact with Forms 12 Feb 2003 Archive Link: "[IRC] 12 Feb 2003" Summary By Arturas Kriukovas Topics: Forms People: James Thompson, Tor-Einar Skog, Jan Ischebeck, Jeff Bailey Tor-Einar Skog (treinar) was interested in the status of HTML/Java interfaces. James Thompson (jamest) explained that Jeff Bailey (jbailey) "was, at one time, working on an html based forms interface. I haven't heard anything about it lately and I think he was going to work on the gtk2 dirvers this week so the html one may be backburnerd" . Also, Jan Ischebeck (sisel) "IIRC correctly had the start of a system using html/php then started messing with javascript/html driver again, i think it's on hold, so I think there are several non-complete drivers created already. It would be nice to have a completed one :)" . Tor-Einar said he would "attempt to do the HTML Interface in Python, outputting HTML/JavaScript" . James offered a short introduction on forms (the display engine) UI system: "forms uses a driver to provide a ui specific interface. That interface is really just a dumb window into what I call a virtual form so if the user presses a key, the ui driver sends back a request to the virtual form saying "interface has requested an 'a' be added to the current entry". The virtual form can ignore the request, convert it to something else, basically do whatever it wants. If it decides to honor the request then it sends the ui back an event that says "this field now contains ". Basically all the input validation is done outside the user interface. It would be ideal if the html interface was tied into the same virtual form. I realize that the individual keystrokes cannot be sent back in real time that the form would be passed back all at once." Tor-Einar thought the "python script would obviously have to parse your XML file, and maintain the connection to the database somehow." James said parsing XML file would result in duplicating a lot of functionality and told he would "try and write a UI driver that works with the existing forms backend. Forms is designed to have any type of UI put in front of it. We're even talking about a touch tone phone interface, however the ui drivers that were working up to this point have been wx(gtk) and curses" . Tor-Einar also asked about the status of Java Interface (old Java forms). James informed that "it's dead as far as I know. I'd say you could just start working on them. Gnue-forms is a reference implementation. People are welcome to reimplement in anything they want, however reimplementing forms in another language is going to be a major undertaking." 2. HTML User Interface for Forms 15 Feb 2003 Archive Link: "[IRC] 15 Feb 2003" Summary By Arturas Kriukovas Topics: Forms People: Rob Adamson, Peter Sullivan, Jeff Bailey, James Thompson Rob Adamson (bobacus) asked what people could "recommend for rapidly producing html forms that access a database? Has anyone tried running gune-forms in the IE with the ActiveX Python control?" Peter Sullivan (psu) explained "there have been several "false starts" with an HTML client - java, javascript, php, but the best way forward is to write an HTML UI plug in that works the same as the wxPython, curses, GTK plug ins i.e. uses as much of the normal forms client as poss. Main issue is that no-one has really had an "itch to scratch" in this area, so no real progress so far. http://www.gnuenterprise.org/~jcater/ HTMLClient.txt> (http://www.gnuenterprise.org/~jcater/HTMLClient.txt) represents one of our core developer's thoughts. If you have the interest/ enthusiasm, and at least some knowledge of python I'm sure that getting a GNUe HTML UI up should be easier than home-brewing something as you have the whole of this channel to help you and it would be a "big win" for GNUe as well, and easier for you as you have all the rest of the GNUe infrastrcture (e.g. the database access and other groovy stuff in GNUe Common) rather than start from scratch." Jeff Bailey (jbailey) said he was "still harrassing" James Thompson (jamest) "about the pieces I need for the HTML ui, although is someone wanted to dive in, I woudl cheerfully step aside. There's a few important pieces: 1) There's no concept in HTML of a fixed grid layout. You can use the fUgly hack that is in phpforms, but you lose all accessiblity, and basically don't respect the medium you're on. 2) To maintain good accessiblity, the labels need to be associated somehow with the input box. While HTML will be handy for people not wanting to use a client, I don't think it should be designed with PCs in mind, but more designed for the palmtop market. So, for inventory control and stuff, where the user would want to edit the form on a cellphone or other such portable, low screen quality device. Also, notably small screen. I also see the HTML UI being ideal for complying with the US (I can't remember which statute) requirements for accessibility. Because HTML degrades gracefully (when done right), it's ideal for large print, brail terminals, screen readers, etc." Rob noticed that "HTML would also be useful where the users are running computers not under the control of the sysadmins - e.g. external services." Jeff thought "ideally the forms client in general should be small and lightweight enough that someone could double client on an icon in a 'run from this localtion' type of deal and have it DTRT." Rob added - "Ideally a gnue forms client would come as standard in windoze :) But basically *my* use of an html/web gnue forms client would be to simplify providing web access to a few facilities - I would be using it as a tool for a custom app rather than as part of a ERP package" . "Basically we have a custom database-driven network management system, and the network is used by students in their bedrooms, and is hence an unusual system, and we try and to our utmost to automate the common stuff to cut down on the number of requests to deal with manually so the usage of this web interface is going to be fairly light." Peter offered other solution - "if the end-users are at all computer literate" just "use the "normal" Forms client as you could just take the normal *.exe install file include the forms definitions in it" . Rob asked was "there a forms client for Apple Macs?" So Peter answered - "the main forms client should work on Macs too, as wxPython is platform independant. I know there have been some discussions on the mail lists that suggest the "should" may be a bit fuxxy at the moment." Rob thought: "I'll need a mediator between the client and database, because users must only be able to view records about their own computers. I could put this in triggers/validation rules on a hypothetical server-based form, or use appserver" . Jeff said if he wants "to do this soon, a server-based form is probably a better bet." No one had yet started coding such a UI - Jeff spent a lot of time thinking about it and was going over code with James Thompson. 3. Stock Keeping Units 16 Feb 2003 Archive Link: "[IRC] 16 Feb 2003" Summary By Peter Sullivan Topics: Small Business People: Dan Bethe, Derek Neighbors, Mike Vincent Dan Bethe (dtm) asked "is there a value and a possibility in" structuring the Stock Keeping Units "like this: [seller] [client] [manager] [category1] [category2] [category3] [category4] [item] - with a numerical value per column of like 2-6 digits each" . He wondered "am i thinking about this too newbishly? maybe an SKU's only job is to be unique, not to structurally identify everything. maybe that's just what database fields are for, and the SKU can be built from here, checked to see if it's unique, and then used?" Derek Neighbors, referring back to Issue #63, Section #2 (3 Jan 2003: SKUs in GNUe Small Business) , said "gnue-sb will do this - you will have like set of categories that 'build' a sku - you could tailor this to whatever need you like" . Dan said his question was more generic - "right now i'm just defining my SKU format, period. so regardless of what generates it (human or any given app), i wanna know that i'm not overloading or underloading the concept of an SKU" . Derek was not "a fan of smart numbers personally - but lots of people like them - i dont like them because like all things they degrade over time" . Also, "the larger a sku is the harder it becomes to memorize, the less productive it becomes to enter it etc" . Using a structured number as Dan suggested could easily end up with "a 20 digit sku - 8 digit sku is more optimal" . Also, as the physical reality of your organisation changed over time (e.g. now more than 100 branches), these kind of "smart" numbers would break "and we stasrt to make 'exceptions'" . He felt it was "acceptable to do smart numbers if you dont fully rely on them - that is you dont write reports based on them and such - for example its nice to select items and let it build you a SKU but once i sku is made if you change the elments i wouldnt have it auto change the sku" . Mike Vincent (Vee2d2) found "intelligent SKU systems interesting.. just keep it as small as you can.. particularly if you're working with these numbers in the real world" . He had used several different SKU numbering systems, but felt the easiest to use was where "everything was converted to an 8 digit (semi) serialized number.. I say (semi) because as they created new products, etc.. they tried to maintain some order so that you could say products in the range of xxxxxxxx-xxxxxxxx were 'this kind' and .. etc.." He felt "15 digits is too large a number to work with.. "Joe Hourly, go cycle count #123456845445578 and #931484453612354" - or.. "BigCo, Inc. can I take your order?".. "Yes, I need to order 5000 #456512313843134's" etc.." Dan said "so it's very much a human interface thing" . Derek said that was why he preferred SKUs that were "8 or smaller" . 4. Improvements to Common 17 Feb 2003 Archive Link: "[IRC] 17 Feb 2003" Summary By Arturas Kriukovas Topics: Common, Application Server People: Jason Cater, Derek Neighbors Derek Neighbors (derek) asked Jason Cater (jcater) what was he doing in common. Jason explained - "preparatory organization" . Part of the 0.5.0 release of common would include several simplifications of datasources (simplification from the end user). "We started focusing on dbdriver reorganization, but decided to group all of common as the root dir of common was getting unweildy" . Instead of having: _pgsql/ postgresql/ psycopg/ popy/ this would be: postgresql/ Base/ Schema popy/ psycopg/ The schema discovery and creation logic would be kept out of the individual drivers so that it could be used without loading a driver. Also connections.conf would be simplified for the end user. The following 3 entries would be the same: # Use the first-available PostgreSQL driver [gnue] provider=postgresql # Use psycopg (slow-loading method, but backwards compatable) [gnue] provider=psycopg # Use psycopg (fast-loading/preferred method) [gnue] provider=postgresql/psycopg "The first one loads any installed dbdriver (psycopg, popy, pgsql), the next two specifically load psycopg. We can also go one step further and add a behavior=..... tag" : # Use ODBC with a PostgreSQL personality [gnue] provider=odbc behavior=postgresql # Use DB2 with the v5-style metadata [gnue] provider=db2 behavior=db2/v5 "you can associate vendor-specific schema stuff w/general odbc drivers or if a particular vendor changed their schema stuff, we can subversion w/in the driver tree, e.g., Oracle v6 is different than Oracle v7-9" . 5. Using wikiwikiweb in DCL 18 Feb 2003 Archive Link: "[IRC] 18 Feb 2003" Summary By Peter Sullivan Topics: DCL, Small Business, Customer Relations, Document Store People: Jeff Bailey, Derek Neighbors Jeff Bailey (jbailey) asked about "Integrating a wiki into" a combination of Customer Relationship Management and DCL (Double Chocco Latte, GNUe's task management tool. Derek Neighbors (revDeke) said "DCL / CRM combo is right around the corner - the CRM stuff in" GNUe Small Business (gnue-sb) "uses the table structs from DCL account/contact tables for dcl 1.0" , which he had further plans for. He thought trying to link this to a wiki was a bad idea, but recognised that he "personally doesnt like wiki too much (which is probably some of it)" . However, "with some modifications" you could do much of this from within DCL, using the "email and/or web interfaces to a customer. For example right now i can send an email and a ticket is created - the part that doesnt happen is the ability for me to communicate back to you via that ticket" This was a common feature request which would be added soon. Jeff said "The thing that the wiki brings is a free form place where people can write documentation. Documentation both on troubleshooting steps, as well as documentation on internal servers and stuff. The thing I was thinking of was that a wiki-type of system might be nice to integrate complete documentation systems in with this." Derek was not convinced - he could see the need for some kind of "Knowledge Base"-type database, similar to those in proprietary ERP systems, and the GNUe Applications would need something similar. But "wiki imho is not good for documenting" - "not horrible just not what i would choose. That certainly doesnt mean others might agree with you and that integrating something like that into dcl wouldnt be a horrid thing" - he "would need to think about it more i suppose" . 6. Converting GNUe Small Business to use CVS (0.5.x) version of Forms 19 Feb 2003 Archive Link: "[IRC] 19 Feb 2003" Summary By Peter Sullivan Topics: Small Business, Forms, Designer People: Derek Neighbors, Jason Cater Derek Neighbors (derek) asked "what is plan for gnue (are the roadmaps still valid) - last i played i was going to convert gnue-sb to 0.5.0 BUT it looks like 0.5.0 never got really released as official - and now much more overall is happening for a 0.5.0 release. Am i better just trucking away on 0.4.3 for now" ? Jason Cater (jcater) asked "will you need designer? if so, you have no choice but 0.4.3" as the CVS version of Designer was not currently working. Derek said "yes and no - i can do forms w/out designer" (by writing the XML form definitions in any text editor) "but im starting to get dependent on it :) - good tools are like that ;)" Jason said "my inclination is to say stick w/0.4.3 for now - however, I *know* I'll regret that when you say "can I do xxx in forms?" and I have to say "in 0.5.0 you can"" . Sharon And Joy Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.