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 ).

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.

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 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.

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).