GNUe Traffic #16 For 16 Feb 2002

A new use for DCL Project Management? - "I tried to use it to manage my kid but he won't cooperate" - "yeah the 'sit still' module is still in development - i checked in the shell of the 'dont touch that' module last week "

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 at http://www.gnuenterprise.org/irc-logs/.

Referring back to Issue #5, Section #1 (18 Nov 2001: Hindi(Devanagari) characters in GNUe Forms) , Jens Müller asked " What means "Unicode" here? UTF-16?" Aditya Gilra explained " I meant the unicode strings in python2.1. I suppose python stores it as ucs-16." . He made several other points about unicode support in GNUe, but particularly emphasised " Please do not use the str() fn anywhere. It cannot handle unicode strings having chars beyond ascii i.e. > 127." The database drivers and user interface drivers would need to use codec functions to convert to and from unicode if necessary.

Some days later, on IRC, Derek Neighbors (derek) asked " did you see the list mail on unicode - and that we should never use str() and related functions? and code on how to work around it" . Jason Cater (jcater) said "um - I don;t fully agree w/that - that will KILL performance if you aren't using codecs" .

Andrew Markley (AnDarkon) asked " Would a Time & Attendance system be a good addition to GNUE?" . He was thinking of using UML as his design medium. James Thompson (jamest) said that was OK, but " alot of us use text files and give general overview" .

Later, Derek Neighbors (dneighbo) asked for more details of Andew's Time and Atttendance system - " you have something and you want to contribute it to gnue?" . Andrew said he was "designing it as we speak. but if you could use it, then I could try my best to make it so it doesn't require any (or very little) rewriting to work under GNUE - I do fully intend to have it stand-alone in any case " He said it looked as if, with GNUe, "the UI and the DB ends are abstracted from the core functions" , in which case he would be keen "to write it to GNUE guidelines/framework " . Derek said "we would love to put under the gnue umbrella and we would make templates and such to make it fit with other packages thusly still letting it stand alone as well " . Andrew asked about copyright. Derek said "we require copyright assignment to FSF - but its DUAL copyright" . Andrew said " I decided on GPL so it's not a problem :-) and have already spent some time on the FSF copyright issue; no reservations whatsoever" . He would also "secure a copyright release from my current employer" . Derek said that copyright assignments usually hadn't been an issue, except with a few big IT companies, where corporate lawyers had got involved.

Nick Rusnov (nickr) asked "wouldn't T&A relate to dcl/phpgw?" . Derek said "kind of - thats why im interested some what" . DCL was " more like job costing time keeping - this is where i really need to sit and ponder dependencies and templates etc" . Nick said he had thought DCL "was project management and issue tracking" . Derek said it was "it was initially a work order system - then it had help desk kind of added " . However, as Andrew noted, "it doesn't provide gross payroll calculations, general ledger cross-referencing" and said "Looks like I'll be covering the gaps :-)" . Derek agreed - "i see payroll as a module, time keeping as a module, etc etc. I think of dcl in some ways as cost based time keeping that would feed time into payroll - or into a traditional time keeping system" . He personally now used DCL to log everything he did - "even now meetings and such" . This meant he didn't need to do a seperate timesheet, as "a report from dcl would tell me the same thing" .

Andrew said his system, called KOMP, would handle "inputs/outputs from clients and front-ends to MRP/ERP systems - all in real-time fashion, along with p2p support so that the timeclocks themselves can be 90% turnkey and scale up with the business - of course small businesses don't need all of the ERP features" . It "could be a complement to DCL, in support of real-time tracking, ie shop floors" , although it was "more for blue-collar work tracking than white" . Jason Cater (jcater) agreed - "dcl is great, but only for a minority of time-tracking tasks - I wouldn't keep up w/my hourly ppl's pay w/it :) " . Derek said "i think in manufacturing, white collar, and other activity based environments it would work with some work :) For things like mcdonald employee time keeping - no its overkill :) As you want to clock in clock out and thats all." .

Andrew explained "KOMP will be able to handle bundled work orders. An example: a company runs its production lines based on orders from its buyers and sometimes two or three orders are for the same exact widget, so instead of running three orders in sequence, the employee can run them all at the same time" .

Derek suggested "maybe using lyx for your documentation (as its similar to tex) and one of the approved gnue doc formats - then grabbing gnue and installing it, see if its somethign you woudl consider using to write KOMP in" . Daniel Baumann (chillywilly) wasn't keen on lyx, for reasons discussed in Issue #4, Section #4 (14 Nov 2001: Using non-free tools for GNUe Documentation) . Andrew said he would use Dia for diagrams. He "was thinking of using SOAP (or XML-RPC) to handle the client front-end (read: from the shop floor) to KOMP" . Daniel commented that "we are building an rpc abstarction that will support xml-rpc, soap, corba, etc. - which our tools will use" as a common API. Andrew was worried "wouldn't that be a little heavy between the shop floor and KOMP?" as "the shop floor will have timeclocks (PC-based) which punches and labor start/stop will be recorded. The timeclocks would then query/message the KOMP engine" . Daniel said appreciated Andrew's concerns, but " I don't think it will slow anything down - you have a config file ststing which mechanism you are going to use - it loads the "plugin" - then can send that type of message - similar to the db plugins" . Andrew said " Right, KOMP itself will be abstracted away from the external interface. There would be a module between the shop floor and KOMP" . Daniel said that Jason Cater was doing most of the work on the RPC abstraction, which was documented in CVS.

