GNUe Traffic #63 For 11�Jan�2003

Editor: Peter Sullivan

By Arturas Kriukovas �and� Peter Sullivan

"GNUe Common is what gives a GNUe Jedi his power. It's an code base created by an AI. It surrounds us and penatrates us. It binds the GNUe Framework togethter."

Table Of Contents

• Printer-Friendly Format
• Text Format
• XML Source
• Introduction
• Threads Covered

  1.	1�Jan�2003		Project PAPO and GNUe
  2.	3�Jan�2003		SKUs in GNUe Small Business
  3.	3�Jan�2003		Converting forms to new .gfd format
  4.	5�Jan�2003		Format Masks in GNUe
  5.	5�Jan�2003		Triggers in GNUe Reports
  6.	5�Jan�2003		Using Reports to produce customer invoices as PDFs
  7.	6�Jan�2003		Bayonne, the GNU telephony project
  8.	6�Jan�2003		Application Server API
  9.	7�Jan�2003		Getting started with GNUe Forms

Introduction

This Cousin covers the three main mailing lists for the GNU Enterprise project, plus the #gnuenterprise IRC channel. Kernel Cousins GNUe is now group-authored: if you'd like to join the team, let us know.

1. Project PAPO and GNUe

1�Jan�2003�Archive Link: "[IRC] 02 Jan 2003"

Summary By Peter Sullivan

People: Marcos Dione,�James Thompson,�Derek Neighbors,�Federico Heinz

Referring back to Issue�#56, Section�#13� (14�Nov�2002:�Merging GNUe and Papo CVS code) , Marcos Dione (StyXman) asked "does anybody knows about the inclussion of features implemented in our patch into gnue?" James Thompson (jamest) said "i'm still working on it" . He had been "hoping to get to over the holidays" but was now hoping to start this week.

Later, Marcos asked "did you hacked anything in the way of <form style="dialog" />" , as discussed in Issue�#61, Section�#8� (22�Dec�2002:�Dialog boxes in Forms returning parameters) . James said "a fair bit of the work is done" - "i just need to make some more adjustsment to the UI" . Marcos asked for any hints as to how this would work - "I need to either reproduce it or backport it when is done." James said there would be radical technical changes - "I wouldn't reimplement - if you can give me the time <dialog> was to be able to replace your genericBox - i planed on that being a dynamically created <dialog>" .

Derek Neighbors (revDeke) said "no offense if you would use official cvs you would save a LOT of time" . James pointed out that papo were still using their own CVS as "I'm still trying to merge their changes up stream so they can migrate up" . Derek said "that was my point - it takes time away from adding new features to try to sync with them - and then they out of sync again" . He "isnt overly concerned from a gnue standpoint, just would like to help papo out by giving a consistent tree" - but the "gnue team cant constantly spend time trying to resync" . Marcos said that, for some time, "we (almost) stopped to add features to our cvs ('cept for bug fixes)" .

Marcos added "I guess we'll have our cvs anyways, as we have functionality that will never get into gnue. unless there were other ways to introduce them, like delegation in the db arch" , as discussed in Issue�#50, Section�#3� (2�Oct�2002:�Adding delegates support to GNUe Common) . Derek said "so what you are saying is you want a fork" . Marcos disagreed - "it's the last thing we want." Derek said "well if you have your own cvs you have a fork" - "it might be a minor fork but a fork none the less" . He felt that GNUe had "bent over backwards to apply patches that you would stop using your own cvs so we wouldnt have such headaches" . James said "we're not fast enough for their business needs - that's all - i mean it's been weeks/months(?)" Derek said "well its a two edge sword - you have dialogs almost done and styxman will spend two weeks implementing or back port - so whom is slowing whom down" ? Applying patches generated from papo's CVS back into the main GNUe CVS was time-consuming, and was only really worth it if papo were intending to use GNUe's CVS in the future.

Federico Heinz (perlhead) said "We most definitely *don't* want to fork. We're doing our best to work with what we currently have." Derek emphasised that he was not opposed to forking - "there are two types of forks - a pure fork... we make foo, you want to go right i want to go left and we fork - and - a mild fork, we make foo, you want to go right, we want to go right, you want to dress in red, we want to dress in blue - in a mild fork it makes sense to 'share' as much as possible - as things are going same direction." He "would rather see papo just use gnue and drop own cvs" but "understands business requirements and timelines" . However, "just like in a data conversion if you continue entering data in old system you will never cut over to the new one" .

