Form validation for multi-rows and multi-columns

[Jean]

Hello All,

I have a classical ASP form with multi-rows and multi-columns that allows
users to enter multiple records at once. How do you check input forms for
errors and, if necessary, display messages plus row number and field to the
user?



Thanks!



Jean

[Ken Schaefer]

Name the rows/columns using some kind of loop, then validate using the same
looping syntax.

For example, if you call all your fields;

txt_1a txt_1b txt_1c
txt_2a txt_2b txt_2c

You can dump out all the values in the first line like so:

<%
For Each Item in Request.Form

If Mid(Item, 5, 1) = 1 then

Response.Write(Item & " = " & Request.Form(Item) & "<br>")

End If

Next
%>

or you could do all the text fields in the "second column" like this:

<%
For Each Item in Request.Form

If Mid(Item, 6, 1) = "b" then

Response.Write(Item & " = " & Request.Form(Item) & "<br>")

End If

Next
%>

and so forth.



"Jean" <jeanwang@email.arizona.edu> wrote in message
news:uUN83y1nDHA.2676@TK2MSFTNGP11.phx.gbl...
: Hello All,
:
: I have a classical ASP form with multi-rows and multi-columns that allows
: users to enter multiple records at once. How do you check input forms for
: errors and, if necessary, display messages plus row number and field to
the
: user?
:
:
:
: Thanks!
:
:
:
: Jean
:
:

[Nicole Calinoiu]

Ouch. That's a lot of work, a lot of code, and a lot of fun to maintain.
<g>

VBScript supports the use of user-defined classes, and this sort of setup is
a wonderful use for them. e.g.:

Class InputRow

Private Property Get RowID()...
Priate Function FullInputName(strBaseName)...

Public Sub Initialize()...
Public Sub Validate()...
Public Sub SaveData()...
Public Sub RenderUI()...

Public Property Get HasValidationErrors()...
...

End Class

Each row could be represented by an instance of this class held in a
dictionary object. Then each section of the main page operations could be
run as a loop through the dictionary.

Nicole



"Ken Schaefer" <kenREMOVE@THISadOpenStatic.com> wrote in message
news:OH4zVj2nDHA.2964@tk2msftngp13.phx.gbl...

> Name the rows/columns using some kind of loop, then validate using the

same

> looping syntax.
>
> For example, if you call all your fields;
>
> txt_1a txt_1b txt_1c
> txt_2a txt_2b txt_2c
>
> You can dump out all the values in the first line like so:
>
> <%
> For Each Item in Request.Form
>
> If Mid(Item, 5, 1) = 1 then
>
> Response.Write(Item & " = " & Request.Form(Item) & "<br>")
>
> End If
>
> Next
> %>
>
> or you could do all the text fields in the "second column" like this:
>
> <%
> For Each Item in Request.Form
>
> If Mid(Item, 6, 1) = "b" then
>
> Response.Write(Item & " = " & Request.Form(Item) & "<br>")
>
> End If
>
> Next
> %>
>
> and so forth.
>
>
>
> "Jean" <jeanwang@email.arizona.edu> wrote in message
> news:uUN83y1nDHA.2676@TK2MSFTNGP11.phx.gbl...
> : Hello All,
> :
> : I have a classical ASP form with multi-rows and multi-columns that

allows

> : users to enter multiple records at once. How do you check input forms

for

> : errors and, if necessary, display messages plus row number and field to
> the
> : user?
> :
> :
> :
> : Thanks!
> :
> :
> :
> : Jean
> :
> :
>
>

[Aaron Bertrand [MVP]]

> Each row could be represented by an instance of this class held in a

> dictionary object. Then each section of the main page operations could be
> run as a loop through the dictionary.

Wow, and you find that *easier* to maintain than iteration code?

[Nicole Calinoiu]

Much. Encapsulation is a very handy thing.

Consider the complicating factor of redisplaying invalid user input as
originally entered after validation errors. If you don't use the class
approach, you'll need to store all the data in arrays or whatever just to
read it back for rendering (unless, of course, you always read directly out
of the request, which is a rather ugly solution in other ways). The class
can simply have a member variable for each input element. The values are
written on validation, read on rendering. If you want to add a new input
element to each row, just add the member variable to the class, and add
handling to each of the reader and writer procedures within the class. No
new collections, indices, etc. need to be added to the main page (aside from
possible feeding of data into the class if reading from the db).

