Professional Web Applications Themes

Form validation for multi-rows and multi-columns - ASP Database

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...

  1. #1

    Default Form validation for multi-rows and multi-columns

    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


    Jean Guest

  2. #2

    Default Re: Form validation for multi-rows and multi-columns

    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" <jeanwangemail.arizona.edu> wrote in message
    news:uUN83y1nDHA.2676TK2MSFTNGP11.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
    :
    :


    Ken Schaefer Guest

  3. #3

    Default Re: Form validation for multi-rows and multi-columns

    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" <kenREMOVETHISadOpenStatic.com> wrote in message
    news:OH4zVj2nDHA.2964tk2msftngp13.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" <jeanwangemail.arizona.edu> wrote in message
    > news:uUN83y1nDHA.2676TK2MSFTNGP11.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 Guest

  4. #4

    Default Re: Form validation for multi-rows and multi-columns

    > 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?


    Aaron Bertrand [MVP] Guest

  5. #5

    Default Re: Form validation for multi-rows and multi-columns

    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]" <aaronTRASHaspfaq.com> wrote in message
    news:eX9XEn%23nDHA.3700TK2MSFTNGP11.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?
    >
    >

    Nicole Calinoiu Guest

  6. #6

    Default Re: Form validation for multi-rows and multi-columns

    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" <nicolecsomewhere.net> wrote in message
    news:eUSvK89nDHA.2312TK2MSFTNGP12.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" <kenREMOVETHISadOpenStatic.com> wrote in message
    : news:OH4zVj2nDHA.2964tk2msftngp13.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" <jeanwangemail.arizona.edu> wrote in message
    : > news:uUN83y1nDHA.2676TK2MSFTNGP11.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
    : > :
    : > :
    : >
    : >
    :
    :


    Ken Schaefer Guest

  7. #7

    Default Re: Form validation for multi-rows and multi-columns

    "Ken Schaefer" <kenREMOVETHISadOpenStatic.com> wrote in message
    news:exVU7QDoDHA.2188TK2MSFTNGP11.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 Guest

  8. #8

    Default Re: Form validation for multi-rows and multi-columns

    The sample I promised is available at
    [url]http://ca.msnusers.com/BordeCal/Doents/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.


    Nicole Calinoiu Guest

  9. #9

    Default Re: Form validation for multi-rows and multi-columns

    Nicole Calinoiu wrote:
    > The sample I promised is available at
    > [url]http://ca.msnusers.com/BordeCal/Doents/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]


    William Tasso Guest

  10. #10

    Default Re: Form validation for multi-rows and multi-columns

    Hmm... It's an MSN group, so I have little control over its behaviour. Try
    going to [url]http://groups.msn.com/BordeCal/doents.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" <news27tbdata.com> wrote in message
    news:uFbzS8NoDHA.2432TK2MSFTNGP10.phx.gbl...
    > Nicole Calinoiu wrote:
    > > The sample I promised is available at
    > > [url]http://ca.msnusers.com/BordeCal/Doents/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 Guest

  11. #11

    Default Re: Form validation for multi-rows and multi-columns

    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" <news27tbdata.com> wrote in message
    news:uFbzS8NoDHA.2432TK2MSFTNGP10.phx.gbl...
    > Nicole Calinoiu wrote:
    > > The sample I promised is available at
    > > [url]http://ca.msnusers.com/BordeCal/Doents/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 Guest

  12. #12

    Default Re: Form validation for multi-rows and multi-columns

    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" <nicolecsomewhere.net> wrote in message
    news:e3Jd3jIoDHA.2272tk2msftngp13.phx.gbl...
    : "Ken Schaefer" <kenREMOVETHISadOpenStatic.com> wrote in message
    : news:exVU7QDoDHA.2188TK2MSFTNGP11.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.
    :
    :


    Ken Schaefer Guest

  13. #13

    Default Re: Form validation for multi-rows and multi-columns

    "Ken Schaefer" <kenREMOVETHISadOpenStatic.com> wrote in message
    news:eSNV8tnoDHA.3040TK2MSFTNGP11.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 cirstances.

    > 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 doentation
    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.


    Nicole Calinoiu Guest

Similar Threads

  1. Implications for a multi lingual, multi curreny e commerce site ??
    By James Noon in forum Dreamweaver AppDev
    Replies: 1
    Last Post: April 17th, 09:27 PM
  2. Selecting multi columns into one ?
    By Gurra in forum ASP Database
    Replies: 6
    Last Post: February 28th, 04:43 PM
  3. multi-select box validation
    By Greg Bryant in forum PHP Development
    Replies: 1
    Last Post: November 8th, 02:58 AM
  4. [PHP] Javascript multi text box form validation?
    By Johnny Martinez in forum PHP Development
    Replies: 0
    Last Post: July 18th, 06:12 PM
  5. Javascript multi text box form validation?
    By Johnny Martinez in forum PHP Development
    Replies: 1
    Last Post: July 18th, 06:07 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139