Andrew Markley (AnDarkon) asked "what inspired you guys to develop an ERP system?" . Neil Tiffin (neilt) said "seemed like a good idea at the time :)" , which it still did, "but it is a lot of work also" . He added that "we have a lot of people interested, but when it comes to committing time it is hard to come by for a lot of people (including me right now) " .

Later, Andrew asked "just how new is GNUE?" . Daniel Baumann (chillywilly) said "GNUe is 2 years old believe it or not " . He said that James Thompson or Derek Neighbors "could say more about the "history " of GNUe - reinhard was also there in the beginning" . GNUe was different from other free software or 'open source' ERP projects like OpenEAS or Compiere, as it was not just applications, but "a framework that can be extended to write any sort of enterprise application" . He added "once the GNUe tools marture to a certain point then the apps will come - we battle with thise sort of thing all the time though as everyone wants apps ;)" .

Derek Neighbors (dneighbo) noted " whoo hoo for first time gnue.org broke over 500,000 hits in a month and crushed the 50,000 in a day mark getting like 67,000 on our last release cycle Not that 'hits' matter in sense of we have nothign to sell - but at least people are recognize the project" . Andrew Mitchell (ajmitch) noted " in november there was one day with > 80000 hits" .

Derek Neighbors (dneighbo) pointed to an article on Newsforge that mentioned GNU Enterprise. "hopefully its truthful enough ;) - unfortunately the LEAD article is about new small business POS/Accounting software and it gets RAVE reviews :(" .

On IRC, Andrew Mitchell (ajmitch) was having problems using GNUe Designer with MySQL, and suggested " hmm perhaps the mysql driver wants some TLC :)" . Derek Neighbors (derek) confimed " mysql driver needs help - it does NOT have introspection i.e. it doesnt work with wizards" . Andrew wondered "how hard it would be..." Derek said it "shouldnt be too hard if you know mysql api :)" . Andrew looked for the MySQL documentation, and asked " what introspection requires :)" . He asked which drivers already supported introspection, so he could look at them for ideas. Derek said that the drivers for " postgres, db2, oracle" already had this.

Andrew posted a patch to the mailing list "to fix my problems - now you can use designer wizards with MySQL databases!" . He admitted that MySQL wasn't very popular in the GNUe community, "but some poor people like I use it for various reasons ;)" .

Later, on IRC, Jason Cater (jcater) announced " By popular demand, schema support for MySQL is now in CVS." . He had "done basic testing. If anyone who actually uses MySQL could do more complete tests, it would be appreciated :)" . He clarified that schema support/ introspection was "in common for all to use - but designer is the only thing to use it at the moment " .

Derek tried to clarify whether Jason had just applied Andrew's patch. Later, Daniel Baumann (chillywilly) noted "looks like the same code - he should've given you credit in the commit message - liek ppl normally do in a ChangeLog entry" . Derek said Jason normally did, " which makes me think he didnt use aj's code" . Andrew said "hmm, code looks similar but not quite the same" . Later, Jason asked "when did aj do the mysql patch?" He was "half-tempted to back out" the patch he had written himself, and use Andrew's instead. Daniel noted "heh, so they did hack the same thing - that's too funny" .

Derek Neighbors (derek) said "hey jamest want a bug?" . Designer was putting CTRL-@ signs inbetween each character of a GNUe Forms Definition. If he used emacs to remove these, "then the forms are fine and dandy" . Peter Sullivan (psu), remembering Issue #5, Section #1 (18 Nov 2001: Hindi(Devanagari) characters in GNUe Forms) , suggested "it;s the unicode bug again by the looks of it" . Derek agreed "we had this before (on this machine) and i dont recall if it never got fixed or if its resurfacing :)" . James Thompson (jamest) said "it's not ringing any bells with me - did jcater look at last time?" .

The next day, Jason Cater (jcater) said " it's saving your file as unicode once again, how'd you do that????? " . Daniel Baumann (chillywilly) said "if there's a will masta will find the way " . Derek said "i work hard to be such a buggy tester" and said he " doesnt feel appreciated ;)" . Later, he reported "i think my unicode issue went away - twice i have gotten new cvs from designer and it just acts WILD - so i delete my cvs dir and re co and all is well" .