He felt that "this dialog sample proves as well - there is functionality that might come into our cvs you want - and its murder for you to back port it." However, "if dialogs will take you 2 weeks to do - and its in our system - and if it takes two weeks to get cvs head to give you proper functionality" , then there was no issue as the work could be done in GNUe's CVS directly "and you are in sync - /me isnt saying thats the case - but you have to look at such trade offs" . Federico said that getting the papo CVS in sync with GNUe's would take much longer than two weeks - Marcos had "played catch up for quite a while in nov/dec, and he never got anywhere near the head branch." Derek felt that the only way to re-sync was "to check out our cvs - then add the functionality to it thats missing and submit as patches - one patch per functionality - not a giant patch - a. that will minimize amount of wait time you would incur from us - b. that ensures our cvs does what you need - in the mean time stop adding stuff to your cvs" . Federico said that the "Problem is, as I understand it, that if we do that, our stuff STOPS WORKING. And we must have a widely deployable version in two months. Debugged and tested." Derek said "well then i would say it behooves you to do ASAP - unless you forever want a fork - as if you deploy you will NEVER get back to our cvs - as you will never be able to 'stop' adding features to sync up. Again im not saying you must do this, or even necessarily that you should do this - that is up to you - just be forewarned we wont take patches created from a cvs other than our own" . Marcos did not think there was actually much difference in functionality. Federico agreed - "there's not actually that much more that we need... just now, a few UI things, and then we can rest." Derek warned that the forthcoming changes to the GNUe Forms Definition format (.gfd) in version 0.5.0 would make papo's CVS "incompatiable going forward without MAJOR work on your tree" .

Marcos noted that there were some changes in papo's CVS that "won't get into gnue ever. and we know that." Derek said "for somethings like that if one off deals you could treat like" patches to the Linux kernel, "where its a 'mini fork' for specific functionality" . Federico agreed, but said that the bigger issue was "We have stuff we need, and that GNUe wants but does not yet have in HEAD." Marcos said that, as papo had several devlopers, they would still want to have a CVS even if just for version control on their own patches.

Federico fully appreciated Derek's point about ideally merging CVS before papo did a wider release, but "it's a financing thing" - "if we get a solution that *works* by march, we get the funding we need to continue work, and that work goes according to *our* schedule." Derek could relate to that, but warned "if you dont make papo tree like 0.5.0 it will be an utter bitch for you to back port any new functionality we put in" . He appreciated that papo "have always been more than eager to share their improvements, i want to make it abundantly clear the gripe is not that they want to fork gnue and not give back - its more that applying patches is utter hell, because they are created off a cvs tree other than our own and in masse" . Federico said that the funding situation "means that we *will* do some shit twice, which we could have gotten right the first time. But if doing so will cost us our release date, we won't even get to the point where we can get it right once." Derek agreed - "the question is does it outweigh what it will cost you to merge the other stuff over" later? Once all of the papo patches from November had been applied, "our cvs head after those patches might not be all that radiacally different feature wise - anywho its up to you guys to decide whats best for you" . Federico said that papo's clients were not that used to software development cycles - they were "Sustainable development organizations, mostly." - "They have great trust in us, and we do all in our power to keep that trust."

2. SKUs in GNUe Small Business

3�Jan�2003�Archive Link: "[IRC] 04 Jan 2003"

Summary By Peter Sullivan

Topics: Small Business

People: Mike Vincent,�Derek Neighbors

Further to Issue�#59, Section�#14� (8�Dec�2002:�GNUe Small Business and demo application for GNUe) , Mike Vincent (Vee2d2) said he had "been thinking about the SKU thing.. I can imagine 3 ways to organize a" Stock Keeping Unit (SKU) - "1) Simple serialized number which is N digits long. 2) A number with N segments one or more of which are a serialized number and one or more are derived from predefined lookup tables and 3) a segmented number completely derived from lookup tables" . Segments could either have "a predefined padded length" or be "delimited with or without a contraint on their length/scope." If "there was a way to configure how a SKU were established, then you could use that information to create your forms to manipulate them based on that configuration." This meta-data could be queried to build the "form according to the data extrapolated. Descriptions would be labels, if the segment was a lookup a dropdown could be created, etc.."