It's also quite handy if row behaviour needs to differ based on some state
marker. Even though VBScript classes don't support inheritance, it can be
mimicked via composition. As long as you stick to a single interface
throughout the possible composition chain, some potentially very nasty
procedural code can be replaced by reasonably clean pseudo-OOP code.
Instead of using ridiculous sets of nested ifs within each procedural loop
(read from db, read from request, validate, save, render), you only need to
make these decisions when figuring out which class will be used to represent
a row.

And if you're getting the feeling that I can't wait until I never have to
touch an ASP.OLD app again, you might just be right... <g>




"Aaron Bertrand [MVP]" <aaron@TRASHaspfaq.com> wrote in message
news:eX9XEn%23nDHA.3700@TK2MSFTNGP11.phx.gbl...

> > Each row could be represented by an instance of this class held in a
> > dictionary object. Then each section of the main page operations could

be

> > run as a loop through the dictionary.

>
> Wow, and you find that *easier* to maintain than iteration code?
>
>

[Ken Schaefer]

I didn't suggest anything like this because it seems that the OP isn't at
the point of iterating collections yet. A solution like this is probably way
too complicated to be implemented by OP at the moment.

That said, I'm curious to know how you represent a "row", considering that
its merely a visual intepretation of a bunch of HTML form elements on a
webpage.

Cheers
Ken

"Nicole Calinoiu" <nicolec@somewhere.net> wrote in message
news:eUSvK89nDHA.2312@TK2MSFTNGP12.phx.gbl...
: Ouch. That's a lot of work, a lot of code, and a lot of fun to maintain.
: <g>
:
: VBScript supports the use of user-defined classes, and this sort of setup
is
: a wonderful use for them. e.g.:
:
: Class InputRow
:
: Private Property Get RowID()...
: Priate Function FullInputName(strBaseName)...
:
: Public Sub Initialize()...
: Public Sub Validate()...
: Public Sub SaveData()...
: Public Sub RenderUI()...
:
: Public Property Get HasValidationErrors()...
: ...
:
: End Class
:
: Each row could be represented by an instance of this class held in a
: dictionary object. Then each section of the main page operations could be
: run as a loop through the dictionary.
:
: Nicole
:
:
:
: "Ken Schaefer" <kenREMOVE@THISadOpenStatic.com> wrote in message
: news:OH4zVj2nDHA.2964@tk2msftngp13.phx.gbl...
: > Name the rows/columns using some kind of loop, then validate using the
: same
: > looping syntax.
: >
: > For example, if you call all your fields;
: >
: > txt_1a txt_1b txt_1c
: > txt_2a txt_2b txt_2c
: >
: > You can dump out all the values in the first line like so:
: >
: > <%
: > For Each Item in Request.Form
: >
: > If Mid(Item, 5, 1) = 1 then
: >
: > Response.Write(Item & " = " & Request.Form(Item) & "<br>")
: >
: > End If
: >
: > Next
: > %>
: >
: > or you could do all the text fields in the "second column" like this:
: >
: > <%
: > For Each Item in Request.Form
: >
: > If Mid(Item, 6, 1) = "b" then
: >
: > Response.Write(Item & " = " & Request.Form(Item) & "<br>")
: >
: > End If
: >
: > Next
: > %>
: >
: > and so forth.
: >
: >
: >
: > "Jean" <jeanwang@email.arizona.edu> wrote in message
: > news:uUN83y1nDHA.2676@TK2MSFTNGP11.phx.gbl...
: > : Hello All,
: > :
: > : I have a classical ASP form with multi-rows and multi-columns that
: allows
: > : users to enter multiple records at once. How do you check input forms
: for
: > : errors and, if necessary, display messages plus row number and field
to
: > the
: > : user?
: > :
: > :
: > :
: > : Thanks!
: > :
: > :
: > :
: > : Jean
: > :
: > :
: >
: >
:
:

[Nicole Calinoiu]

"Ken Schaefer" <kenREMOVE@THISadOpenStatic.com> wrote in message
news:exVU7QDoDHA.2188@TK2MSFTNGP11.phx.gbl...

> I didn't suggest anything like this because it seems that the OP isn't at
> the point of iterating collections yet. A solution like this is probably

way

> too complicated to be implemented by OP at the moment.

I'm guessing the "OP" means the person who asked the question. If so,
you're very likely correct. However, I've personally spent lots of time
over the years learning various ways to do things that I wasn't "ready" to
do, and it was often worth the effort. (Time spent learning a better
approach was usually quickly paid back during implementation and debugging.)
While I wouldn't necessarily recommend the class-based solution to someone
who feels really uncomfortable with the approach, it is (at least IMO <g>)
considerably easier to debug, maintain, and extend. The complexity lies in
the design, not the implementation, and even the design isn't truly complex
if one is reasonably familiar with OOP and already understands the reading,
validating, persisting, and rendering cycles of ASP server-side processing.

