[Gambas-user] Fwd: Re: Weird, yet again. Two way access to a collection. (not really a gambas issue)

[Bruce]

-------- Forwarded Message --------
Subject: Re: [Gambas-user] Weird, yet again. Two way access to a 
collection. (not really a gambas issue)
Date: Thu, 22 Nov 2018 09:04:25 +1030
From: Bruce <adamnt42 at gmail.com>
To: Steve <stevjensen at aol.com>

Thanks to all for the input.

As usual I have not been very clear.

My real problem is that with so many status conditions (1600+) we have 
difficulty while maintaining our code base i.e. within the IDE, with:
- code errors due to incorrect statuses
- the probability of "duplicate" status codes.

So I suppose what I am looking for is some way to "look up" the statuses 
  while editing the code. Sort of a "dynamic" add-in to the IDE I suppose.

But with all the ideas you all have given me, I think what I'll do is 
build a stand alone utility program that will provide
"a centralised "status" management subsystem that would let us manage 
the status of the parsing and persistence of RA data (as a start). The 
subsystem would ease development of the parsers etc by making the known 
statuses available somehow within (or close to) the Gambas IDE.
It will also provide a means to transport the exact status between 
parser classes as a simple (integer) code and allow the parser UI to 
show the status as a human understandable string." (from my notes on the 
design of the beast.

regards
Bruce



On 11/22/18 4:34 AM, Steve wrote:
> On 11/21/2018 6:17 AM, Bruce wrote:
>>
>> A real, real example is this. We have an application that lets horse 
>> trainers submit a horse for an auction.  There are about 20 gazillion 
>> rules and regulations about the animal concerned, which we need to 
>> check in that application and several others before the horse is 
>> acceptable as as lot in that auction.  So we have a component that 
>> does all the necessary checking with the relevant authorities. If 
>> everything goes OK then the component can send back a result code of 
>> 400 ("Probity checks satisfied, proceed with submission"). Otherwise, 
>> it may send back a code of, say 463 ("This horse is registered with &1 
>> as being deceased! Best of luck with trying to sell it") where &1 is 
>> replaced with the relevant authority name. The mnemonic in that case 
>> :-) might be "REG_HORSE_DEAD". Which is is hell of a lot easier to 
>> remember than 462, oops I meant 463, when maintaining the component 
>> code. If you get my drift.
>>
>>
>> And yes, the "products" change all the time. In this case they are the 
>> regulations that apply to validating an auctionable lot.  And yes, the 
>> *(%%&(^( authorities always pick the busiest time of the year to 
>> implement the rule changes! @#^%*#^*# !!!!
>>
>>
> If I understand this correctly I might investigate doing this as a 
> database application.
> Don't know the gambas database application capabilities or for that 
> matter how flexible it is with runtime screen object creation
> but...
> 
> An approximation of a  possible database (not even remotely meant to be 
> a final solution) might look like
> Parent = Agency* (name, contact info, remote submission info)
>          dependent child agency rule = (rule#, rule_text, 
> entry_datatype, entry_allowable_values*, remote submission format 
> string, edit status*, eff_date, exp_date))
>          dependent child rule>allowable_values (drop down box, range test)
>          dependent child rule>edit_status (error#, error_text)
> 
> You could, at runtime, build an input form (either for all agencies or 
> individual) with appropriate entry fields
> Do local edits. (Horse age < 0.  Sale of potential horse not allowed).
> Submit to remote agency/s and display responses
> 
> Essentially all your logic ends up in the database and none in your 
> program code.
> Not a simple implementation by any means but once done only the database 
> needs to be updated as agencies send new regulations.
> Your pgm would only need to be updated for new edit types.
> Yes, this would be a major departure from what you appear to be doing now.
> Its also possible to do mix and match pgm and db logic, say just the 
> error codes.
> 
> Enjoy.
> 
> 
>