GNUe Traffic #33 For 15 Jun 2002
By Peter Sullivan
/me thinks double entry book-keeping is a bit like XML - when you first look at
it, you think it's over-fussy and precise but the more you get into it the more
you relalise the power you have by placing restrictions on yourself - actually,
that probably describes the GPL pretty much as well
Table Of Contents
* Standard Format
* Text Format
* XML Source
* Introduction
* Threads Covered
1. 5 Jun 2002 - 6 Jun 2002 (4 Layout manager for GNUe Forms
posts)
2. 5 Jun 2002 Changing widget attributes at run time
3. 5 Jun 2002 Using tags to support optional
widgets
4. 5 Jun 2002 Multi-select widget in Forms
5. 5 Jun 2002 GNUe Navigator development and testing
6. 6 Jun 2002 Nola as an alternative to GNUe
Financials for fund accounting
7. 6 Jun 2002 Re-coding or re-using GNU-RPC on other
projects
8. 7 Jun 2002 Free accounting packages for SMEs and
Chart of Accounts design
9. 7 Jun 2002 Free Java
10. 7 Jun 2002 - 10 Jun 2002 DCL - more than just a bug tracking
system
11. 7 Jun 2002 GNUe Application Server API
12. 9 Jun 2002 - 11 Jun 2002 Problems with floating point fields in
PostgreSQL
13. 9 Jun 2002 Developing and testing GNUe
14. 9 Jun 2002 Updating dropdown entry lists within
Forms
15. 9 Jun 2002 Scrollbars for grids
16. 10 Jun 2002 Perl and GNUe
17. 10 Jun 2002 Properties box in GNUe Designer
18. 10 Jun 2002 Defining the dependancies between GNUe
Packages
19. 11 Jun 2002 Widgets on resized forms
20. 11 Jun 2002 Entering null values in numeric fields
21. 11 Jun 2002 Creating a fixed number of child
records for a parent
22. 11 Jun 2002 Using docstrings in python
Introduction
This Cousin covers the three main mailing lists for the GNU Enterprise project,
gnue (http://mail.gnu.org/mailman/listinfo/gnue) , gnue-dev (http://
mail.gnu.org/mailman/listinfo/gnue-dev) and gnue-announce (http://mail.gnu.org/
mailman/listinfo/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 (http://www.gnuenterprise.org/irc-logs/) . For more information
about the GNU Enterprise project, see their home page at http://
www.gnuenterprise.org (http://www.gnuenterprise.org) .
1. Layout manager for GNUe Forms
5 Jun 2002 - 6 Jun 2002 (4 posts) Archive Link: "[gnue-dev] Layout Management
and Forms"
Topics: Forms, Designer, Reports
People: Jason Cater, John Lenton, Derek Neighbors
Jason Cater said that layout management was not a priority issue for the "core
forms team (myself included)" , as they were happy to use absolute "x,y
positioning" . However, other people were interested in layout management, so
there needed to be discussion about the best way of supporting this without
cluttering "up the forms code or the forms GFParser with support for all the
different layout management styles." His proposal was to "Remove ANY
positioning tags/attributes from the basic Forms XML schema and implement all
positioning using Layout Adapters, qualified by an XML namespace in the XML
file" , and he gave some examples. He suggested "A few layout engine adapters
would be part of the core GNUe distribution and would always be available.
Official apps could only use these core adapters, which of course initially
would only be Character (x,y) positioning." . This approach:
* removes positioning ugliness from the forms code and puts it in the Layout
Adapter code.
* allows us to keep our current absolute positioning that has worked so well.
* allows anyone who feels they need more than absolute positioning to write
an adapter for their positioning logic without needing access to the forms
internals.
It would, however, "break any existing forms. This could be alleviated by
adding code in GFObjects that implicitly converts" from the old to the new
format, both in Forms and Designer.
He also suggested that the Layout manager concept "might also be useful in
Reports" but he had not really thought that through yet.
John Lenton suggested using Cascading Style Sheets (CSS), "because they give us
a separate, orthogonal namespace in which to talk about attributes of the
widgets and stuff we define in the XML. So do namespaces, but IMHO CSS is
cleaner" . He gave several possible file formats. Also, if a designer did use
"the 'old-style' absolute positioning attributes" , this would need to be
handled consistently too. However, he understood why layout managers was not a
priority at the moment.
On IRC (http://www.gnuenterprise.org/irc-logs/gnue-public.log.07Jun2002) ,
Derek Neighbors (dneighbo) said "at first my gut reaction was what does css
have to do with layout - but the more i thought about it, it might not be an
all bad idea - as it might address my concern on how to make 'web applications'
that dont look normal forms embedded in a browser" . John (Chipaca) said that
the whole point of CSS was "to separate design from content - if the idea is
that one same form should be able to be layed out in different ways, then CSS
it is." Jason (jcater) said "define "different ways" - as I'm not sure we were
talking same thing in the emails to the list" . What he was looking for was
"adding layout engine support to the GFDs - i.e., allow developers to use
GridBag layouts if they want instead of absolute" but "the developer would
still have to choose which engine he wanted to use - and code the form
accordingly" . Derek said "i think what im thinking that CSS adds is layout
separate from gfd - i.e. i slap widgets and such down in the .gfd then let the
CSS (or somethign similar) define how they are placed and such" . Jason said he
thought "CSS could complement what I'm after - but I still think they are
addressing different issues" . Derek said "well layout is relative - mainly i
dont want something that looks like a gnue form in the middle of my website/
ecommerce site etc - i watn it to integrate into my marketing look" . The GNUe
Forms Definition and Jason's layout manager "handles the 'base' layout of where
thigns belong in a general sense - and a CSS allows by target to define some
additional things" . Jason said he was "not opposed to this - but I think it is
separate from what I'm trying to accomplish" .
John asked how the layout manager would work - "Do you need entities to do it?"
If so, then XML namespaces would be needed. Jason said that "absolute
positioning will use attributes" as at present - other layout managers might
need to use entities, but he personally was only interested in the absolute
positioning layout manager. He emphasised that "I don't want any layout logic
in" the GNUe Forms parser code. He wondered "if there are any CSS parsers for
Python" . John mentioned "XIST" .
Later, John noted that Jason's proposal would allow the developer to change
layouts, but not the end user. Jason said that was a different topic - "we are
not talking "what color will this widget be?", "what size will this font be?""
but the fundamental underlying layout of the form, which had to be the
developer's responsibility. Derek said that, with web-enabled applications, you
might want to split form/logical design from layout design. He agreed with
Jason that there were two separate issues here, but hoped there might be a
clever way of resolving both of them together or in similar ways. Jason said
"even if you separate layout logic into separate files, you have to have a way
to denote the relations between the locations of the objects" . He agreed "we
should be able to support multiple "layouts" of the same form using the same
GFD - but I'm trying to address how to denote the layout (wherever that layout
is located)" .
2. Changing widget attributes at run time
5 Jun 2002 Archive Link: "[IRC] 06 Jun 2002"
Topics: Forms
People: James Thompson, Marcos Dione
Continuing Issue #32, Section #9 (30 May 2002: Customising the main tool bar
and menu bar in Forms) , James Thompson (jamest) said that Marcos' supressible
toolbar widget was similar to ideas he had had - "i wanted to add visible
attributes to lots of stuff in forms" including the toolbar. This would allow
the toolbar to be switched on and off using triggers, and "hiding a toolbar
would have same syntax as hiding a entry widget - consistancy is a good thing
:)" Marcos Dione (StyXMan) asked "why wait till code is run? set the toolbar
optional by tag or attr. Easier, and more consistent for the developer." James
explained "because all the other widgets will work like this too" . Marcos
certainly liked the idea of being "able to do things to widgets @ runtime" -
not just visible/invisible, but also enable/disable. James said that Marcos'
"work w/ the toolbar would make this easy to implement" . Marcos explained how
this would work, but noted "defining your own menubar must be done by xml, not
triggers." James said that "the self attribute in triggers" was not currently
working, which made triggers and trigger libraries less useful "if they have to
have hardcoded references" . However, it had been some time since he had looked
at this.
3. Using tags to support optional widgets
5 Jun 2002 Archive Link: "[IRC] 06 Jun 2002"
Topics: Forms
People: James Thompson, Jason Cater, Marcos Dione, Michael Maluck
Reprising Issue #32, Section #29 (4 Jun 2002: Maintaining UI independance
whilst allowing custom widgets) , Marcos Dione (StyXman) said he was not keen
on using the XML tag to hook in non-standard widgets - he would prefer
to use attributes on tags, or even allow new tags for new widgets. James
Thompson (jamest) said that GNUe Form Definition (.gfd) files used to support
"attributes in several different" ways - both " or
foo " had been supported - however, "we
ended up scrapping that old way" . Also, the tag had at one stage been
used for multi-line code like triggers "however triggers ended up different
anyway :)" . Jason Cater (jcater) noted, however, that tags were still
used to "assign non-standard properties to objects in forms that can be
retrieved in triggers - that's why I don't want to get rid of options"
completely. He agreed, however, that "in the cases where an option replaced a
standard tag, I've never been really thrilled" .
Marcos understood the need to keep the tag for this, but did not see
how it would link to the GFOption object that would handle it - as there was
usually a one-to-one relationship between Forms XML tags and Forms objects.
Jason said the tag worked differently - "all objects have a getOption
() method that retrieves any s set on it - so basically, any
non-standard attributes would be options" . However, "there will actually be a
GFOption object implicitly created" .
Marcos asked how the and tags would interact - "I realize
that is for gouping s together - but how does a
gets related to its parent?" . The GNUe Forms Parser code implied that all
tags were children of the tag, which was a child of the
overall tag. Jason said "the GFParser file isn't quite correct."
Michael Maluck (madlocke) re-expressed his preference for "a way to add new
tags" for new widgets " but still being able to create valid dtds" , as this
would make the XML more understandable. He was not sure how this would work,
however - it might be better to "delete all options, because options force men
to make up decisions ;)" He said "it's like with mirrors... when you look into
it, it will always show you. you can't tell the mirror to show something you
want to see. there is actually no option ;) - but ok you have the option to
destroy the mirror ;)" Marcos felt "wowo, that was deep. you'll teach me zen?"
.
Later, Marcos said that, for common s such as tooltips, having to
re-write the code to handle it each time would be a pain - "you'll try to move
the tooltip code to a class" , and part of the core widgets. Other s
would be more one-offs. "I guess the answer is: no, don't do it in general.
that's what jcater or jamest said yesterday - do it case by case" . Michael
said "i understand their complaints about new tags/attrs that are not in the
core very good" , and he needed to give some more thought to the best way of
allowing optional widgets - he did not want to end up with unofficial patches
or an unsupported fork.
4. Multi-select widget in Forms
5 Jun 2002 Archive Link: "[IRC] 06 Jun 2002"
Topics: Forms
People: Marcos Dione, Jason Cater, James Thompson, Derek Neighbors, John Lenton
Marcos Dione (StyXman) asked if there was a "multiselect widget" . Jason Cater
(jcater) said "not yet" . He added "we need to think thru how we want it
handled - it'd be a block style" . Marcos did not see why - he was talking
about being able to select multiple records for a single field. Jason said he
was "thinking of "fallback" - i.e., what would a UI driver fall back to if it
doesn't support this nifty new feature" , especially how you would "tie that
directly to a datasource?" .
James Thompson (jamest) said that "the one thing that sucks about putting it in
a block is navigation - as I have a similar need that I do via a block of
dropdowns" . Jason said "I need something similar too - so I'm not arguing
against such a thing" . Derek Neighbors (dneighbo) said he thought a good form
dialog was more important, as "i dont need the multi select really 'in' a form
but rather as a 'utility' to rapidly assign data" , creating many to many
relationships between the primary keys of two tables via a switch table - "once
assigned it can be displayed in grid" . Derek and Marcos traded some practical
examples of this. Marcos said, in his particular case, he "would prefer a
muktiselect list box" as "the options are just a few in this particular case" .
John Lenton (Chipaca) suggested "if they're really few, surely checkboxes are
better?" . Marcos said that checkboxes existed, but it was not always easy to
get the data back in the database from these.
The next day (http://www.gnuenterprise.org/irc-logs/gnue-public.log.07Jun2002)
, Marcos said "I'm gonna do a listbox" , and asked "should I just extend entry
or better to add a new class?" . James confirmed that all the entry widgets
were "all tags with a style" . Marcos said the box would start off
single-select, but would eventually support multi-select.
5. GNUe Navigator development and testing
5 Jun 2002 Archive Link: "[IRC] 06 Jun 2002"
Topics: Navigator
People: Derek Neighbors, James Thompson, Jason Cater, Bajusz Tam?s
Derek Neighbors (derek) did some testing of Navigator. James Thompson (jamest)
noted that menu line entries in the GNUe Process Definition (.gpd) file - the
standard file format for Navigator - now supported both and
<description> tags. He confirmed that using Navigator to launch both Reports
and non-GNUe applications was still supported. Derek noted that "image works
now - about box doesnt work" . James said the "menu doesn't work yet at all -
it's only there for looks at this time :)" Navigator also "does single login
for multiple forms - which is nice" .
Later, Derek posted some screenshots to the website for the " navigator open
screen (http://www.gnuenterprise.org/modules.php?op=modload&name=NS-My_eGallery
&file=index&do=showpic&pid=40) " and " navigator in actoin (http://
www.gnuenterprise.org/modules.php?op=modload&name=NS-My_eGallery&file=index&do=
showpic&pid=41) " . Jason Cater (jcater) said that the web version of Navigator
"should be working" but he had not "tested it out in last day or two" . It was
not as advanced as the Navigator full client yet, however.
The next day (http://www.gnuenterprise.org/irc-logs/gnue-public.log.07Jun2002)
Bajusz Tam?s (btami) asked "is there any special reason navigator uses
treecontrol instead of classic menus? in a main window?" . He explained "some
users (accountants) hate using mouse - and a main window with menus is maybe
simpler" . James Thompson (jamest) said that "the tree can be navigated via the
cursor keys - and we're just trying things out to see what people think" .
Bajusz said that he did not like having two windows - one for Navigator and one
for the form. James explained "navigator can launch forms, reports, executables
- anything you want really - I have mine here launching IIRC perl scripts" . He
added "just remember though we're still very much so playing - so if you want
to see something just describe it" . His users needed to be able to "have
multiple forms open at same time" , which is why he personally preferred the
new layout to earlier versions of Navigator. Bajusz suggested "1 main window
with menubar(navigator) - and forms,reports are the child windows in it - like
excel opened with more then one xls" . James thought this was "an interesting
idea - may have to do some more playing" . He noted that "navigator takes ui
drivers - so nothing prevents us from making something like that in it's own
UIwxmdi.py" . He said "the entire UI system is under reworking - we need to
start a wishlist" as "I really would like to get most the UI stuff nailed down
this next release" .
Later, Derek Neighbors (dneighbo) thought Navigator was "giong good though im
not sure of two things - a. why its dual paned - b. that we cant make gpd's
load into menus if we so desire" . This second option would be useful for
curses (text-only) users "or people really liking deep ugly menus :)" .
6. Nola as an alternative to GNUe Financials for fund accounting
6 Jun 2002 Archive Link: "[IRC] 07 Jun 2002"
Topics: Financials (Accounting)
People: Andrew Mitchell, Derek Neighbors, Peter Sullivan
Andrew Mitchell (ajmitch) asked "anyone know of any small/medium business
accounting software" ? Derek Neighbors (dneighbo) suggested "nola - its not
gnue but well - its accounting that looks promising to do some gnue stuff too"
. Peter Sullivan, remembering Issue #26, Section #7 (21 Apr 2002: Nola - free
alternative to GNUe Financials?) said that Nola was "a LAMP application (Linux,
Apache, MySQL, php) - screenshots look moderately sophisticated (but then so do
ours) - jcater downloaded for a look-see, you might want to ask him when he
wakes" . He noted that "there's an online demo" on their website (http://
nola.noguska.com/main.html) . He felt the "look and feel isn't terrible, isn't
wonderful - and being GPL gets you lots of gold stars in my book ;-)" . Andrew
said he "would still like something GNUeish tho - web-based is ok but not ideal
for things like printing reports, invoices, etc" .
Andrew said he "doesn't like NOLA's UI that much" . Peter felt it was "LAMPish"
. Andrew said that "DCL could be called LAMPish, but i think it has a better UI
- so does phpGW" . Derek said that "nola is far from perfect BUT i think its
far enough that its a decent start - and it would be worth building gnue
screens for and such" . He would "probably get gnue screens for it" .
Derek said he would probably do some work on Nola to "make it support fund
accounting" , so that you could record separate funds "with self balancing set
of accounts - usually used to observe some restriction or limitation of
resources" . This was a fairly common requirement in the US government sector,
but he would be using it for church accounts, where there were separate funds
for different church purposes - "only instead of having a ton of bank accounts
you have paper (or virtual) ones" . Peter said he had seen similar set-ups,
where "each directorate has own balance sheet - but the "Cash" figure is not
real cash - just their share of the central balance sheet" . Derek said
"generally every fund has assests, liabilities, fund balance" . Peter said "I
keep wavering as to whether this is a good idea" in cases where it was not a
statutory requirement, as "the control aspects can be done w/ good row
security" instead.
7. Re-coding or re-using GNU-RPC on other projects
6 Jun 2002 Archive Link: "[IRC] 07 Jun 2002"
Topics: Common
People: Dan Kuykendall, Jan Ischebeck, Jason Cater, Derek Neighbors, Dan Bethe
, Peter Sullivan, Bradley Kuhn
Dan Kuykendall (Seek3r) asked if there was any documentation on GComm
(GNU-RPC). Jan Ischebeck (siesel) said there was some preliminary documentation
in CVS. Dan said he was "building some code in php to support xml-rpc and soap
in much the same way. if you already have things defined then I can look at
doing mines much more like yours" . Jan said that, as of time of writing, it
was too early to decide "which functions should be made general available for
all drivers and which are private functions." Dan said "Im mostly concerned
with the basic functions developers wanting to the the GComm are supposed to
use. Like what they do to start the client, how they package up their params
(selecting data types), and how they make the calls, and then how the return
comes back. Ditto with creating a server. how they add functions, how they are
documented. If I can make mine look like a port. so that it basicly matches,
then it will be more generally consistant. Syntax will be a little diff because
of the diffs between python and php" . Jan said "ok, thats quite easy. the only
difference between python and php implementation will be" that python would
allow you to "just request an service object and then all method call on that
service object will be transparently executed on the server" as part of GComm.
Dan said he could "do the same with php" .
Jan said that, as of time of writing, "the api is quite simple: client: 1.
atach(interface,options) 2. request('servicename') 3. transparent calls" . As
it was not web-based, it used its "own socket port" . Dan said he could not do
this, "Since in PHP I am stateless. I have to wait for the web server to kick
me into life" . Jan did not think this was a problem - "It just means that you
have to parse the description file one time per method call ;) - or you keep a
preparsed file in a php file" .
Dan asked if GComm could detect incoming requests using different RPC
protocols, and select the appropriate driver. Dan and Jan worked through some
examples. Dan concluded that, in php, he would have to do direct access in a
different way to the python-based GComm. There might be problems detecting what
type of object was being sent, but "if they use this future GTypeCast, they
will be giving you an object that you can then get the type and data from" -
this could also be done in PHP. He asked if the data returned by an RPC request
was automatically converted into python variables. Jan confirmed this. Passing
multiple parameters to a function would have to be done differently in PHP to
python - although PHP version 4 could do it the python way, Dan needed to use
PHP version 3 for GPL compatibility. Jan said he would be prepared to change
the way the python-based GNU-RPC worked, provided "it doesn't means changing
heaps of code" .
Dan asked whether "GComm and GNUe RPC are two different things?" . Jason Cater
(jcater) said that "GComm was the original working name before any coding was
done" . It was now interchangeably referred to as GNUe Common, GNU-RPC or
GNUe-RPC. He emphasised that it was "only one implementation - the "standard"
or "proposal" can be called whatever - but our implementation I'd think we
would call GNUe-Something" . Dan confirmed he was "gonna try building a PHP
version today with the xml-rpc driver" for use on "the new web services I am
developing for DotGNU" .
Later, Derek Neighbors (dneighbo) said he did not "see the value in spending
time REPLICATING gnurpc for every language" but would prefer to "rather see
someone wrap the python so php could use it" . This was "not a python is right
everything else is wrong thing - its a why write same code over and over in
diff languages only to have to maintain it?" .
Dan Bethe (dtm) noted that Dan Kuykendall was "currently redesigning"
phpGroupware (phpgw) "somewhat to decouple the server and client and to make it
language neutral - not requiring php" . Dan K. was keen on working with GNUe,
but Dan B. felt there had been some communication issues. Peter Sullivan (psu_)
noted that "GNUe Common was named GNU-RPC precisely because it was meant to be
usable by other projects" . Dan B. said that Dan K. "still wants to collaborate
- and collaboration will probably be greatly enhanced by his rearchitecture" .
Derek noted that, although it was not quite the same issue as phpgw using
GNU-RPC, two separate people had started writing GNUe Forms clients in php,
"and after grokking common" decided to use (and in one case, help to develop)
that instead. It was much more than "merely data abstraction (ala PEAR or PERL
DBI or libGDA)" - "its complete programmer abstraction" including features
"like handling master detail relationships adn complex queries and foreign key
look ups and the such" . He felt that there were several ways of working with
phpgw, depending on what Dan K. wanted.
Peter noted that "we were going to make that one-off meeting in #gnuproject" (
Issue #5, Section #11 (26 Nov 2001: The GNU Project - Meeting of the Minds) )
"a regular thing - but everyone is too busy" . He had done a prototype web page
(http://www.manorcon.demon.co.uk/gnuproject.html) for it. Derek said "i will
look if i have time at this - and try to reconvene a meeting - as i think there
are several thigns for the agenda" . He was keen to keep the various
business-related GNU projects working together. One key issue was "where GNUe
is at with its rpc abstraction - as there is definitely prototype stuff there"
. Dan B. said that phpgw's recent change in architecture meant that they would
become more interested in "broad interoperability" . Derek said he needed to
speak to Bradley Kuhn.
8. Free accounting packages for SMEs and Chart of Accounts design
7 Jun 2002 Archive Link: "[IRC] 08 Jun 2002"
Topics: Financials (Accounting)
People: Nicholas Lee, Peter Sullivan
Nicholas Lee (esands) said he was not aware of any "SME open source business
(accounting) software avaliable at the moment" . He added "For myself I'm using
gnucash at the moment. Only thing else out there AFAIA is sql ledger and maybe
nopa. Not sure how good nopa is. There are all pretty hacky." . Peter Sullivan
(psu) said that a simple General Ledger (GL) would not take long to write, but
"a GL w/o Purchase and Sales Ledger is fairly pointless" . Nicholas said he
"was hoping gnue would be RAD enough for me to hack together some tools I could
us in my businesses. Not quite there yet." .
Nicholas agreed that "GL is pretty straight-forward. Dealing with the
complications of multiple GLs and business logic is obviously harder" . Peter
said that "GL is really just a big dustbin where you can store things to find
'em later - All the fuss over data warehousing - Accountants have had them for
years - we just called 'em General Ledger" . Nicholas felt "The operative word
is "hope" to find then later.... Isn;t it? ;)" Peter replied "not if you have a
good enough chart of accounts" . He personally "prefers Chart of Accounts
formats that cannot be depicted in real space - i.e. at least 4 dimmesnions of
analysis" . Nicholas said that, for small to medium enterprises (SMEs), a "4.2
code GL is good enough" . Peter suggested "keep the posting codes short - and
build the reporting logic via parent-child relationships - one less keystroke
on a million transactions is a million less keystrokes ;-)" Nicholas agreed -
especially "when I've been the one punching though codes at times. 8)" .
9. Free Java
7 Jun 2002 Archive Link: "[IRC] 08 Jun 2002"
Topics: Why GNUe?
People: Perry Lorier, Peter Sullivan
Reading Issue #32, Section #1 (27 May 2002: Freedom issues with using Compiere
as an alternative to GNUe) , Perry Lorier (Isomer) admitted he risked a large
debate, but asked "why people believe Java is so evil? there are GPL Java
compilers/runtimes no? you can write GPL Java code? /me fails to see why it's
non-free?" . Peter Sullivan (psu) said "you can wriite GPL Microsoft Acess -
but you still have a non-free dependancy" . He noted "well, there are
definantly no free Java compilers/runtimes - since to be Java, you have to be
licensed by Sun - but there may be "java-like" or "java-compatible" ones" .
10. DCL - more than just a bug tracking system
7 Jun 2002 - 10 Jun 2002 Archive Link: "[IRC] 08 Jun 2002"
Topics: DCL
People: Perry Lorier, Peter Sullivan, Derek Neighbors
Perry Lorier (Isomer) asked "are there any reasonably complete GNUe "apps"?" .
Peter Sullivan (psu) said that DCL was "part of the GNUe family but not yet
part of the GNUe architecture - although there are some GNUe Forms that work w/
it now it's still mainly a php app" . It started as a bug-tracking system, but
was "evolving into general project mgt / contact management / multi-user to do
list application" . The GNUe Project's DCL server was set up for read-only
guest access "if you want a look-see ;-)" .
Some days later (http://www.gnuenterprise.org/irc-logs/
gnue-public.log.11Jun2002) , it was asked whether DCL would be a drop in
program for a typical helpdesk. Derek Neighbors (derek) said "i think its a
stronger projects/work order system than a help desk - but i think it does
helpdesk ok - and you have the code :)" . GNUe and DCL had now merged (as
discussed in Issue #19, Section #14 (5 Mar 2002: GNUe/DCL merger announced) ),
and "currently we are gutting the contact management for next realease that
will be the base for a gnue crm that fsf will be using - already in cvs for
working version there are gnue screens" . He was also using GNUe Reports with
it as well. Later, he pointed to "a screenshot (http://gnuenterprise.org/
~dneighbo/service_request.png) of a gnue'ized dcl - going against production
dcl data" .
11. GNUe Application Server API
7 Jun 2002 Archive Link: "[IRC] 08 Jun 2002"
Topics: Application Server
People: Jan Ischebeck
It was asked why geasList had a geasSession field when geasInstance did not.
Jan Ischebeck (siesel) explained "because geasList needs access to geasSession
to get an GConnections object to create a list. geasInstance don't need that."
This meant that loading an instance or creating a new instance had to be done
"over the list object" . The reason for this was "to move the resultset / row
paradigm into an api. so you have to retrieve an object list, before you can
get single instances." He explained that the current release of Application
Server was "a (minimal features/as soon as possible production ready ) version
of appserver - I hope that the overnext version will support much part of ODMG
standart."
12. Problems with floating point fields in PostgreSQL
9 Jun 2002 - 11 Jun 2002 Archive Link: "[IRC] 10 Jun 2002"
Topics: Common
People: Marius Gedminas, Derek Neighbors, Jason Cater
Catching Derek Neighbors (dneighbo) on a late night rush after Team USA got a
lucky draw against South Korea in the soccer World Cup, Marius Gedminas
(mgedmin) asked "if someone's working on problems with PostgreSQL numeric types
- (SQL errors like "operator = not defined for numeric and double") (when
trying to update a record containing a numeric field)" using the psycopg
database driver. He reported "basically postgres wants explicit typecasts in
statements like UPDATE employee SET foo=bar WHERE numericfield=123.4::numeric"
. Derek was able to reproduce the bug - "someone has introduced a bug in cvs OR
the pyscopg driver in sid has been changed - as when i ran this form before"
the form had worked. They both tried various alternatives, including =1, ='1'
and =1:numeric. Marius confirmed that his PostgreSQL reference book implied
that it "wants a typecast when it sees a numeric type in the WHERE part" . He
confirmed that "it works fine when you try to add new records - it fails when
you try to update them - or perform a query (no error messages, but no results
either in that case)" . He gave the workaround he had developed - "I don't like
that though" . Derek agreed - "if it chokes other db's it needs to be in the
postgres driver" and not in the GNUe code. He asked Marius to submit it as a
bug, and the workaround as a possible patch, pending an "official patch" .
He noted that there was no problem with integer fields, which had previously
been the case - fixing this had apparently "fried the float numeric type" , but
only for PostgreSQL. It also seemed to matter whether floating point fields
were referred to as 100 or 100.0. He could see several issues emerging here,
and felt it was "best to address" the next day - or more, accurately, later in
the same day after some sleep!
Later, Jason Cater (jcater) said he was not impressed that PostgreSQL could not
"handle implicit numeric conversions" . He felt that getting the database
driver code to check for specific numeric types and do the conversion itself if
necessary "may not be too hard" but if it meant "we have to do full-on
introspection at form load time" to check the types of all numeric fields "that
could be a big performance hit" . Derek said he "hopes this is a postgres bug,
but doubts it - as i have postgres 6.5.x here and it does same thing" . Jason
felt "any "reason" they can provide is a technical one that should be hidden
from SQL users" .
Marius pointed out that "forms currently perform the updates by constructing an
SQL statement and listing all fields in WHERE clause. Is there a way to use
only the primary key instead?" Jason said "that's something we need to look at"
. For most databases, "the database's "row id" is used - IF the database
supports such a thing" . However, in PostgreSQL 7.2 and higher, "oid's are
optional" .
There was some discussion about whether this, and the numeric conversion
problem, were desirable or not. But, as Derek noted, "postgres is a db people
will be using, we need to support their quirks whether we agree or disagree
with them" . He suggested changing Forms to identify different types of numeric
field separately. Jason said he "was trying really hard to avoid that - as it
goes into support issues I didn't want to deal with" . Derek said he did not
like it either, but the only other way of resolving the issue was to use
database introspection to check the exact type of numeric fields every time
they were used.
Some days later (12Jun2002) , Marius suggested resolving the issue of having to
list all of the fields in the WHERE clause of an update query by having a 'key'
attribute against each entry field on a form - "and the SQL query should only
list fields with key==TRUE in the WHERE part" . Derek said he was not sure of
this - "all too often people dont make proper keys" . Marius felt that "imho
the union of all fields in a block is less likely to be a proper key than a
developer defined set of fields" . Jason said he had "purposely avoided that
approach" in the past. Given that "we're gonna have to do a quick schema lookup
on form startup" anyway "so we can solve these numeric issues" , the code might
"as well as get the primary keys if defined - and fall back to using the whole
record if a table has no primary key" . This was not ideal, but "would solve
several issues at once" .
13. Developing and testing GNUe
9 Jun 2002 Archive Link: "[IRC] 10 Jun 2002"
Topics: Forms
People: Derek Neighbors
Derek Neighbors (derek) said "one should be able to do useful things with gnue
w/o being a GNUe developer - BUT - i think they need to be a developer of some
level to do something - i.e. they shouldnt have to be a GNUe tool developer,
but they should have application development experience" . For testing,
"currently i have like 3 forms i use to 'test' things - as i find forms that
'break' things - i try to shovel them into my 'test' suite" . He wanted "to
look at unit tester that will test functions of GNUe w/o actually running forms
- at some point we will need to build or find a free test suite to automate
testing" since "as more people start to bring GNUe into production the more
important test suite will come" .
14. Updating dropdown entry lists within Forms
9 Jun 2002 Archive Link: "[IRC] 10 Jun 2002"
Topics: Forms
People: Aditya Gilra, Derek Neighbors
Aditya Gilra (aditya_gilra) said "we're trying to change the list of values in
a dropdown entry from a trigger" and asked how to do this. Derek Neighbors
(derek), referring back to Issue #32, Section #27 (3 Jun 2002: Look-up combo
boxes in Forms) said "this is known issue" , as "the dropdowns get loaded at
start time only - it is a problem for others as well, we have started to
discuss best way to handle - as we dont want them updating all the time as that
could be a large penalty hit" on performance. No real conclusion had been
reached yet.
15. Scrollbars for grids
9 Jun 2002 Archive Link: "[IRC] 10 Jun 2002"
Topics: Forms
People: Marcos Dione, Derek Neighbors, James Thompson
Marcos Dione (StyXman) noted, as previously discussed in Issue #20, Section #13
(12 Mar 2002: Wizard changes in Designer) , that the code for scrollbars was
currently empty, and asked for suggestions. He was "thinking in a kind of
block, that could have any amount and kind of entry's - you then say how much
rows want to see at once, and the block should pass that info to its childre,
i.e., the entry's" . Derek Neighbors (derek) said "that was jamest original
intent iirc" . James Thompson (jamest) confirmed "my quick and dirty scrollbars
were going to do - look at the block/datasource to get record count and based
upon the rows (visible) set the size of the scroller - then set the up/down of
the scroolbar to only really do a next/prev record event - after each next/prev
event have the scrollbar look at the top visible record and adjust the scroller
position to be about right." Everyone encouraged Marcos to try some code out
with his own ideas - Derek even tried some reverse psychology on him.
16. Perl and GNUe
10 Jun 2002 Archive Link: "[IRC] 11 Jun 2002"
Topics: Common
People: Derek Neighbors, Jason Cater
It was asked whether there were perl bindings for GNUe. Derek Neighbors
(derek_) said "yes and no - i expect that the trigger engine" in GNUe Common
"will eventually support perl if someone writes the perl hookup" . Jason Cater
(jcater) suggested looking "at zope's Perl Script support - as they have perl
bindings for python" . Derek emphasised that "we are not against such a thing
but are limited on resources so its not high priority as of yet" . For people
with an interest in writing forms-like interfaces in perl, he recommended
entity (http://www.entity.cx) - although it had different goals and hence was
not as database-orientated or cross-platform as GNUe.
17. Properties box in GNUe Designer
10 Jun 2002 Archive Link: "[IRC] 11 Jun 2002"
Topics: Designer
People: Derek Neighbors
A problem with Designer was reported - it's was not letting users edit anything
in the properties editor. Derek Neighbors (derek) said that was a known
wxPython bug - "make the property editor big enough the scroll bar goes away -
and then you should be able to edit" . If the object has too many properties
for the screen size even when maximised, Derek suggested "um virtual desktops
:) - thas how i solved it" .
18. Defining the dependancies between GNUe Packages
10 Jun 2002 Archive Link: "[IRC] 11 Jun 2002"
Topics: Base
People: Derek Neighbors, Jason Cater, Neil Tiffin
Derek Neighbors (derek) asked for feedback "on packaging and such" . He had
discussed this with Neil Tiffin (neilt) on several occasions, including Issue #
15, Section #7 (4 Feb 2002: Private GNUe applications and GNUe Templates) .
The issue was that "packages have overlap - dcl for example needs contact info
as would say invoicing (vendors) etc etc etc as would salesforce automation -
but each needs 'varying' degrees." At one time, a "base" package had been
proposed, "but do to do that schemas and such would have be done properly to
break apart and such" . With the work going on to add contact management to DCL
and for the Free Software Foundation (FSF), "then maybe its time to do it more
'officially'" .
He was not sure of the best approach, but expected to need "something like apt/
dpkg only specifically for gnue to manage dependencies and such" . Jason Cater
(jcater) said that he had not thought about it much, "and my mind thinks in
relational, 2-tier fashion" . Derek said that the same principles of packaging
would apply to n-tier applications using Application Server. Jason pointed to a
very old document (http://www.gnuenterprise.org/~jcater/ExtendingGNUe.txt) of
his - "but that only addresses updating schemas - not dependencies/conversions/
upgrades" . Derek noted that the document had neatly predicted the need for a
database-independant way of creating and updating database schemas, which they
now had with the DCL schema generator that used XML. This could be expanded to
include not just the data about what tables and fields were required, but also
meta data about dependancies "to say when to use what - obvioulsy its vastly
more complex than this - but its a start" . Jason said that the existing XML
parsing code in GNUe could be used "so you could have a "pre-install" trigger -
and a "pre-dependency-check" trigger :)" .
19. Widgets on resized forms
11 Jun 2002 Archive Link: "[IRC] 12 Jun 2002"
Topics: Forms
People: Marcos Dione, James Thompson
Marcos Dione (StyXman) asked "why forms 'drops' widgets that would be outside
the current form?" . "they don't appear, even if I resize the form manually
(i.e., with the mouse)" . James Thompson (jamest) explained that "the form size
is set at startup time via it's height and width - it doesn't bother to create
UI widgets for anything outside that set size" . Marcos said that now he was
hoping to add a scrollable widget, this might need changing. James had "never
considered putting widgets inside a scrollable widget" , but looking at the
code he could not see why this would not work, and explained how to test in the
code whether a widget was created or not. Marcos reported "the widgets get
created, but the ones that 'fall' off window's region are not shown..." . James
said that the User Interface driver must not be re-sizing the container widget
when the form was resized. It might be possible to write code to do this
triggered by "onsize event" .
20. Entering null values in numeric fields
11 Jun 2002 Archive Link: "[IRC] 12 Jun 2002"
Topics: Forms
People: Marius Gedminas, Chad Walstrom, Derek Neighbors
Marius Gedminas (mgedmin) asked "suppose I have a numeric field in the database
and I create an entry field in a form - can I enter NULL values into the db by
leaving this field blank?" Chad Walstrom (^chewie) suggested logging this as a
bug in DCL if "you don't find it in the current bug database" . Later, Marius
reported "ah, solved the issue with nulls - apparently empty entry field is
stored as NULL in the db if it is typecast as "numeric"" . In his case, "a
couple of my field were missing that typecast" . Derek Neighbors (dneighbo)
asked Marius to close the ticket in DCL for the issue "so jamest knows what you
did and can look to see if either a. there needs to be a fix b. there just
needs to be better documentation" .
21. Creating a fixed number of child records for a parent
11 Jun 2002 Archive Link: "[IRC] 12 Jun 2002"
Topics: Forms
People: Marius Gedminas, Derek Neighbors
Marius Gedminas (mgedmin) asked "suppose I have a master/detail form where for
each master record there is a fixed number of detail records" . How could he
create the empty detail records when the master was created, so that they just
needed editing. Derek Neighbors (dneighbo) said "i think it can be solved via
master/detail hookup along with triggers" . Marius noted that this "is
basically the same as ticket 58" in DCL.
22. Using docstrings in python
11 Jun 2002 Archive Link: "[IRC] 12 Jun 2002"
People: Derek Neighbors, Jason Cater
It was asked why GNUe's python source files had # comments at the start of each
module rather than proper python docstrings. Derek Neighbors (dneighbo) thought
"we really should be using doc strings - so that we can build things with pydoc
or happydoc" , as previously discussed in Issue #32, Section #13 (1 Jun 2002:
man and info pages for GNUe) , but "we dont want code to be littered with
documentation i.e. the source is not hte place for the api manual" . Jason
Cater (jcater) felt that "docstrings REALLY reduce the readability of the code
imho" . Derek said "im thinking happydoc actually works with # stuff" . Jason
agreed. Derek said that a file generated from happydoc could form the shell of
the API documentation.
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.
</html>