> That said, I'm curious to know how you represent a "row", considering that
> its merely a visual intepretation of a bunch of HTML form elements on a
> webpage.

I used the name "InputRow" just to stick with the generic nature of the
question itself. What's being represented isn't really a "row" at all, but
rather the logic needed to read and write (from/to persistent data storage
or a proxy and from/to the UI) the data for a particular entity. Amongst
other things, the class "knows" how to Response.Write the HTML that will
represent the entity on the page, but that's far from its only purpose.

Personally, I very strongly recommend against creating tabular data entry
UIs of this type in web applications. The risks of losing user changes to
the data are just too high (e.g.: network problems, server problems, user
clicks on link in an e-mail that replace the data entry page in their
browser). I generally try to keep any form to within 5-15 input elements
(depending on type, context, etc.) in an effort to minimize the chances of
such data loss, and this would preclude the kind of UI we are discussing
here.

That said, I have still had ample opportunity to create variations on the
theme, usually dealing with different subclasses of entities. The rendering
is in a non-tabular list, but the "behind the scenes" challenges are nearly
identical. I've used the class-based approach for these ever since it
became available, and never regretted the decision for a second. If I ever
have a client who insists on a tabular data entry UI despite my
recommendations, I wouldn't hesistate to use the same approach.

Quite honestly, I'm a wee bit surprised by the level of, well, "surprise" in
this thread. I would have expected that this would be a technique in
relatively common use by now. Since it seems that I was wrong, I'm going to
mock up a small sample based on the tabular UI approach and post a download
URL to this thread in the next couple of days or so.

[Nicole Calinoiu]

The sample I promised is available at
[url]http://ca.msnusers.com/BordeCal/Documents/ASP%2FMultiRowUI.zip[/url]. If you want
to actually run it, you'll need to change the connection string as mentioned
in the readme file.

The scenario I chose for the sample is a page used to maintain a list of
links that will be shown on a site. For each link, the following
information can be entered:

URL: the href for the anchor tag
Display text: the text that will displayed in the link
Target: the target attribute of the anchor tag
Start date: the first date on which the link may be displayed
End date: the last date on which the link may be displayed (or empty for
perpetual display)

I started out trying to write a "simple" little sample, but it turns out
there's nothing simple about allowing both insertions and updates in this
kind of UI, so it ended up a lot more complex than I originally intended.
My apologies, but it's the nature of the beastie...

(BTW, there is a big problem in the sample wrt potential concurrent CUD
operations. This is reasonably easy to address with SQL Server, but not so
easy with Access. In order to avoid making the sample even more complicated
than it already is, I chose to ignore this issue entirely.)

If you want to test my ease of maintainability and extensibility claims, try
making any of the following modifications listed below (they are listed in
more-or-less increasing order of difficulty) after you've become familiar
with the design of the sample:

1. Add a button after the text box in the URL column to test the currently
displayed URL by attempting to open it in a new window.

2. The display text for a link is currently required. Without changing
anything in the db, allow the user to leave it blank, but use the URL in its
place if it's not supplied by the user. If no display text is supplied, the
URL should be used instead as soon as possible. e.g.: If there's a
validation error and the data needs to be redisplayed, the user should
already see the URL in place of the empty display text.

3. In the current implementation, the database is updated for each row,
regardless of whether it's actually been changed by the user. Change this
behaviour so that only rows that have actually been edited are saved upon a
valid submission.

4. The current implementation only allows pure date (without time) values
to be specified for the displayable interval endpoints. Change this to
allow complete date/time values (down to minutes) to be supplied. If a time
value is not supplied, assume it is 00:00.

5. In the current implementation, any validation error on the page will
result in no rows being saved. i.e.: A completely valid submission must be
achieved before any data is written to the db. Change this so that any
valid row can be saved, regardless of what's happening on the other rows.
(Hint: watch out for for the ReadDbData call at the end of the
SaveRequestData procedure.)

6. Migrate the db to SQL Server or MSDE then get rid of the concurrent CUD
problem.

[William Tasso]

Nicole Calinoiu wrote:

> The sample I promised is available at
> [url]http://ca.msnusers.com/BordeCal/Documents/ASP%2FMultiRowUI.zip[/url].
> ...

Responds with:

"Please click the button below to continue. This manual step is neccessary
because your browser has scripting disabled"

'click' leads to login page.

--
William Tasso - [url]http://WilliamTasso.com[/url]

[Nicole Calinoiu]