Derek Neighbors (derek) said the "way i planned on doing it was drop downs and triggers - you selected the 'categories' or such that generate the numbers" . He added "i really think making a dynamic form is a bad solution - at least in the gnue world. Maybe for gnue proper - but getting sku numbers that complex in gnue-sb i think is over kill." The main requirement for his clients was to be able to generate new SKU for new items using pre-existing categories from drop-down lists, but also use SKUs that did not fit the standard pattern - "i.e. the sku# is a free form field - but you can use the categories to generate a number" . His users would typically have three levels of category. Mike said that, with too many segments, this could "would create very large numbers and very large numbers are hard to manage outside of the computer." However, as "if I were a consultant this could be a bonus to be able to adapt to a running system rather than expect a migration if things didnt fit." His "numbers are completely derived from lookup tables and are in 5 segments/categories" .

3. Converting forms to new .gfd format

3�Jan�2003�Archive Link: "[IRC] 04 Jan 2003"

Summary By Peter Sullivan

People: Marcos Dione,�Dmitry Sorokin,�Jason Cater,�ra3vat

Marcos Dione (StyXman) asked "how should I use the .04to0.5 conversor?" Dmitry Sorokin (ra3vat) said "run it with your form as param - old form will be saved with <name>-PRE050 name" . The conversion routine, which was designed to convert GNUe Form Definitions (.gfd) from the format used in version 0.4.x and earlier to the new format that split the logic and the display, was not completely automatic, but "in most cases mine worked" . Marcos said "ok, I'll finish the file by hand" . Later, Jason Cater explained that the syntax for the conversion script was "gfd04to05.py <source.gfd> [<destination.gfd>] - if you specify two names on the command line, then the second one is the output name and the first one is left unchanged - if you only specify one form, then the original is renamed and the new one is created in its place" .

Earlier, Marcos reported various errors trying to run a converted form, most of which seemed to be caused by the convertor putting "all my buttons in the logic part" . This was a very simple form, just with a few buttons. He wondered if this was the problem - "can a form have no logic?" Jason asked "do you have a <button> as a child of a <block> ??" . Marcos said this was true of "all the buttons" . Jason said that the conversion script was not "accounting for buttons in blocks" . Marcos confessed "we have more complicated things like that. boxes inside boxes inside blocks and so on. would that be 'wrong'?" Jason said "well, the converter won't support it - nor will" the CVS head version of GNUe Forms - "I'm not sure what it will do" .

Dmitry and Marcos concluded that the new format .gfds always had to have a <logic> section - at a minimum, this had to contain a <block> tag to specify which datasource to use. The conversion script would fail with very simple forms that had no datasource, but converted forms could then be made to work by manually adding a dummy datasource - Marcos noted that "tmpDataSource is valid" .

Marcos asked about containers for widgets. Jason said "we haven't implemented containers yet - in the old version or the new - with the exception of a <page>" . Marcos said "I sent a patch for that one a looong time ago and it almos got in, but it was disabled for 0.4.0 release, AFAIK" . Jason explained "it broke a lot of existing forms - when applying I thought it was backward compatable - but I haven't had time to correct it" . He thought "we are leaning to not having a dual function <box> tag, but an actual container tag of sorts - but I'm not 100% sure what we want to do there yet" .

Dmitry asked "where should trigger be tied to field tag in logic or entry tag in layout? what's the difference if both ways are possible?" Jason said "there's not a 1:1 relationship between a field (logic) and an entry (layout)... there's a 1:many. most of the time you'd probably want to do a <field> trigger" . He confirmed that on-change triggers should exist for field tags, as for entry tags.

4. Format Masks in GNUe

5�Jan�2003�Archive Link: "[IRC] 06 Jan 2003"

Summary By Arturas Kriukovas

Topics: Forms, Common

People: Marcos Dione,�James Thompson,�Mike Vincent,�Jason Cater,�ra3vat,�Dmitry Sorokin

