Logic ideas - 5 levels.

[Neil Williams]

On Thursday 22 September 2005 6:49 pm, Derek Atkins wrote:
> I don't see how that helps at all.  The validation we're talking about is
> USER INPUT validation, not datafile validation.  Sure, XML can be used
> to validate the datafile, or QSF.  But that's not the real issue..  That's
> not where most of the code is.

True, but it is one component of the overall logic AND, crucially, it is the 
one place where some of this logic is expressed. i.e. some of the constraints 
on a particular parameter at runtime are determined by what the application 
can and cannot load from the file. Not everything is currently expressed 
within the GUI logic, some is implicit in the file backend. OK, it's not much 
but it IS a component of the overall logic cascade.

> The code we need, what's most of the codebase, is validating the
> input from the user.

The other levels of the logic cascade deal with the higher levels of logic. 
ALL can be used for runtime validation of user data input.

> For example, the user is typing into the 
> new-account dialog, and we need to make sure that they supply a name,
> and that the commodity type is valid for the account type, and
> lots of other types of validation.

That's the entity level validation, leading possibly to collection and book 
logic tests. Currently, the backends do NOT do entity level validation, the 
majority is in the objects (typically in the clone routines). What I need is 
a way of using that logic without having to clone the entity. Other parts of 
the same logic level also occur in various dialogs. It's all runtime stuff.

But it's vital to get away from the discussion of dialogs - this is nothing to 
do with the GUI and that's why it's going to take a while to complete the 
task.

When entering a new account (whether in a GUI or CLI), we do need to verify 
certain parameters of that object as and when they are changed, at the point 
where the entity is supposed to be complete and indicate to the front end 
that the entity IS sufficiently complete to allow the user to commit the 
data.

Entering a new account means checking that certain parameters have usable data 
- the lowest level of "is this a string when it's meant to be a number" type. 
As data entry continues (whether from the user or from some automated source) 
the entity itself can be tested as a unit. That's where we check that certain 
parameters are present and useful - before this point we could just be 
waiting for more data entry. Only when the entity passes validation as a 
whole would the logic indicate to the UI that the entity can be accepted. 
This is where the GUI would enable the OK.

Please go back to the 5 levels - it's all there for passing data on validity 
to user interface elements that enable or disable user entry inputs, i.e. 
this is not just about validating entities at the end of input, it's about 
validating each parameter as it is entered and only enabling a commit if the 
logic tests pass.

In a GUI, a validity failure will prevent OK being enabled. In a CLI, it will 
do an equivalent operation - preventing the commit command from operating and 
alerting the user to the validity problem(s).

We've got to get away from WHERE this takes place and abstract HOW it works.

> I think you've lost the picture of what needs to be done in your list,

No, I think you've jumped at the first level and discarded the rest - when it 
was the rest that was actually directly relevant.

You've missed my point completely - the only reason for any of this logic work 
is because FILE input (in CashUtil) is *insufficient*.

So we agree, logic is about runtime data entry, whether that is a book merge, 
parameter edit, undo, new entity creation . . . . However, a (small) 
component of that logic is also implicit in the file backend and as QSF has 
none of these assumptions, it is an area that needs consideration.

Granted the majority is in the higher levels - I did say that. 
"That's the lowest level and it's the one we have already - albeit it isn't 
fully utilised always."
"The lower levels (1 + 2 above), are small increments from where we are 
now. Level 3 is implemented in a patchy way for certain elements of certain 
objects. Levels 4 and 5 are implemented in two ways: the gnc-backend-file 
refuses to save/load data that doesn't fit the implicit assumptions of that 
backend and the UI refuses to display data that doesn't fit it's own versions 
of those assumptions."

i.e. the backend is currently ONE of the ways that the implicit logic is 
enforced - I'm thinking here of account hierarchies. It IS possible to create 
accounts without correct hierarchies and these just drop out of the file when 
it is saved.

But I did clearly relate the same logic levels to the UI.

> (which I've snipped away here)...  You don't talk about user input
> validation at all,

I do, each of the higher levels of the cascade are for user input validation - 
at runtime, during user entry, one parameter at a time if appropriate and 
checking the entity, the collection and the book if necessary.

I don't talk about *GUI user input*. The point is not at all about dialogs, 
it's about how the entity parameters are modified *as a result* of the user 
action - whether that is a dialog or a CLI command.

We've got to get the code OUT of the GUI and that's why I try not to talk 
about the logic in terms that predispose to a discussion of dialogs and 
druids.

-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20050922/d53215b0/attachment.bin