Hmm... It's an MSN group, so I have little control over its behaviour. Try
going to [url]http://groups.msn.com/BordeCal/documents.msnw?fc_p=%2FASP[/url]. The
sample is the only file there. If you're asked for a login, it's should be
just MSN asking for your passport in order to figure out your permissions in
the group. I've set up the group for full public read access, so you
shouldn't have to join in order to download the file.


"William Tasso" <news27@tbdata.com> wrote in message
news:uFbzS8NoDHA.2432@TK2MSFTNGP10.phx.gbl...

> Nicole Calinoiu wrote:

> > The sample I promised is available at
> > [url]http://ca.msnusers.com/BordeCal/Documents/ASP%2FMultiRowUI.zip[/url].
> > ...

>
> Responds with:
>
> "Please click the button below to continue. This manual step is neccessary
> because your browser has scripting disabled"
>
> 'click' leads to login page.
>
> --
> William Tasso - [url]http://WilliamTasso.com[/url]
>
>

[Nicole Calinoiu]

Dug a little deeper into the msn groups help, and it looks like there's no
way to view downloads without joining. Bit of a PITA. I've copied the
sample to [url]http://pages.infinit.net/curtains/samples/asp/multirowui.zip[/url],
which should not require any login whatsoever. Just watch out for the
URL--it's case sensitive and should be all lower case.


"William Tasso" <news27@tbdata.com> wrote in message
news:uFbzS8NoDHA.2432@TK2MSFTNGP10.phx.gbl...

> Nicole Calinoiu wrote:

> > The sample I promised is available at
> > [url]http://ca.msnusers.com/BordeCal/Documents/ASP%2FMultiRowUI.zip[/url].
> > ...

>
> Responds with:
>
> "Please click the button below to continue. This manual step is neccessary
> because your browser has scripting disabled"
>
> 'click' leads to login page.
>
> --
> William Tasso - [url]http://WilliamTasso.com[/url]
>
>

[Ken Schaefer]

Hi Nicole,

I had a look through your code, and the concept of a "row" of data is hard
coded into your class file. To capture all the rows you do a loop from 1 to
m (where m is the number of rows).

Now, I realise that you could reconstruct the columns by peeking into the
database schema again (but we obviously also need rules to exclude certain
fields from the initial display, and when reconstructing the object), but if
you don't know at run-time what the columns are, then you're back to doing
some kind of loop, either in the main body of the code, or in the class.

So, in essence, you need to do some kind of iteration/loop, regardless of
whether you have a class, or just inline code, and then we're back to what I
posted.

I was interested to know if you'd developed something beyond this, since I
also use classes in my older ASP code. When I say "beyond", I meant some
kind of "automated" control/object reconstruction, similar to the way
ASP.Net works, where it recreates the control heirachy on postback, so we
can get the "row" back without the type of looping, or hard coding that we
have in ASP.

Cheers
Ken



"Nicole Calinoiu" <nicolec@somewhere.net> wrote in message
news:e3Jd3jIoDHA.2272@tk2msftngp13.phx.gbl...
: "Ken Schaefer" <kenREMOVE@THISadOpenStatic.com> wrote in message
: news:exVU7QDoDHA.2188@TK2MSFTNGP11.phx.gbl...
: > I didn't suggest anything like this because it seems that the OP isn't
at
: > the point of iterating collections yet. A solution like this is probably
: way
: > too complicated to be implemented by OP at the moment.
:
: I'm guessing the "OP" means the person who asked the question. If so,
: you're very likely correct. However, I've personally spent lots of time
: over the years learning various ways to do things that I wasn't "ready" to
: do, and it was often worth the effort. (Time spent learning a better
: approach was usually quickly paid back during implementation and
debugging.)
: While I wouldn't necessarily recommend the class-based solution to someone
: who feels really uncomfortable with the approach, it is (at least IMO <g>)
: considerably easier to debug, maintain, and extend. The complexity lies
in
: the design, not the implementation, and even the design isn't truly
complex
: if one is reasonably familiar with OOP and already understands the
reading,
: validating, persisting, and rendering cycles of ASP server-side
processing.
:
:
: > That said, I'm curious to know how you represent a "row", considering
that
: > its merely a visual intepretation of a bunch of HTML form elements on a
: > webpage.
:
: I used the name "InputRow" just to stick with the generic nature of the
: question itself. What's being represented isn't really a "row" at all,
but
: rather the logic needed to read and write (from/to persistent data storage
: or a proxy and from/to the UI) the data for a particular entity. Amongst
: other things, the class "knows" how to Response.Write the HTML that will
: represent the entity on the page, but that's far from its only purpose.
:
: Personally, I very strongly recommend against creating tabular data entry
: UIs of this type in web applications. The risks of losing user changes to
: the data are just too high (e.g.: network problems, server problems, user
: clicks on link in an e-mail that replace the data entry page in their
: browser). I generally try to keep any form to within 5-15 input elements
: (depending on type, context, etc.) in an effort to minimize the chances of
: such data loss, and this would preclude the kind of UI we are discussing
: here.
:
: That said, I have still had ample opportunity to create variations on the
: theme, usually dealing with different subclasses of entities. The
rendering
: is in a non-tabular list, but the "behind the scenes" challenges are
nearly
: identical. I've used the class-based approach for these ever since it
: became available, and never regretted the decision for a second. If I
ever
: have a client who insists on a tabular data entry UI despite my
: recommendations, I wouldn't hesistate to use the same approach.
:
: Quite honestly, I'm a wee bit surprised by the level of, well, "surprise"
in
: this thread. I would have expected that this would be a technique in
: relatively common use by now. Since it seems that I was wrong, I'm going
to
: mock up a small sample based on the tabular UI approach and post a
download
: URL to this thread in the next couple of days or so.
:
:

