Lists Home |
Date Index |
Bullard, Claude L (Len) <firstname.lastname@example.org> 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
Cheap shot: as far away as possible....
> A user interface is likely doing all of the following:
> 1 Managing the flow of information through the user interface
> 2 Managing the transitions between stages of a user interface process
> 3 Modifying user process flow in response to exceptions
> 4 Separating the conceptual user interaction flow from the
implementation or device where it occurs
> 5 Maintaining internal business-related state, usually by holding on
to one or more business entities > that are affected by
> the user interaction
> 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"
> It seems to me that items 3,5 and 6 are pertinent.
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?
> Would I want to use the schema
> to find exceptions that modify user process flow given this also
> management? Likely not. Maintain internal business state? No.
Verify that data
> taken from many components are valid priot to performing a batch
update? Ok. That
> looks like a good candidate. But is it?
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. Given
the current state of the Web I've come to assume that the ideal
architecture would do duplicate validation. Once up front with fancy
circumvent the normal UI. Never built such a system, but with our
current system it would be relatively easy (a couple person months) to