The next day, Derek asked " do you have any idea if the unicode issue is in our code or my beta python version? as i really dont want to spend all night upgrading python" from source if that wouldn't fix it. He asked " can you tell me which .py file in designer does the save? so i can start 'debugging' the problem - or tell me what to grep for " . James said " GObj should do the save - dumpXML" Derek said " if i save blank form it works - if i save hand created form it works - if i save a form after i run the wizard it does unicode" . Based on this inconsistant behaviour, he thought "its something that wizard creates but not the wizard itself" . James asked Derek to run a sample form and cut and paste the error message for him. Derek noted that the xmlDump function was producing the correct output, " so im wondering where perhaps its happening in writing out the file or someting?" . He asked "what is StringIO()" , which the save routines were using. James said this might be relevant, as "its unicode aware " . Derek tracked down the code that did the save routines, and said it " looks pretty standard to me" . James said that "stringIO can't mix and match 7bit and 8bit codes" . He added " IIRC weren't there some I18N changes made so that someone could do forms in lang other than english?" Derek bypassed the normal save routines and had xmlDump write directly to a file, and was still getting the problem.

Jason asked "what version of PyXML you running?" . Derek said he was using 0.6.5. Jason "wonders if 0.6.5 is not compatable w/2.2 as a lot changed in py2.2" - Python 2.2 could equally have been called "3.0 considering all the changes " . Derek said he would " try a newer pyxml" , but this " didnt fix things" . He was beginning to think the problem was probably "probably python2.2a - but i really wish that had better proof of that" . He said "what is bothering me about this problem" was how inconsistant it was. Jason asked "does anyone else use python2.2? as I'm not kidding... a lot changed in 2.2" . James said "IIRC unicode support was big in 2.2" .

Derek found a reference from the official python page that said "In Python 2.1, the StringIO module (though not cStringIO) supported Unicode. This capability is accidentally not present in Python 2.2." This "explains why SECOND time it happens - is stringio is used to READ the xml file" . James and Jason both swore loudly. Derek said that "i can use 'emacs' to fix things for now - but this is big as we need to not tell people to use 2.2 or we need to fix our code to not use stringio" . Jason said he would patch the Designer code to work around this, but Derek thought it might be better "to say we dont work well with 2.2 until they fix bug" . Jason uploaded the patch to CVS, but wasn't sure it would work - "if the same issue then we are 2.2 incompatable for the indeterminable future" . Derek said "thats probably not too horrid as im the only one insane enough to run 2.2 :)" Jason hoped "I hope they come out w/2.2.1 before major distro's bump up to 2.2.x support" . Daniel Baumann (chillywilly) noted that "not even debian unstable has 2.2" as of time of writing. Derek was still getting the problem even with Jason's patch.

Andrew Mitchell (ajmitch) asked for some advice on "how to build a nice form for data entry - i guess it's a case of RTFM?" . He had " a working form, i just need to make it nicer :)" . James Thompson (jamest) mentioned " a fewe things I do - i typically add case="upper" to my entries so that the data always goes in consistant" . For addresses, he had some datasource code he often used to look up the city and state from the zip code, "with that trigger attached to the zip entry" . He admitted " this is of course only good example for lamericans" and added "the above is completely undocumented - it's what I've been working on in cvs" . He added that "you can get a feel for what you can do with triggers from the common/doc/ dir - there is a trigger doc in there that describes how this almost works :)" .

Perry Lorier (Isomer) asked " under Windows they have various widgets which they can connect to a SQL database, "Data Aware Objects" or something. I believe that Java has something similar. Other than gnue, is there anything similar? or, is the solution that GNUe provides, portable to other programs other than the forms builder? For example, can I use corba to connect to geas to do this?" He added " well, I want to develop applications in C or C++, and have access to widgets that don't require me to handle all the database handling. "

The next day, Peter Sullivan (psu) suggested that GNUe Common and GNUe Forms might do much of what Perry wanted. Derek Neighbors (dneighbo) said he wasn't sure - " if he wants database abstraction for C code he might be better off right now today to look at libGDA - as writing bindings for our gnue-common is probably more trouble than he is looking for. If he is looking to use application server then yes via corba today he could use our app server with his front end and write methods in python or C. If he is looking to us gfd, he could write a forms engine in C though i wouldnt recommend it at this stage of the game. So some of it depends on his 'needs' in order to answer properly." .

Andrew Markley (AnDarkon) said he had reviewed that Module Guide Proposal and Base Package Proposal, and had some questions. James Thompson (jamest) suggested "you'd get the most intelligent answers from neil or reinhard" . Andrew asked "what does GNUe have working so far? " James said "Tools wise.... forms, designer, reports (limited)" . Andrew said "There's a benefit of having GNUe available for my work; I can concentrate mostly on the Time & Attendance (realtime) module without having to worry about the frontend or the DB aspects" . He asked "the designer is for the forms or is that also for biz logic?" . James said "right now it's forms only" but would eventually be extended to be a reports designer as well. James said "we're having interface/performance issues with geas and neil and reinhard are busy with real life - the interface to geas needs work and the performance is terrible, the security is terrible. reinhard and neil are fixing these issues but they inherited the system so it's slow going" . Andrew said "the geas itself is the whole point, isn't it? what with the business logic/rules" .

