Table Of Contents
|1.||2 May||Using filters in Application Server|
|2.||3 May||Using different parts of the GNUe toolkit in real-world applications|
|3.||7 May||Status of various accounting packages in GNUe|
IntroductionThis newsletter mainly covers the the #gnuenterprise IRC channel, with occasional coverage of the three main mailing lists (gnue-announce, gnue and gnue-dev) for the GNU Enterprise (http://www.gnuenterprise.org) project.
1. Using filters in Application Server
2 May Archive Link: "[IRC] 02 May 2006"
Summary By Peter Sullivan
Topics: Application Server
People: Reinhard Müller, Malek Hadj-Ali
Reinhard Müller (reinhard) explained "the idea behind filters is to implement things like multi company - you have a table "company" that contains the companies - and all other tables have a foreign key to the company table. You select the company you want to work in at startup or you can even define it in your connections.conf - and you will only see the records for your company" . Malek Hadj-Ali (lekma) asked "why is getFilters language dependant?" wondering whether he could "use filters to rule out all record that are not in my locale?" Reinhard said this was certainly possible, but the more basic reason why filters were language dependent was because the name of the object being filtered on would be different in different locales - for example, "for German it will not be "Company" but "Firma"" . He noted that "you can find example for filters in gnue-luca" (as referred to in Issue #107, Section #3 (9 Mar : Current Status of GNUe Project) ).
Malek asked how to supply the filter value to the Application Server. Reinhard explained that, for example, "if you have a filter="base_lang", appserver creates the field implicitly" and "on login, you give base_lang = <the gnue_id of the language you want to have>" . Malek asked how he would know "which gnue id" to supply. Reinhard replied "that's the purpose of getFilters - it gets you the valid values with their respective gnue_id. The idea is that you can, on the front end, display a dropdown with the values - and let the user select, and then send the corresponding gnue_id at login" . The reason for using getFilters rather than just querying the table or class that contained the possible values for the filter was that the class "could have dozens of fields" so you needed a mechanism to decide "which of these fields you want to see in the login dialog" for the user to select from - "you see only those fields that have a search=" property. This was similar to the way the search= property was used in Forms, to determine which field or fields were displayed as the pick-list in dropdown selection fields.
Ealier, Malek had asked "is there a way to bypass a filter?" Reinhard explained "you can bypass a filter by explicitly including the filter property into the condition tree" . The way that filters were implemented was that normally "appserver implicitly adds a "... and filter_property = filter_value"" to the end of all queries. But it only did this "if the condition does not contain any reference to the filter property" already. So putting in your own, explicit, condition on filter_property that was always true (e.g. filter_property IS NOT NULL) would bypass the filter and show you all records.
Reinhard also explained that some of the apparent complexity of the filter-realted code was an attempt to deal with multi-level filters, such as language and dialect. You might need to first of all select a language (e.g. English), and then select the dialect (e.g. British English or American English).
He admitted that there was more work to do on filters, "but I think in basic principle, it's usable and the right direction" . When the time came "to play around with the login process a little more, when we want to add real security to appserver" , that might well also be the time to "think the filter stuff through again" .
He added that, in terms of security for Application Server, "I would prefer login methods that don't send passwords over the net - so we would either need a wrapper that encrypts passwords client side and decrypts server side - or use an authentication system that is secure as such. I've been thinking TLS, SASL, Kerberos, GSSAPI and a lot of other buzzwords, but I need to read deeper into it to see what fits with what we actually need - but that's down the road anyway" .
2. Using different parts of the GNUe toolkit in real-world applications
3 May Archive Link: "[IRC] 03 May 2006"
Summary By Peter Sullivan
Topics: Reports, Forms, Common
People: Nick Rusnov, James Thompson, James Thomspon, Reinhard Müller
Nick Rusnov (nickr) noted "I need to make a little app to calculate sales quotes" , asking "Do I need to create database records for the actual quote in order to produce a report from it" using GNUe Reports? Quotes would be calculated from "a database of prices, discounts, schedules etc - I'm just wondering if I need that to be created as a group of records in the database in order to get it as an output or if I can get it directly from the forms client somehow" ? James Thompson (jamest) recommended saving the details of the quotes generated in any case - "as i always get hit up for it later" - "people want that history here at times" of previous quotations provided.
More generally, he explained "in some of my forms i have a trigger do the work, store the record(s), then call a python app to generate the output form" . This was then passed to "a python app that uses reportlab (http://www.reportlab.org/bauer1.html) to build the output" . However, you could also produce output this way without saving the data to a database first. This was "like my packing slips, the gnue-form frontend isn't directly bound to any tables - the shipping guys fill in the form, press a complete button. my output looks nothing like the form - as it adds company logo, barcodes, extra info the shippers don't enter" . This was a fairly simple application - a 463 line GNUe Form Definition (.gfd), plus about 100 lines of python for the triggers.
Nick explained his requirements - "essentialy the sales person selects a discount/pricing schedule, and then adds items to a list which have this pricing schedule applied to them - if they don't specify an exact count they can select a quantity break - if they specify an exact count for every item then it caries over the price and totals" . Then "at the end they click a done button or whatever and it outputs a nice pdf of the quote for the customer" . Why he was interested in using GNUe Forms was that "it'd be nice if they could see the items as they are added and then be able to at least delete them if they make a mistake" .
James Thompson said that "another option if forms is too rough would be a small custom app based upon gnue-common - i do that for more complex tools like our scanner app and order processing app" . A custom application could use GNUe Common directly (i.e. not via Forms or Reports) to "present a QT designer built UI to the user - access to our datasources - basic argument parsing - the debug and profiling stuff" .
He explained that "forms is mainly a data-aware front end that provides basic input manipulation, validation, and triggers" but he cautioned "forms can't dynamically change the UI layout currenlty" . He confessed "for me I use forms more than I should - as it presents a common interface to most our apps - but if you need areas to expand and contract then forms won't fly" as of time of writing. Nick felt that "forms needs a data table widget" . James said "we're talking about adding a table widget - but really other than looks the rows=" tag that already existed "does the same thing" . Reinhard Müller noted that "a grid is going to be in form's next release" but this was probably several months away.
3. Status of various accounting packages in GNUe
7 May Archive Link: "[IRC] 07 May 2006"
Summary By Peter Sullivan
Topics: Financials (Accounting), Luca, Small Business, Application Server
People: Dmitry Sorokin
It was asked if there was an accounting schema for GNUe. Dmitry Sorokin (dimas) said "the only accounting schema i remember was in gnue-luca" . It was noted that there had been no work done on GNUe Small Business Edition since July 2003. Dmitry said that schemas were normally stored in .gcd (GNUe Class Definition) files, as used by the Application Server. GNUe Small Business did not have these, as it "did not intend to use appserver from the beginning" , but just work in two-tier mode (GNUe Forms or Reports talking directly to the database).
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.