johnf wrote: > On Wednesday 27 May 2009 06:22:15 am Ricardo Aráoz wrote: > >> I've done something similar under VFP. I have a form with a label, a >> textbox and a list box beneath them with the names and contents of all >> the pertinent filter variables. As the user scrolls through the list box >> the label takes the value of the highlighted variable and the textbox >> the corresponding content, if the user wants to change the value of a >> filter variable he does so in the textbox, where the data is validated >> properly (mask is in effect to filter input), pre-processing is done and >> results converted to proper type are fed to appropriately named >> property. Once the ok button is pressed the query is executed with >> values taken from these properties. This schema allows me validation >> against other defined variables (just validate the corresponding >> properties). >> The filter variable names, pre-processing, validation, error message >> (when validation is not true), type, mask, visibility (so I can use >> variables not accessible to the user), etc. are stored in a table. >> > > Sounds good! > > So can I assume that when a range is required that there are "var from" > and "var to" in the list? > Yes. I would define a FromDate and a ToDate variables, in from date's default value I'd put say "date() - day(date()) +1" and on ToDate's default I'd have "date()". On both dates valid "FromDate >= ToDate" and a proper error message. I also use a pre-process field where I can convert a variable to it's final form, for a Period variable it might be "val(right(Period, 4) + left(Period, 2))" where the mask of the variable is "99/9999" and the default "transf(month(date())) + '/' + transf(year(date()))". Of course I have a form where all these settings may be handled by the programmer. > In our case the idea was to have dynamic controls appear as required. On the > left we have a dropdown with "single", "range", or 'all' for each of the > required params. If the user selects "single" only one (textbox, datebox, or > masktextbox) control appears, if 'range' is selected then two controls > appear. There is nothing to do if 'all' is used. The SQL then uses the user > input to retrieve data. > You might add "some" and show a multi-select list. I also allow queries to be defined in these cases so as to fill the multi-select list. Problem with "range" is that the user looses control over the variable, or has to have in mind that when there is a range then variable "Var" must be referred as "FromVar" and "ToVar", given that my memory is weak I prefer to deal with both ends of a range one at a time. I used a list and a text box because in some cases I may have up to 20 filter variables in a report, but with wx I'd probably use a scrollable form and allow the programmer (user) to define the control they'd like for the variable. > The problem of validation is of concern. Unlike VFP Dabo (in general) > expects > bizobj's to handle validation. In this case there is no bizobj. So we > haven't got it down pat for the moment. > How would you go in Dabo when you want something validated right away (as the user exits the control)? I would just validate the filter variables without regard to the bizobj. After all they are NOT necessarily related to the table or the data IN the database, but to the report at hand. Let's say you have a variable for the user to enter a text to be printed at the beginning of every report page (let's say a note to the reader, no relation with the data), and for the sake of the argument that you want some freak validation over this text. Then maybe a bizobj wouldn't be appropriate as there is no table to relate it to. So I would use bizobjs for my data but not for my filters, after all Dabo is there to help you, not to stand in your way. > But we are providing the user lookup tools to pick the params. For example > if > the user wanted to pick a customer they would click on the lookup button and > a pick-grid would appear listing the customers. This goes a long ways in > preventing bad input. > Yes, but "power users" (the people that use the system all day, every day) will also like to be able to input the customer number right away, they have this numbers memorized. And then you still have the same validation problem as if you had no look up at all. > Our biggest issue is the report interface is very dependent on tables, and > our > home grown classes. The tables (meta data) I don't mind. They don't have to > be on a postgres server. We could have used SQLite. But using our home > grown classes are of concern. Not that they don't work - they do. Just that > when we wrote them we were less than knowledgeable when it came to Dabo and > python in general. But we are getting better daily. > Don't worry about that, it's unavoidable. Just think of the fun you'll have in version 2 when you start thinking of ways to improve your app, and take notes of stuff you'll want improved. Who said you can't start thinking of version 2 before delivering version 1?
--- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html --- _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users Searchable Archives: http://leafe.com/archives/search/dabo-users This message: http://leafe.com/archives/byMID/[email protected]
