[
Lists Home |
Date Index |
Thread Index
]
From: Hunsberger, Peter [mailto:Peter.Hunsberger@STJUDE.ORG]
Bullard, Claude L (Len) <len.bullard@intergraph.com> writes:
>> Let's ask the question another way. Considering that a schema
>> only knows how to do one thing, test conformance of an instance
>> to itself, where should a schema sit in a model-view-controller
>> architecture?
>Cheap shot: as far away as possible....
So I would have thought. As I read further, I discovered that
MVC is a scaling pattern. Different parts of an architecture have
different models; thus as in the message that followed, one finds
a schema validation step taking place in what I would have
considered interprocess communication, eg, the handlers. My two
most fundamental errors are to consider schemas only at the
external system junctions and to consider only a single schema.
(I do know this is wrong but it is a thought habit.)
>> A user interface is likely doing all of the following:
>>
>> 1 Managing the flow of information through the user interface components
>> 6 Accumulating data taken from many UI components to perform a batch
>>update at the server
>>> 7 Keeping track of the progress of a task in a user interface process"
>I find MVC to be an incomplete model, but playing along with this for a
>moment, what about 1? Early validation that what the user entered is
>what the application expects is always good?
Is it? It might mean I couple the validation to the user interface
and it is coupled to the device. That might not be the best place
to put the schema. A question is which events cause a validation?
Do I validate all form entries at one time (on submit) or validate
each field as entered (on loss of focus, on tab, etc.). Obviously
the latter fattens up the client and forces me to replicate some
rules across clients and devices. Also, given the MS configuration
file, some of this validation is for the file itself because in
that system, transition declarations are pushed out of the UI
presentation file itself. So I am wrong in the next statement.
>> Would I want to use the schema to find exceptions that modify user
process flow given this also
>>affects transition management? Likely not.
Again, I fall into the trap of thinking of THE schema and not
recognizing the system as a declarative ecosystem of schemas
and schema components.
>>Verify that data taken from many components are valid prior to performing
a batch
>>update? Ok. That looks like a good candidate. But is it?
Yes.
>Well, if you're trying to protect the back end from bad data (assuming
>it can't protect itself) then it seems like another good spot.
It is one of many schemas one might be using. So far, the idea
that the schema is a 'train wreck' seems to be false. However, relying
on one monolithic schema for all tasks is. Now we have a version
management issue.
>Given the current state of the Web I've come to assume that the ideal
>architecture would do duplicate validation.
Possibly. That is the Trust But Verify approach. The looser the coupling,
the more fit that approach becomes. Loose coupling weakens reliance
on correct-by-construction techniques. Otherwise I suspect we apply
XML at some scales of the system because we can.
len
|
