*** reinhard has joined #gnuenterprise
<reinhard> good morning all
*** johannesV has joined #gnuenterprise
<johannesV> good morning
*** dimas has quit IRC
*** johannesV has quit IRC
*** lekma has joined #gnuenterprise
<lekma> good morning all
<lekma> reinhard: are you available for a few questions?
<reinhard> yes (if you can accept slow answers, am on the phone)
<lekma> ok
<lekma> first i really need to understand what filters are, cause it seems i may need this functionnality
<lekma> could you provide an example
<lekma> please
<lekma> from what i understood
<lekma> they are some kind of reference from a class to another class
<lekma> but to what purpose?
*** johannesV has joined #gnuenterprise
<reinhard> the idea behind filters is to implement things like multi company
<reinhard> you have a table "company" that contains the companies
<reinhard> and all other tables have a foreign key to the company table
<reinhard> you select the company you want to work in at startup or you can even define it in your connections.conf
<reinhard> and you will only see the records for your company
<lekma> how do you define a filter and why is getFilers language dependant? couls this filter process be used to implement locale dependent data?
<lekma> ie if i have a lang class
<lekma> and translation classes
<lekma> can i use filters to rule out all record that are not in my locale?\
<reinhard> you could do that
<reinhard> getFilters is language dependent because it returns a structure containing a question to ask and the possible answers
<reinhard> like "Company" and "company1", "company2",...
<reinhard> but for German it will not be "Company" but "Firma"
<reinhard> you can find example for filters in gnue-luca
<lekma> could you give the svn url of contrib (gnue-luca is in contrib, right?)
<reinhard> gnue-luca is a separate svn repo
<lekma> oh
<reinhard> svn.gnuenterprise.org/var/svn/gnue-luca/trunk
<lekma> svn co http://svn.gnuenterprise.org/var/svn/gnue-luca/trunk gnue-luca
<lekma> svn: PROPFIND request failed on '/var/svn/gnue-luca/trunk'
<lekma> svn: Could not open the requested SVN filesystem
<lekma> do you have an idea what's going on?
<reinhard> I use svn+ssh instead of http
<reinhard> I don't know how it works with http
<lekma> that's ok
<lekma> the correct http url is: http://svn.gnuenterprise.org/gnue-luca/trunk
<lekma> hmm i see some examples, i'll try... is the whitepaper up to date?
<lekma> cause it mentions compound properties
<lekma> i'd like to know what these are
<reinhard> oh
<reinhard> they have been ditched
<reinhard> the idea was originally to have some kind of C struct
<lekma> No parameter for the filter base_lang specified
<lekma> what does this mean? how do I set a parameter for a filer from the rpc pov?
<lekma> and is there a way to bypass a filter?
*** kilo has joined #gnuenterprise
<lekma> InvalidFilterValueError: \'en\' is not a valid filter of the type \'base_lang\'\n'
<lekma> i'm a bit lost with this filter functionnality
<lekma> even though it seems useful
<reinhard> just a second
<reinhard> you have a class base_lang?
<lekma> <?xml version="1.0" encoding="UTF-8"?>
<lekma> <module name="base">
<lekma>     <class name="lang">
<lekma>         <property name="code" type="string(2)" nullable="False" />
<lekma>     </class>
<lekma>     <class name="langtxt" filter="base_lang">
<lekma>         <property name="code"     type="base_lang"  nullable="False" />
<lekma>         <property name="langDesc" type="string(80)" nullable="False" />
<lekma>     </class>
<lekma> </module>
<lekma> this is my module def
<reinhard> I think you didn't understand correctly
<reinhard> if you have a filter="base_lang", appserver creates the field implicitly
<lekma> yeah
<reinhard> I think lang and langtxt would be the same class
<reinhard> without filter=
<reinhard> and then you have some other classes that have language dependent data
<reinhard> that have filter="base_lang"
<reinhard> on login, you give base_lang = <the gnue_id of the language you want to have>
<lekma> so i need to make a session request to find out which gnue id apply to my filter?
<lekma> before  i do anything else
<reinhard> that's the purpose of getFilters
<reinhard> it gets you the valid values with their respective gnue_id
<reinhard> the idea is that you can, on the front end, display a dropdown with the values
<reinhard> and let the user select, and then send the corresponding gnue_id at login
<lekma> but what i get from getFilters is only a bunch of gnue_id's so i still have to find out what data they represent
<lekma>     mySession = myServer.open({"_username": "", "_password": ""})
<lekma>     myFilters = myServer.getFilters("en")
<reinhard> you might need a corresponding gld for the gcd defining the filters
<lekma> for test purpose this is how i connect
<reinhard> btw, you can do getFilters *before* the open
<reinhard> because you need the filter in the open
<lekma> ok
<lekma> i don't get the needing of a gld, what it will provide are labels only, not the data, the filter i want represents langs like en, fr, de, zh... these are data in base_lang.base.code
<lekma> so how getFilters will give me those?
<lekma> what i'd like at the end is a table base_lang:
<lekma> fr
<lekma> en
<lekma> de
<lekma> zh
<lekma> and table base_langtxt:
<lekma> fr  en french
<lekma> fr fr français
<lekma> en  en english
<lekma> en fr anglais
<lekma> ...
<lekma> a translation table
<lekma> in this example
<lekma> the lang code and the lang translation code are from the same class
<lekma> so i was thinking maybe if i had a filter base_lang = en  i didn't have to put an extra condition when accessing translation classes cause it would rule out all record which are not base_lang == en
<reinhard> ah ok i understand
<reinhard> getFilter returns a rather complex structure with dictionaries where labels and data are interwoven
<lekma> i see now that with a gld it's different
<reinhard> I think it might be an improvement to fall back to something more meaningful if there is no gld
<reinhard> creating an issue now...
<reinhard> err wait
<reinhard> as I write it, it gets logical why it doesn't work without gld
<reinhard> the base_lang class could have dozens of fields
<lekma> yep
<reinhard> and in the gld you define which of these fields you want to see in the login dialog
<reinhard> (i.e. you want to get in getFilters)
<lekma> how?
<reinhard> you see only those fields that have a searc=
<reinhard> search=
<lekma> which is a pb by itself
<lekma> cause if i understand correctly
<lekma> search is also used in gnue-forms
<lekma> right?
<reinhard> yes, but for the same purpose
<reinhard> to be precise, it's used for generated forms
<reinhard> that have a foreign key to the language
<reinhard> so search is what you want to see in the dropdown when you select a language
<reinhard> and you probably want to see the same in the login dialog (to select a language) or in any other form (to select a language)
<lekma> there can be mixups between the filter use (where you would only see, say, the code) and gnue-forms use (where you'd like to see the code and smthing else)
<lekma> why?
<lekma> in a login dialog you don't want to clutter the ui with too much things
<reinhard> you can also have multiple fields in filter use
<lekma> and in the forms you need the info
<lekma> how can you bypass a defined filter?
<lekma> for migration purpose, for example
<reinhard> http://www.gnuenterprise.org/~reinhard/filter_login.png shows how a login dialog looks like with more than one search=
<reinhard> you can bypass a filter by explicitly including the filter property into the condition tree
<reinhard> only if the condition does not contain any reference to the filter property, appserver implicitly adds a "... and filter_property = filter_value"
<reinhard> bbl, lunch
<reinhard> back
<lekma> i really think the search attribute for getFilters use should be in gcd's instead of gld
<lekma> the result of a getFilters("en")[3] is a dict with one property whose label is empty, is that correct?
<lekma> if so why the empty label?
<lekma> s/getFilters("en")[3]/getFilters("en")[0][3]
<reinhard> elements 2 and 3 of the tuple include definition of related filters
<reinhard> if filters are not related, element 3 is a dictionary with a "None" key
<reinhard> say you had dialects
<reinhard> like for "en" you can have "en_GB", "en_US", etc
<reinhard> then you had 2 filters
<reinhard> language and dialect
<reinhard> the set of valid dialects would depend on the language
<lekma> al right
<reinhard> you can probably see that the filter stuff hasn't gone throught the "lekma quality check" system ;-)
<reinhard> but I think in basic principle, it's usable and the right direction
<lekma> :)
<reinhard> sooner or later we will have to play around with the login process a little more, when we want to add real security to appserver
<reinhard> like login with kerberos or whatever
<lekma> ldap woud be great
<reinhard> and we might well then think the filter stuff through again
<reinhard> I would prefer login methods that don't send passwords over the net
<reinhard> so we would either need a wrapper that encrypts passwords client side and decrypts server side
<reinhard> or use an authentication system that is secure as such
<reinhard> 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
<reinhard> but that's down the road anyway, we focus on forms nowadays
<lekma> just a thought: could it be possible that instead of sending "base_lang": "the32charsgnueidofthedeath" in your params we send "base_lang.base_code": "en" as a filter?
<reinhard> base_code is not guaranteed to be unique
<reinhard> IIRC we had that once but then we switched to gnue_id because we felt that was safer
<kilo> lol @ gnueidofhtedeath
*** jamest has joined #gnuenterprise
*** lekma has quit IRC
*** kilo has left #gnuenterprise
<jamest> hmmm
<jamest> i was thinking there was a way to iterate through all the records loaded into a form (to create a sum in a trigger) without updating the UI
<reinhard> yes, you can use the resultset as an iterator
<reinhard> like
<reinhard> for rec in blkFoo.getResultSet():
<reinhard> for rec in blkFoo:
<jamest> ok, thanks
<reinhard> should actually work, too
<jamest> the blkFoo: does work but scrolls the UI
<reinhard> ah yes it does
<reinhard> right
<jamest> i need it to not do that as accounting doesn't like their entry forms scrolling after each tab
<jamest> :)
<reinhard> I wonder whether the scrolling is on purpose or it could be changed
<reinhard> as I actually don't like the idea that trigger code can directly access the RecordSet at all
<reinhard> err the ResultSet
<jamest> i don't know thy the result set is exposed now
<jamest> as i'd always used the for rec in blkFoo: in my triggers
*** dimas has joined #gnuenterprise
*** klasstek has joined #gnuenterprise
*** derek has quit IRC
*** johannesV_ has joined #gnuenterprise
*** johannesV has quit IRC
*** sacha has joined #gnuenterprise
*** derek has joined #gnuenterprise
*** jcater has joined #gnuenterprise
*** tinwood has joined #gnuenterprise
*** tinwood has left #gnuenterprise
*** bjantscher has joined #gnuenterprise
*** sacha has quit IRC
*** sacha has joined #gnuenterprise
*** dimas has quit IRC
*** sacha has quit IRC
*** sacha has joined #gnuenterprise
*** SeanTater has joined #gnuenterprise
*** SeanTater has left #gnuenterprise
*** sjc has joined #gnuenterprise
*** sacha has quit IRC
*** johannesV_ has quit IRC
<reinhard> jamest: could you unsubscribe harder@brinkmann.nl from all gnue lists?
<reinhard> this address is broken
*** sacha has joined #gnuenterprise
<jamest> yes, i can in a bit
*** psu has joined #gnuenterprise
*** sacha has quit IRC
*** klasstek has quit IRC
*** klasstek has joined #gnuenterprise
*** sacha has joined #gnuenterprise
*** klasstek has quit IRC
*** klasstek has joined #gnuenterprise
*** ra3vat has joined #gnuenterprise
*** ra3vat is now known as dimas
*** bjantscher has quit IRC
*** psu has quit IRC
*** sacha is now known as SachaZzzz
*** SachaZzzz has quit IRC
*** lupo__ has joined #gnuenterprise
*** SachaZzzz has joined #gnuenterprise
*** kilo has joined #gnuenterprise
*** jamest has left #gnuenterprise
<reinhard> good night all
*** reinhard has quit IRC
*** lupo__ has quit IRC
*** kilo has left #gnuenterprise
*** klasstek has quit IRC
*** sjc has quit IRC
*** jcater has quit IRC
*** jcater has joined #gnuenterprise
*** jcater_ has joined #gnuenterprise
*** derek has quit IRC
*** derek has joined #gnuenterprise
*** Amorphous has quit IRC
*** Amorphous has joined #gnuenterprise
*** dimas has quit IRC