Marcos Dione (StyXman) asked Dmitry Sorokin (ra3vat) whether he knew what was the supposed semantics for the different masks (display, input, format). Marcos needed them "to show just a few decimal but keeping all the decimals internally." James Thompson (jamest) was afraid "that's up in the air right now IIRC" . Marcos said he "just want to know if I should implement displaymask or format mask. and what will be the use in thew future." James thought "there is already work done on format masks, it's already in the code base but not in use IIRC" . Marcos raised another question: "ok, let's do the question in a better way (I hope): what are display, input and format mask for? Especially, the difference between display and format? Input seems rather clear." James noted that his answer came only from memory: "fields can display differently when you edit them vs when you're not in them. The best place to see this is in a date field, as IIRC it's the furthest along. When you enter the field, 2003/01/06 may be displayed for editing. When you exit it may flip to read "Monday, Jan. 6th 2003". I _think_ display is non editing and format is editing, but again, I'm not sure." Marcos replied - "it sounds to me, but I may be wrong, that display is for showing (Mon, Jan 6th 2003), input for input (2003/01/06), and format for internal representation (20030106)" and James, on the whole, agreed: "that could very well be. I think that 2 of the 3 are in use and the 3rd one is pending proper setup of the format definition. The best source of info on this would be jason." Mike Vincent (Vee2d2) noted that "there's a bit of information in the forms dev guide (.5) pg 24.. but the only thing documented is datetime."

Later, Marcos caught Jason Cater (jcater) and he answered immediately: masks "don't work. That's part of 0.5" . However, Marcos was also interested "what are they exactly for. I mean, de dev-guide talks about display and input masks, what is format for?" Jason was still wondering if GNUe needed the "format" mask. "Input mask --> when field is in input mode, the mask used to validated/let the user enter the value, display mask --> how the field is displayed when user is not editing it, format mask --> (if there's a need) how the field is actually stored in the database" .

5. Triggers in GNUe Reports

5�Jan�2003�Archive Link: "[IRC] 06 Jan 2003"

Summary By Arturas Kriukovas

Topics: Reports

People: Dmitry Sorokin,�James Thompson,�ra3vat

Dmitry Sorokin (ra3vat) enquired "is it possible to do something like colspan in reports?" (in general, in native xml report format). James Thompson (jamest) offered using "simple tabulation, just put in empty column defs <out:col/>" . Dmitry was trying "to do simple text output that fit with 80 chars screen to be send by email. It'd be great to split one output db row on two rows in report ans span wide cells if needed" . James thought that "with a little effort you might be able to get a trigger to do it, but the trigger support in reports is functional bu not complete. I would think some type of post-change trigger on a field that split the data and stored in 2 non-bound fields would do it" . Dmitry asked "how to reach different report objects from report trigger" ? James said that "they should be able to be referenced by name report.fieldName" . There were no examples on this as of time of writing, because it seems that no one had used triggers in reports. James expected to write an example sometime later the same week.

6. Using Reports to produce customer invoices as PDFs

5�Jan�2003�Archive Link: "[IRC] 06 Jan 2003"

Summary By Peter Sullivan

Topics: Reports

People: James Thompson

James Thompson (jamest) spoke about a practical use of GNUe Reports from his own organisation - "i took some sample code jason wrote for Oracle Reports/zope/php and reworked using GNUe Reports/Zope(with ZShellScripts). It takes an RTF template of an invoice, merges it against data in the rdbms, and pumps out a pdf file via a web site so customers can lookup past invoices. what's cool is if the people this is for use it for initialy printing their snail mail invoices then they will be the exact same as the pdf" .

7. Bayonne, the GNU telephony project

6�Jan�2003�Archive Link: "[IRC] 07 Jan 2003"

Summary By Peter Sullivan

People: Dan Bethe,�Daniel Baumann,�Dmitry Sorokin,�John Lenton,�ra3vat

