RE: Editable forms on the web

Caveat: I'm not exactly sure I have the way your back-end people want to do
this correct in my head:

> The back-end developers, who are all coming from a client-server point of
> view, think that this process is too time consuming.  Instead,
> they want one
> page that displays the record in editable fields.  They also want the user
> to be able to query mulitple records, and then have the records
> be displayed
> on a page, again in editable fields.
>
> I keep telling them that this is not the way the web works, but
> they're not
> listening.  I keep telling them that this is the web, not client
> server.  I
> keep telling them that my solution is 508 and WCAG compliant, but
> they don't
> care.

What do you mean by "the web". If you mean HTTP and HTML then you're pretty
much correct, there are ways of doing things closer to what they suggest,
but they are likely to end up being worse from a client-server point of view
unless they use some pretty hard-core client-side processing of a kind that
won't be available on many browsers.

If you mean HTTP, and you just happened to chose HTML in a browser for your
presentation layer then something like the way they suggest seems reasonable
enough, as long as usability and accessibility issues in the custom software
you build are resolved.

> All they care about is that transactions to the server are going
> to slow the
> system down.  I told them that if that's the case, then we shouldn't be in
> this business.

I'm not too sure they're 100% correct about this. If you make some or all of
the client-server communication stateless (which you are doing if you are
using multiple SELECTs and UPDATEs and closing database connections when you
are finished as opposed to editable recordsets, even if there is stateful
stuff going on with the webserver <-> browser communication) then that
brings it's own performance benefits. Systems built on MTS and its rivals
generally perform better when you don't maintain database connections. When
you factor in the fact that you don't have the same locking requirements for
your SELECTs then I wouldn't be surprised to find that their solution (if I
gather it correctly from what you say) starts off as faster but doesn't
scale as well as your solution.

The only way to know for sure is to do a realistic stress-test on both
systems.

Received on Wednesday, 3 July 2002 10:37:22 UTC