[Nicole Calinoiu]

"Ken Schaefer" <kenREMOVE@THISadOpenStatic.com> wrote in message
news:eSNV8tnoDHA.3040@TK2MSFTNGP11.phx.gbl...

> I had a look through your code, and the concept of a "row" of data is hard
> coded into your class file. To capture all the rows you do a loop from 1

to

> m (where m is the number of rows).

Yup. I never suggested that iteration wouldn't be required at all. I was
only trying to suggest that representing the UI/data "rows" using a class
leads to greater ease of maintainability/extensibility than a rows x columns
array approach.

> Now, I realise that you could reconstruct the columns by peeking into the
> database schema again (but we obviously also need rules to exclude certain
> fields from the initial display, and when reconstructing the object), but

if

> you don't know at run-time what the columns are, then you're back to doing
> some kind of loop, either in the main body of the code, or in the class.

Ouch. This is very dangerous. Very.

I was already cringing over the amount of information I allowed to be
provided by the client in the sample. For anything other than an DBA web
interface for direct editing of table data, I would definitely not recommend
a solution where even the columns are not know at design time, forget about
runtime. And even for a DBA web UI, I still wouldn't recommend this type of
multi-row editing interface. (See below for reasons.)

One exception is the different row "subclasses" I mentioned in an earlier
post. However, the nature of each subclass would be well defined at design
time, it's just the composition of the list wrt to the subtype of each row
that would only be known at runtime. An example would by a dynamic
questionnaire UI, where types of questions are well defined, but the make-up
of any given questionnaire is data-driven. However, this doesn't pose the
same dangers as the sample since the UI composition is entirely defined on
the server. Any "additional" information provided by the client can be
ignored completely.

> So, in essence, you need to do some kind of iteration/loop, regardless of
> whether you have a class, or just inline code, and then we're back to what

I

> posted.

"Vertical" iteration, yes, at least for everything besides reading from the
db. "Horizontal", not except in some very special circumstances.

> I was interested to know if you'd developed something beyond this, since I
> also use classes in my older ASP code. When I say "beyond", I meant some
> kind of "automated" control/object reconstruction, similar to the way
> ASP.Net works, where it recreates the control heirachy on postback, so we
> can get the "row" back without the type of looping, or hard coding that we
> have in ASP.

What do you think ASP.NET is doing under the hood to support the automated
reconstruction? <g> (For a bit of fun, decompile the DataGrid and Repeater
controls.) Could the same thing be done in ASP? Sure. Is it worthwhile?
Not for me since I would not use this type of UI in a production
application.

Actually, one of my biggest complaints about ASP.NET is that it makes it
much too easy to create this kind of UI. In addition, all the documentation
and samples I've seen sweep the concurrent CUD problem under the rug or
defer it to late detection at the time of the save. Unless only one user
could possibly be working with any given "row" over the lifetime of the page
on which the list resides, the row should be re-populated from the db
immediately prior to the edit since the data may very well have
changed/deleted since the list was originally populated. This is, of
course, possible using the ASP.NET controls, but I have yet to see it
recommended anywhere.

Of course, as long as you're making extra server and db round-trips to grab
the current data, you might as well do either of the following (in ASP or
ASP.NET):

1. Re-render the table with only one editable editable row, in which case
most of the iteration work drops away.

2. Instead of rendering the editable row in the table, use a popup window
for the editing, with potentially more user-friendly layout, more room for
explanations, error descriptions, etc. You'll also save the work of
re-rendering the non-editable parts of the table until after successful
submission of the edit.