Dan Bethe (dtm) reported a possible lead for someone looking "to move to Bayonne on a totally shoestring budget. probably can't even afford new hardware, still using ISA phone cards ;)" . Bayonne now had a demo mode that could run on an ordinary sound card "so you can test your bayonne apps" . Daniel Baumann (chillywilly) suggested "do you call up custumers and yell, "show me the money!!!" - cause that would be the cool way to collect on accounts payable ;)" . Dmitry Sorokin (ra3vat) asked "what will be lost in that "testing" mode - /me owns a coulpe of sound cards and a heap of old soldering parts too" . Dan said "it can't make phone calls obviously - you can just listen, and the software will function. as it can be very expensive or difficult to test on live equipment like a T1" . Dmitry felt that might not necessarily be the case - "we have to find one 2400 modem to make a phone call" . Dan confirmed that, for a basic but useful Bayonne installation, "your 2400 bps modem can be your call center" - as long as it could "do voice ;)" . John Lenton (Chipaca) asked "what exactly can bayonne do? is it just a call center thing? or is it anything else?" Dan pointed to the website, suggesting "go ahead and take a look - it's the best IVR on the planet! Think of it as the apache of telephony - takes virtually any type of telephony device and turns it into a call center, an IVR, voicemail server, etc" . John asked whether "IVR is an interactive voice racoon?" After a series of various racoon jokes, Dan explained "IVR == interactive voice response - i.e. a menu with prompts and often voicemail - "thank you for calling XXX. press 1 for sales, 2 for collections, and 3 to troutslap chilly"" . Daniel Baumann (chillywilly) urged everyone to "pick 3! pick 3!" .

8. Application Server API

6�Jan�2003�Archive Link: "[IRC] 07 Jan 2003"

Summary By Peter Sullivan

People: Reinhard M�ller

Reinhard M�ller (reinhard) announced that the "new Appserver API is fully implemented - we now need - * somebody who makes the RPC around this work - * a dbdriver for forms that uses the new api" . Actually, "it means that most of the api calls in usual cases have a result that is very close to what it should be ;-) - but it should be enough to build upon" .

9. Getting started with GNUe Forms

7�Jan�2003�Archive Link: "[IRC] 08 Jan 2003"

Summary By Peter Sullivan

Topics: Forms, Designer

People: Jason Cater,�Anthony Lenton,�Dmitry Sorokin,�John Lenton,�Derek Neighbors,�ra3vat

Anthony Lenton (aa_) queried an entry in the XML DTD for GNUe Forms, which did not seem to work when he tried it. He was using the latest CVS version. Jason Cater (jcater) said "in cvs, the gfd format is changing somewhat - I guess the DTD needs to be regenerated" . He explained "we have moved the layout management to use a separate namespace - this is so we can migrate to supporting multiple layout mechanisms w/in the same form i.e., absolute positioning, grid layout, gridbag, etc. I think the "creating your first form" chapter in that pdf shows this - but because the layout stuff (x,y,width, height) is now in a separate namespace a separate dtd would be needed" .

Anthony read the Developers' Guide, with details of the new format, and typed in the sample, which he could not get to work. "It exits with ' Entry references non-existent field 'zipcode' I set up the db as is suggested. The field really honestly does exist" . Dmitry Sorokin (ra3vat) suggested "start with more simple example that does not require db" . Anthony "tried to remove all entries from the same example. It exited with 'There are no navigable widgets in this form. Unable to display." Later, Derek Neighbors (revDeke) confirmed this error message was as expected - a form had to have at least one entry field, but not necessarily tied to a database. John Lenton (Chipaca) confirmed that Anthony's connections.conf settings were correct, "and with --debug-level it says it's reading the right connections.conf" .

Dmitry suggested "if desingner is not broken you can easily build a simple form with wizard - and wizard will allow you explore your conncetions.conf file (choose datasource or db) and db tables when choosing particular columns" . Anthony reported that the Designer seemed to work fine, but the Run-Form menu option from within Designer bombed out. Dmitry suggested saving the form, and running it from GNUe Forms directly. Derek said "have you confirmed that forms works at all? If not, please run samples/intro/intro.gfd first to confirm that it functions properly - if it does then lets get a database form working" . Anthony confirmed that "ok! intro.gfd works fine - i'll take a look at how that works and move on from there" . Derek explained that "there is a HUGE jump from non datasource to datasource forms - and fortunately or unfortunately a lot can go wrong with datasource forms that have NOTHING to do with gnue - i.e. database or database driver misconfiguration - so we like to use a dataless form to get a 'quick' view of whether forms itself is working" .

�

�

�

�

�

�

Sharon And Joy
