Merge & Storing input validation logic as a custom property

[dunbarx]

Sounds like a load of fun, to make those connections work.

That said, I would instantly go back to the ordinary. I do not see any advantage in maintenance, since if there are changes, it is as easy to change a value as it is to change an expression, and to my mind, much more readable.

I may be old fashioned, but I read a line of code that refers to or extracts a value in, say, a custom property much more readily than I would read a line of code that assembles pieces of conditionals to create what is essentially a new line of code. I do not see any shortcut, though I appreciate the construction process in and of itself.

Probably just a matter of style. Do what you like best.

Craig

[AxWald]

Hi,

So the part that I want to store as a Custom Property is "field A = 90 and field B > 0".

cCondition of fld "A" in my previous example:

Code: Select all

([[me]] = 90) AND ([[fld "B"]] > 0)

WHOW!, I completely missed the usefulness of this for general input validation. I learn a lot here, actually ;-)

Whereas I'm going more and more away from direct user input into fields. This works great on traditional desktop machines but is a complete PITA on mobile (due to abysmal means of input) - and doesn't work at all (reliable) in table fields that I generally use instead of the dreaded dataGrid.

And it's more suited to the traditional "chain of work" anyways, where there's so often a "media break" (paper => database) that requires manual data entry. These days basically everything comes (and goes) in digital form, so the main attention is now on creating interfaces/ parsers for the different data formats, and to create the best possible matching predictions that then only need minor corrections & acknowledgment.

So I have now my own "ask/ answer"-like input system with extensive use of "+ / -" buttons, option menus etc. that's a bit slower on desktop PCs but much faster on tablets. Still, there's need for input validation, and having the condition in the cCondition of the calling object, and having handled it by the input system, saves some more of redundant code. Maybe such:

Code: Select all

on mouseDoubleUp                   --  this lives in a locked field
   get askInput(the name of me,"Augustiner")
   --  my cCondition is: "([[it]] = "Augustiner")"
   --  my cQuestion is: "What beer do you want?"
   --  my cTitle is: "Choose your beer:"
   if line 2 of it is empty then             --  condition met:
      set the cValue of me to line 1 of it   --  for display/ further processing
   else                                      --  condition not met:
      answer line 2 of it & " is not acceptable!" titled "Barbarian!"
      --  or process the input in line 2 of it  (an unacceptable choice)
   end if
end mouseDoubleUp

function askInput theCaller, theDefault  -- this lives somewhere in the message path
   --  to make it comprehensible I do a simple ask call:
   ask the cQuestion of theCaller with theDefault titled the cTitle of theCaller
   if it is empty then exit to top              --  user hit "Cancel"
   if merge("[[" & merge(the cCondition of theCaller) & "]]") then
      return it
   else
      return false & CR & it
   end if
end askInput

Now the whole evaluation is centralized in the askInput function. Left in the input field is very few redundant code - and we might use behaviors to reduce this even further (if the implementation of these wouldn't be this awkward in my 6.7.10 ...)

Mental note to myself: Implement!!!


Ooops, I stumbled over something unrelated:

the next thing after this on my to-do list after this is "deploy to Apple"

If you don't have a full set of contemporary AppleStuff already, check with your clients before, carefully. Cupertino's h_iWaymen are merciless - you'll need to be very sure your costs will be covered!
Only once a customer approached me with this - he had an iPad inherited from his daughter, and wanted to use these now in the company. So I investigated and pointed him to the Apple Developer Enterprise Program which he must be member of to install his own proprietary App on his own iPads (that are used by his own employees) without having to buy it from himself via the iStore (and drop a 30% fee for Apple). A few requirements are:

• " Join the Apple Developer Enterprise Program for 299 USD per year" ...
• "To enroll in the Apple Developer Enterprise Program, your organization must be a legal entity with 100 or more employees."
• "Your organization must have a D-U-N-S Number so that we can verify your organization’s identity and legal entity status. These unique nine-digit numbers are assigned by Dun & Bradstreet ..."

I cannot quote his reaction, there may be minors reading. In short, his idea suffered an immediate decease.
And I hadn't even told him yet he'd have to buy me a suitable Mac & an iPad to test on, and to pay my Apple Developer Program bribe. :)
And he hadn't even realized yet how many of his existing tablets got lost/ damaged in the field each year, and that an Apple replacement for even the best of his existing tablets had an above 100% price extra.

So my advice: Make sure it really makes sense, before you start spending time & money.
Windows/ Linux/ Android work very well with LC, allow the use of GPL, without any need to buy expensive proprietary stuff/ pay some greedy h_iWaymen.
And has, together, an overwhelming market share compared to iOS/ MacOS.
At least as long as you need to sell your code to real live businesses that are able to pay you enough to earn you a living. It may be different for other people.

Have fun!

[KimD]

Thanks to your help your help, I've got both the "Do" and "Merge(Merge())" solutions that you proposed working. But, I also decided to try and create solution that used the Value function. What I came up with, which works, is:

The custom property (PassedValidation) of field "Latitude1" contains -
(me < 90) OR (field "Latitude2" = 0)

The custom property (PassedValidation) of field "Latitude2" contains -
(field "Latitude1" < 90) OR (me = 0)

The handler contains -
If NOT value(the PassedValidation of me) then
// Field failed validation script
Else
// Field passed validation script
end if

Note:
1) I had some (very simple) earlier validation that checks that each field (individually) is not null, is a number, and falls within an appropriate range. My value() function just handles the aspect of the validation that is dependent on another field.
2) I found that whenever either "Latitude1" or "Latitude2" changed, I needed to re-validate both fields. The validation of "me" was triggered by CloseField, and I then Dispatched a message to cause the partner field to also validate.

I'm going to run with the solution using the Value function. It's the easiest of the three options for me to understand. It's been an excellent learning experience, including learning the difference between Me and The Target. The Target is not always Me, that's just paranoia

Thanks again

Kim

[SparkOut]

Can I just say how happy I am to see the discussion in this thread and it is both informative and refreshing. I love the philosophy of validation of input before it is acceptable, rather than leaving it to the machine to decide whether it will eat or choke on what it has been fed.
Use of sliders to limit values within a range, radio buttons, checkboxes and so on also help to restrict the option for invalid input where suitable. I just had to make an interface to choose option 1, 2 or 3 by typing the choice into a field and pressing the enter button. Bleagh, but for reasons that actually do make sense, if I could spend time to explain, this was the preferred UI style. Needless to say, I validated so only an input of 1, 2 or 3 could be made, no other characters allowed and max length of 1.