Andrew asked how objects would fit into forms. James said "when dealing w/ objects internally i see the following mappings: object = table, object instance = row in a table, object method = trigger, object attribute = field, object child = master/detail relationship" . This would mean that "forms looks at objects and tables in the same mannor - they both have the same capabilities and only the terminology changes a little" .

Andrew Markley (AnDarkon) said " I had the impression that the forms were also UI-agnostic that it could run under web, X, etc" James Thompson (jamest) said "it should be - at one time the curses and GUI systems both worked - but currently the only one working is wxpython - that is going to be fixed soon" . However, the user interface was not tightly coupled to wxpython at all. In fact, "jan is working on a php forms client " , as referred to in Issue #14, Section #25 (30 Jan 2002: PHP client for GNUe Forms) and Issue #15, Section #10 (5 Feb 2002: PHP version of GNUe Forms client) . He felt "what is cool about it is that his goal is too make it look/behave as close to uiwxpython as possble - and he's doing a pretty good job of it" .

Yurii Rashkovskii (Yurik) said he thought "that UI is not very important thing. Most of the system in enterprise management should run absolutely automatically" . Andrew agreed, but said "it just so happens that my realtime T&A needs some UI in different forms: Win32, DOS, Web, etc" .

Andrew Markley (AnDarkon) asked whether storing GNUe Class Definitions (.gcd) in a database had been considered. Reinhard Müller (reinhard) said this had been discussed before (see Issue #8, Section #7 (13 Dec 2001: Storing GNUe definitions in a database) ). The main points raised were:

storing them in database would be big change and take a lot of time
we need files anyway to "bootstrap"
storing them in database would mean we need a comfortable way to edit it (via a form)
with gcd files we have all those un*x possibilities from grep over awk to sed
having in ascii file lets you edit the definition w/ vi or emacs even over 9600 modem line or something like that

He said that "the final decision was 1. for now let them be in gcd files 2. maybe later rethink about moving to database" . Andrew said he had asked because "we might want to have a distributed network of application servers - then again, nfs could solve the problem rather neatly for shared access to the GCD files" .

Andrew Markley (AnDarkon) asked "what's the smallest resolution for the TIME type? I'm hoping it'll be in milliseconds or I'll have to extend it for the T&A module" . Reinhard Müller (reinhard) said " it will depend on the database - but we can only "guarantee" the least common determinator" . He explained "we have definitions like "char must be able to store strings up to 255 bytes" and for every db geas must choose a type that is able to do this" . The time type had not been defined yet in GNUe Application Server (GEAS). Andrew suggested "Ok. Maybe I got here in the nick of time (pun unintended)" . He understood the problem - "Oracle doesn't support datetime as well as Informix can; in the worse case scenario, it could be a CHAR field " .

Andrew Markley (AnDarkon) asked whether " for the class currency, the default_decimals is set to whatever the company wants it to be and in the event of a change in management and/or accounting procedures they want to change the decimal position " ? Reinhard Müller (reinhard) said this was fixed - "the default_decimals is specific for the currency not to the management - like us dollar will always have 2" , whereas Egyptian currency values were always stored to three decimal places. He added that " the precision of the values can differ from default_decimals for certain cases" , such as reporting.

Kenny Flegal (soulstompp) said he had downloaded and installed GNUe and wanted " to start toying with the forms portion to see if I can use this for some practice management software I am working on" . Derek Neighbors (derek) clarified " i am going to assume 'practice management' == some sort of doctor/lawyer ERP?" . Kenny confirmed "yeah we have an interested cardiologist and dentist" . Derek said " GNUe is several things but its core things are : a. a framework for rapid business application development b. a prebuilt system using the framework that is highly extensible " . The framework could be either client/server (2-tier) or "multi tier (application server)" .

He said "the biggest issue we face is that we have only build 'custom' solutions" so there were no working applications available under the GNU Public License yet. "we do have a lot of supply chain and some accounting with specificaitions (read business requirements) - HOWEVER those specs were built with our application server in mind" . However, "the upside to this is we want gnue success stories - and we want them bad - which means im sure you would get more than one of us to help you on practice management software IF you were willing to give them back to gnue for others to enjoy" . Kenny said " this is a new business and all of us are in agreement that GNU is the way to go - so I would happily contribute everything back to the community - that is good" . Derek said "i think that if they have NOTHING at all currently other than paper you could give them USEFUL applications by weeks end - when i say USEFUL, it might not have all bells and whistles but they will be capturing some stuff in a real database so when more features come on line they can easily start absorbing them" .

Kenny asked about reporting. Derek said that, in the interim, you could just use a non-free reporting tool like Crystal Reports to access the data directly from the SQL database. However, "our report server i think kicks MAJOR ass - but its not production ready yet. It generates all XML output for maximum flexibility - and it works liek a SERVER i.e. i can run in server mode so that you can 'cache' reports like monthly financials and things" . Also, " one VERY useful thing it does is document merges :) which is VERY important for practice management as they have to write lots of patient and insurance 'letters' or 'form' letters" . This meant "you can use ms office, star office, abiword etc to make document and run it against server to poplulate it" .

James Thompson (jamest) then spent some time walking Kenny "thru building a ui so you can see how easy it is :)" using GNUe Forms.

Later, Kenny thanked "jamest and derek for all of your help - I have a GPL fistfight I gotta finish with the founders :) - I am glad to see that this project has a community that is so helpful - it is going a long way in my argument - well that and that the product is so cool" .

The next day, Kenny had some initial problems getting GNUe to talk to his database, which Derek and James helped with. He confirmed "I got connected and I am playing with the wizard" in Designer. He said " I went through the wizard and got the form set up and I added a button " . James said that, for simple forms, "you don't need buttons on a form for anything - you get queries and commits for free - via the menu, toolbar, or keyboard shortcuts" . Kenny was impressed, but reported "I am getting a segmentation fault everytime that I try to delete this button off of my form" . James said that was a known bug. Kenny said he had " deleted it from the XML doc" manually. James said "at this point in time i find myself doing 1/2 in designer 1/2 in vi|emacs - a month ago I was doing 1/4 designer so were getting there :)" . Derek claimed his ratio was "3/4 1/4 - the trick is dont make mistakes " .

Kenny asked whether he should " do the database in an OODB or relational design" . Derek said "um use what works for you - relational will be easier for two tier - when we get geas (appserver) up to speed we will probably make a 'conversion' tool so you write your objects in geas and map your relational tables to them or somethng similar" . James said " i do relational - the form can do master/detail but designer can't auto set it up - what I do is make forms for each table, put the blocks together and hand modify the datasource entries" . Kenny said he would play with Designer more later, and "give you some feedback tommorow - hopefully it will be useful"

Derek Neighbors suggested a cure for boisterous children - "we could use an ADO driver for common - m$ says they require a 'first' born" . Daniel Baumann (chillywilly) suggested " we'll use yours then - you have children to spare - /me only has one" . Derek suggested " we need find someone with a kid so bad that m$ will give them back :)" . James Thompson (jamest) suggested "heck, chillywilly how old are you? think you could pass as a kid ? if so then it'd be like a trojan horse" . Daniel replied " but I would die inside if I worked for the beast - chillywilly would be no more" .

Derek Neighbors (derek) reported that GNUe Common "appears to be IGNORING port" in the connections.conf file when accessing pypgsql. James Thompson (jamest) said that the port parameter was not documented. Jason Cater (jcater) said "I thought port= was documented " , and asked when Derek had last updated from CVS. James noted that the connect string code supported " 'host=%s dbname=%s user=%s password=%s'" only. Jason said "we need to modify connections.txt to say "look in README.databases" to see all supported parameters as each database driver supports different parameters - most either support the (host, port) pair or (service) string" . Everyone was sure this had been discussed before, but no-one could find a record of it. James suggested "you might be able to do host=foo.bar.com:port" as a workaround in the meantime.

Andrew Markley (AnDarkon) asked " how was the decision to use python made? I made the same decision before I found GNU enterprise. I'm curious about the thinking process that came to that point :-)" . James Thompson (jamest) said "i'd used tcl in the past and wasn't happy with it - lots of people on the list either already liked python or didn't object to it" . Andrew said he had been "deliberating between Python and Java. I had already concluded that perl, while being very veristale (sp), would get too spaghettiy in large projects - what cinched is was Jython heh; the fact that I could run Python code on top of java machines cinched Python as the winner" . James said he "dislikes java with a passion" . He said "a major problem with java is the inconsistancies in the java VM" , meaning you often had to use specific versions of browsers for specific applications. Sometimes you ended up "redoing the systems to run java on the web server" using jsp " which makes the whole cross platform benefit of java kinda moot " . However, he hadn't used Java recently. He concluded "I used to be able to get GCC to run on far more platforms that a JVM - which I always found somewhat amusing :) " . Andrew said "I haven't encountered a system yet that didn't have gcc" .

Further to Issue #15, Section #11 (6 Feb 2002: Polls for web site) , Derek announced "there is a new survey out there for you" on the GNUe Enterprise web site, asking what databases people used. He said "im hoping the number of Other (not listed) is minimal as it will mean common is pretty complete db wise :)"

Two days later, Jason said that he was " surprised how many ppl use MySQL for business data - and how many "others" there are" . Derek said "i really suspect most people consider dynamic db driven web applications as 'business apps' - thus the mysql numbers" . He said "mysql is to me like access - a good 'starter' db - and lots of folks doing first business consulting etc pick it up cause its easy and the BIG feature sell is its xplatform natively - not through cygwin" . He was surprised at the number of answers for 'Other', "as i think we have all the BIG ones listed" . He was " im impressed to see 11 oracle - not suprised that oracle has market share mind you - suprised that Oracle (highly expensive) users are looking at free software ERP" .

Andrew Markley (AnDarkon) asked why everyone seemed so impressed that he was an 'Andrew M.' Peter Sullivan (psu) explained "Andrew Murie did the original code for GEAS - which reinhard & neilt are now re-hacking" . Andrew asked "am I to infer that the original GEAS is somewhat a hairball?" . Peter said "I think it would be fairer to say that it was written by/for a company for its own purposes and then contibuted back to the community and thus did what they wanted rather better than what the project wanted/needed - plus everyone's ideas about what an App Server should be has evoleved somewhat" since then. Reinard Müller (reinhard) reminisced that " his boss (who also was here very often was also named andrew" . Derek Neighbors (dneighbo) said " at one time there were 3 andrews on this project all from new zealand within like 150km of one another" . He said "the joke was - to live in new zealand must you have andr in your name?" Reinhard said "some days we entered irc and said something like "hi andr*" :)" .

Derek Neighbors (derek) said " next phase will get serious and i think will do press release on the usage for a site i do work for, they are a recruitment firm - they have online candidate/employer databases" , which was web-based. However, he didn't want to use web-based forms for administrative tasks, so "in about 30 minutes i wrote two nice forms to do the management - and i am pleased as punch - getting ready to add new billing features that i hope to NOT make any web screens for. i also hope to give them some READONLY forms for 'searching' - currently i have some pretty kick arse web search forms but i dont like them cause they are web based :) i hope to get mail merge wizards for them and other things - all in all its a start" .

James Thompson (jamest) noted that " postgresql made oid's optional in 7.2" . This would mean "our schema stuff now fails" . Derek Neighbors (derek) wondered " why on earth would they do that?" James said "some users didn't want the performance hit (i read that as mysql users :)" . Derek said he thought "sometimes people sacrafice WAY too much for sake of performance" . James said that this meant that "in any case designer wizard are now dead for me - until i have time to figure out how to restructure the query" . Jason Cater (jcater) asked whether PostgreSQL was part of the woody Debian distribution yet, in which case this might become a common problem. James said he would find out.

James Thompson (jamest) said " i need forms to do dynamic menus - now" . Derek Neighbors (dneighbo) suggested using GNUe Process Definition (.gpd) files " and integrate them into the menu structure - that woudl be my vote. Or do you mean REALLY dynamic menus - like triggers editing them" ? James said yes. Derek replied "well i still vote read gpd into menu structure then allow for its manipulation " . James said he was up against a deadline, and gave a list of parameters for his new GMenu object. This would allow the GNUe Forms parser to read <menu> tags, nesting them if required. However, he wasn't sure if this was a good idea, "as I'm allowing gfd people to override menus" .

He explained " the entire menu structure for forms will be in a file in gnue/etc so you can do site customizations to the menu" . Derek said " i thought that is a large part of what .gpd was" . James said that gpds were more for process-based menu entries - a custom menu entry like a modified "file - save isn't a biz process" . Derek suggested " if i want it in the framework (on EVERY form) it shoudl go in gnue/etc - if i want it on only SOME forms it should be in a gpd" . James added that " a single entry in gnue/etc/forms-menu" would determine whether the gpd file was used in the menu system or not.

James noted that, in some cases, he might need to replace standard menu options with bespoke ones - "this doesn't really lend itself to a nested <menu> structure" , as he would have to re-create all the existing menu structure in the gpd file. Instead, he was wondering about allowing developers to specify a location within the existing menu structure to attatch a new menu item to. Derek disagreed, saying " i dont think menu structures belong in forms" - he still preferred doing this in the gpd file. James said "it's like a custom menu for an app" , whereas " gpd is the basis of workflow" . Derek said that was part of it, "but its made to do what you are saying - it can call outside apps, reports, other forms etc etc" . James said all he wanted to do was "to call custom triggers defined in this one form" . Derek said that James' proposal was tantermount to " lets throw gpd away" , as this was always the sort of thing it was intended for. He suggested talking to Jason Cater.

Later, James clarified " i'm making a menu system that can be dynamically defined and exposable to triggers that any gnue app could use" . Derek agreed, but said that " most of the time you arent going to want to define things dynamically 100% - that is where you use gpd" . He added "i hate irc - i think face to face adn white board would have this solved in minutes " . James looked for " docs on gpd's" but couldn't find them. He thought he "may just hack a custom gfclient w/ extra menu entires" to meet his immediate deadline "as this is turning into something well beyond anything I can do in the time alloted" .

Derek Neighbors (dneighbo) said " i think we see an IT trend - shops are sick of paying high dollar levies to be treated like crap - so the higher the price tag and more shit you are treated more likely you are to come in search of FS" . Jason Cater (jcater) said " well, it's no secret that IT budgets have been slashed, yet the technological needs have not shrunken at all" . He said "it trips me out the consultants who we bring in who think the products they supply should be supplied at a cost relative to the about of money we save over the long run - instead of how much the product is actually worth" . Derek thought it might be interesting if, say, toilet paper was priced that way - "lets face it you would be buying a lot more underwear" without it.

However, "toilet paper is bad example as its really not REUSABLE" . A better example "woudl be a tooth brush" - "as brushing your teeth saves on average 2 cavities a year - and cavities cost 800 to fill - so 200 for a brush that saves you 1600 is an INCREDIBLE deal. Then the 500 for the toothpaste contract - thats where the REAL value is - i mean for 700 you will have your money back in less than 6 mos - how incredible is that?" He noted " what is funny is anyone reading this would probably die laughing - but this is common thing in IT industry" . Of course, "the vendor just makes sure his toothpaste is incompatiable with other vendors brushes so you are locked into that toothpaste contract - or forced to buy a new brush" . Jason said that " their toothbrushes require their own special "holder" - custom installed, of course. You can't reuse your existing holders ("I know the slots are the same size; but ours it calibrated especially for our toothbrushes. Also, who's to say your holder can withstand the extra load")" . Derek added "yeah crest's holders just dont 'scale' well - i mean a family of 5 or 6 and your screwed" .

Jason said "let's not forget "user training"" . "and floss" , added Derek, "thats high performance dental care - you pay top dollar for floss" . Jason said "one member of the family will need to be flown to our "flossing seminar" - BUT it's in Miami this year " . Derek said "for only 4,500 i can get crest 'reach' toothbrush certified - with that cert i am like 80% less likely to have ginvitis which is a huge value - peridontial disease is SO costly" . He noted that "the toothbrush vendor regularly is able to sell brush, paste and floss to folks with dentures :)" . Jason suggested that maybe "the vendor has a 20% stake in the Denture company - "to spread his risk"" .

Derek thought he should perhaps " make a small list of things that are 'cheap' but highly useful - then see if they have some 'money saving' value like the toothbrush - "what if the rest of the world operated like a software company..." we ahvent even relaly touched on the 'monoply' implications here :) just on the no value ones :)" . He said "people wouldnt buy a 200 dollar tooth brush and a 500 toothpaste contract - they will buy millions of dollars in software license fees - though i think slowly people are stopping the trend - whether it be because of reduced budgets or waking up and smelling the coffee" .

Daniel Baumann (chillywilly) asked "btw, I was looking at some code in common and was wondering what GObj is exactly?" . Jason Cater (jcater) said it was " just a generic object that can be expressed as XML" . He explained "there's a few other convenience functions in there" but otherwise it was just a container for items like GFForm, GFBlock, GFEntry and GFBox.

Daniel asked whether it would " be useful if all business objects on the app serverwere GObjs? " . Jason said he hadn't considered that. Daniel said this would mean "you could transparently get persistence of GObjs ;P" . Jason said "well, the only persistance I see us needing is storing the objects in their corresponding XML file - so the point of GObj is already to provide transparent persistence via xml" , but he wasn't sure. Daniel clarified "so, does having GObjs witht he ability to output xml help you generate forms? Is that how you use it?" . Jason confirmed this. Daniel said "maybe I should concentrate on an ODMG python binding to store any type of python object [...] anyway, GObj just kinda caught my eye - think about it, lemme know if anything smacks you upside the head ;)" . Jason " nervously looks for approaching trout" .

James Thompson (jamest) asked " navigator - how official is it?" . He wanted "to make win setup.exe of it " . Jason Cater (jcater) said he thought it was very useful, but "wonders if he shouldn't add a "tree-style" interface first" . James suggested " you might be able to rip the event handler (unused) in forms UIwxpython to possibly grab those events you're missing in UIwxweb" . He would have to prioritise getting " windows support polished up tonight in there" and try to work out why the CVS version of Forms was not working on Windows. Later, Derek Neighbors (derek) confirmed that he regarded Navigator as 'official' even though it needed more things adding and hadn't been part of a release yet.

Jan Ischebeck (jan) said he had been working on block support, "but the biggest problem, i've spared up ;) for later: master-detail relationship" . James Thompson (jamest) wished "you could interface to our python stuff" in the normal GNUe Forms client. He "haven't seen a php/python bridge though :( " . Jan suggested "We could do it by SOAP. [...] I'm not shure how to write the python part, but if there would be a gnue-common webservice, possibly with a similar interface like GEAS...." . James said " there was work done on gnue-rpc" , but Jason Cater had had to deal with more pressing issues. Jason (jcater) said "the real issue is that gcommon is a library, not necessarily a service - so I'm not sure how that would work - it's as easy to do XML-RPC in Python as in PHP, though" . Jan said he would particularly like access to "the db abstraction layer" in GNUe Common.

James said he was thinking of adding to Forms "the ability to say that forms pages are steps - so that I could rapidly design a web form that is one or more steps - then on the last page a commit is done - as personally I hate making html forms" . Jan said that was possible - "Whats about a "WIZARD" attribut in the <form..> tag?" . James said he had not given this a lot of thought, and " i'm not sure how the normal client would deal with this type of form " or even if it was desirable functionality. It wouldn't be a problem if it required a change to the XML definitions, as "I don't think the DTD is stable yet" .

Jan said the PHP forms client was very slow at the moment, as "Every time php parses the xml file and load session data." , but was faster if cached. He would look at improving the caching once "the basic features are in" .

Jan started to think about James' wizard idea, and said "every page needs back and forth buttons and the last one needs the commit button." . James explained how to do this in python. He said the wizard would be "usefull in 2 places - html forms are #1" . They could also be useful for situations like "say you want your reps to always ask the same things in a specific order" . Jason Cater (jcater) noted "if we had multipage blocks this would be easy to do using existing "pages" concepts" . Jan thought that however the wizard worked, it needed to work for " the standart client" as well, and wondered "Whats about using the normal pages and some triggers to implement it?" . James said that " right now forms are of type="tabbed" iirc which makes the pages become notebook tabs" - a " type="stepthru"" could be added. It was important to "hide all the extras - query, print, next/prev foo, jump to record" so that there was only one route through the wizard with " and gave a next, back, cancel button" . Multiple blocks wouldn't do this. Jason agreed, but said " multipage blocks are probably a prerequisite - and if you had multipage blocks, you could easily simulate such a system without a special tag " .

Later, Jan asked " why shouldn't two blocks share on datasource?" . James said "our datasources implement master/detail - so they have a concept of current record" . This allowed users to "cruse thru a master/detail set of data changing masters and children at will - then commit the whole mess" . Jason said this was a key feature - "I don't know of another forms implementation that can do master/detail like GNUe can" . Jan did a simple "master detail implementation in one single block" and decided ". Ok, thats enough master detail for tonight. :)" .

James said that he had now put Jan's PHP Forms client on the GNUe website - "i set him up an account so we can always show this stuff off :)" . He had already publicised it to several contacts by e-mail. He tried Jan's 'pre-alpha' wizard. Jan noted "only thing is form cannot send mail to you" . James suggested using triggers, but Jason thought "conceptually, it wouldn't be a problem to have a "write-only" database driver that actually sends an email :)" . Jan said his PHP client needed some more debugging, and currently didn't support "RPC, SOAP, orbit,.... just postgres....." . However, James said he thought it was really useful, especially as the same GNUe Forms Definitions (.gfd) could be used with the normal Forms client. Jan added e-mail forwarding as well.

James was very enthusisatic, but emphasised the need "to be carefull and figure out how to wrap this into common" and the main Forms client as well. " we need to get php and python playing together" , so they could feed some of Jan's work on the PHP client back into the main Forms client. Jason said that, "if we don't mind restricting this to apache for the near future we might want to look at mod_python or mod_snake" . He cut-and-pasted " Mod_python is an Apache module that embeds the Python interpreter within the server. With mod_python you can write web-based applications in Python that will run many times faster than traditional CGI and will have access to advanced features such as ability to retain database connections and other data between hits and access to Apache internals." . James thought this sounded promising.

Later, James emphasised that they were trying to merge Jan's work into the core product, " so that the python forms core and common can be used" . Derek Neighbors (derek) wondered whether a PHP Forms client was worth it - "in the same amount of time he could probably learn one of the python embeded deals" , but he admitted he wasn't keen on web-based forms generally. James said the whole focus was "ways to reuse what we have" , and the lessons learned could be useful in developing an HTML forms client. He thought " what was demo'd tonight was nothing short of breathtaking" .


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

1.	1 Feb 2002 - 10 Feb 2002	(2 posts)	GNUe unicode support
2.	7 Feb 2002		Time and Attendance Module for GNUe?
3.	7 Feb 2002		GNUe History and Philosophy
4.	7 Feb 2002		GNUe Website
5.	8 Feb 2002		GNU Enterprise on Newsforge
6.	9 Feb 2002	(1 post)	Introspection for MySQL driver - times two
7.	9 Feb 2002 - 11 Feb 2002		Occasional unicode problems with Designer
8.	9 Feb 2002		Forms Tips and Tricks
9.	10 Feb 2002 - 11 Feb 2002		Using GNUe tools to write C/C++ applications
10.	10 Feb 2002		GNU Enterprise infrastructure Q & A
11.	10 Feb 2002		User Interface for GNUe Forms
12.	10 Feb 2002		Storing GNUe Class Definitions in a database
13.	10 Feb 2002		Defining field types in different databases
14.	10 Feb 2002		Decimals in Currencies
15.	10 Feb 2002 - 11 Feb 2002		GNUe for Practice Management
16.	10 Feb 2002		Microsoft ADO driver for GNUe Common (but rapidly off-topic)
17.	10 Feb 2002		Using pypgsql driver on a non-standard port
18.	11 Feb 2002		Python or Java for GNU Enterprise?
19.	11 Feb 2002 - 13 Feb 2002		Polls for web site
20.	11 Feb 2002		History of GNUe Application Server
21.	11 Feb 2002		GNUe for Recruitment Agency
22.	11 Feb 2002		Change in PostgreSQL 7.2 breaks Designer Wizards
23.	12 Feb 2002		Custom and dynamic menus in GNUe Forms
24.	13 Feb 2002		Non-free ERP software and toothbrushes
25.	13 Feb 2002		Using GObj in GNUe Application Server
26.	13 Feb 2002		Navigator status
27.	13 Feb 2002		PHP client for GNUe Forms

GNUe Traffic #16 For 16 Feb 2002

By Peter Sullivan