Prevent user from entering punctuation

Discussion in 'HTML' started by PW, Jun 18, 2006.

  1. PW

    PW Guest

    Hi,

    Is there anyway to format a text input so the user cant enter punctuation
    marks?

    TIA,
    PW
     
    PW, Jun 18, 2006
    #1
    1. Advertising

  2. PW

    tbar Guest

    tbar, Jun 18, 2006
    #2
    1. Advertising

  3. PW wrote:
    > Hi,
    >
    > Is there anyway to format a text input so the user cant enter punctuation
    > marks?


    Before it is posted, your can use JavaScript to check the input, but
    that is no guarantee because the user may have JavaScript disabled. You
    should *always* check user input upon the receiving end at the
    server-side script. There is where you can make the final and absolute
    check of the input. You can either quietly filter out the unwanted
    characters or return to then previous form with an error message.

    --
    Take care,

    Jonathan
    -------------------
    LITTLE WORKS STUDIO
    http://www.LittleWorksStudio.com
     
    Jonathan N. Little, Jun 18, 2006
    #3
  4. PW

    tbar Guest

    Isn't Disney bound to a 3d thing for xmas
     
    tbar, Jun 18, 2006
    #4
  5. tbar wrote:

    > Isn't Disney bound to a 3d thing for xmas


    Ok. You've discovered Usenet. Now go away until you realize just what it
    is.

    --
    -bts
    -thinking about the killfile
     
    Beauregard T. Shagnasty, Jun 18, 2006
    #5
  6. PW

    PW Guest

    Yeah, thats what I was afraid of.

    Thanks for the info,
    PW




    "Jonathan N. Little" <> wrote in message
    news:ab3db$4494c287$40cba7a5$...
    > PW wrote:
    >> Hi,
    >>
    >> Is there anyway to format a text input so the user cant enter punctuation
    >> marks?

    >
    > Before it is posted, your can use JavaScript to check the input, but that
    > is no guarantee because the user may have JavaScript disabled. You should
    > *always* check user input upon the receiving end at the server-side
    > script. There is where you can make the final and absolute check of the
    > input. You can either quietly filter out the unwanted characters or return
    > to then previous form with an error message.
    >
    > --
    > Take care,
    >
    > Jonathan
    > -------------------
    > LITTLE WORKS STUDIO
    > http://www.LittleWorksStudio.com
     
    PW, Jun 18, 2006
    #6
  7. Beauregard T. Shagnasty wrote:
    > tbar wrote:
    >
    >> Isn't Disney bound to a 3d thing for xmas

    >
    > Ok. You've discovered Usenet. Now go away until you realize just what it
    > is.
    >


    Well, he thinks he's being clever,

    --
    Take care,

    Jonathan
    -------------------
    LITTLE WORKS STUDIO
    http://www.LittleWorksStudio.com
     
    Jonathan N. Little, Jun 18, 2006
    #7
  8. Beauregard T. Shagnasty wrote:
    > tbar wrote:
    >
    >> Isn't Disney bound to a 3d thing for xmas

    >
    > Ok. You've discovered Usenet. Now go away until you realize just what it
    > is.


    >--
    > -bts
    > -thinking about the killfile


    BtS encouraging it, as usual. :)

    --
    Blinky RLU 297263
    Killing all posts from Google Groups
    The Usenet Improvement Project: http://blinkynet.net/comp/uip5.html
    Coming Soon: Filtering rules specific to various real news clients
     
    Blinky the Shark, Jun 18, 2006
    #8
  9. Jonathan N. Little <> scripsit:

    > Before it is posted, your can use JavaScript to check the input, but
    > that is no guarantee because the user may have JavaScript disabled.
    > You should *always* check user input upon the receiving end at the
    > server-side script.


    In this particular case, the check should probably be made _only_ in the
    server.

    As a rule, it is a good idea to consider setting up client-side checking as
    well, after you have designed and implemented the server-side check.
    Immediate checking is good for usability and accessibility: the user gets an
    error message at an early phase where he remembers what he just did and has
    the context and position in front of his years, literally or figuratively.

    However, double checking tends to be expensive in terms of implementation
    and maintenance work. You normally use two quite different programming
    languages, JavaScript for client-side checking and something else for
    server-side checking. This means duplicate coding; only the overall logic is
    the same. Moreover, any changes need to be implemented twice, and this means
    that some day you (or you successor as the maintainer) will forget this.
    Testing needs to be duplicated, too - with scripting enabled and scripting
    disabled. Testing the client-side checking is problematic, since there are
    differences between browsers in JavaScript implementations.

    So although it is a good idea to _consider_ client-side checking, due
    consideration does not that often lead to _implementation_ of client-side
    checking. In this particular case, the problem is particular hard. It is
    much harder than people naively think, since they typically imply the ASCII
    character repertoire.

    A well-designed form handler is prepared to anything, including any Unicode
    character in input data, since there is no reliable way to prevent users
    from inputing any character, intentionally or accidentally. And when your
    data is Unicode data, the question "what is a punctuation character?" is far
    from trivial. Apparently e.g. Arabic triple dot punctuation mark and Greek
    ano teleia and Tibetan mark tsheg shad are punctuation marks, right? Would
    you even include all characters with a General Category value starting with
    "P"? And no other? That would be a technically simple definition, and you
    could write the check using a suitable function in a suitable subroutine
    library - if you use an advanced programming language. But would that really
    match what you want it to match?

    My point here is that you probably want to define a _positive_ rule (which
    characters are allowed) rather than a negative rule (which characters are
    not allowed). The rule should correspond to the repertoire of characters
    that your form handler and other software and data formats involved are
    prepared to handle. There's no point in accepting a character on input if it
    will be lost or distorted in the actual processing, e.g. when saving to a
    database.

    --
    Jukka K. Korpela ("Yucca")
    http://www.cs.tut.fi/~jkorpela/
     
    Jukka K. Korpela, Jun 18, 2006
    #9
  10. PW

    code_wrong Guest

    "PW" <> wrote in message
    news:SX1lg.11231$...
    >
    > Hi,
    >
    > Is there anyway to format a text input so the user cant enter punctuation
    > marks?
    >


    what's wrong with punctuation?
     
    code_wrong, Jun 18, 2006
    #10
  11. Jukka K. Korpela wrote:
    > Jonathan N. Little <> scripsit:
    >
    >> Before it is posted, your can use JavaScript to check the input, but
    >> that is no guarantee because the user may have JavaScript disabled.
    >> You should *always* check user input upon the receiving end at the
    >> server-side script.

    >
    > In this particular case, the check should probably be made _only_ in the
    > server.
    >
    > As a rule, it is a good idea to consider setting up client-side checking
    > as well, after you have designed and implemented the server-side check.
    > Immediate checking is good for usability and accessibility: the user
    > gets an error message at an early phase where he remembers what he just
    > did and has the context and position in front of his years, literally or
    > figuratively.
    >
    > However, double checking tends to be expensive in terms of
    > implementation and maintenance work. You normally use two quite
    > different programming languages, JavaScript for client-side checking and
    > something else for server-side checking. This means duplicate coding;
    > only the overall logic is the same. Moreover, any changes need to be
    > implemented twice, and this means that some day you (or you successor as
    > the maintainer) will forget this. Testing needs to be duplicated, too -
    > with scripting enabled and scripting disabled. Testing the client-side
    > checking is problematic, since there are differences between browsers in
    > JavaScript implementations.
    >


    I agree that it makes more work for the designer, but the benefit is
    that it can give an advance tip to the user. I see benefit is
    accommodating the user. If you make it more convenient or accessible for
    them the more likely you will get their business! On dialup from
    experience it can be a real pisser to only discover your error after you
    posted the form and will have to do the process all over again.

    On the implementation side I took the time to create a pair of script
    PHP and JavaScript , I created an validation class object in each and
    the base validation is set in my PHP and the PHP object creates upon
    loading the document the JavaScript to load the same checking values
    into the JavaScript object to keep everything synced. It was worth the
    initial effort so now I only have to include the PHP class and attach
    the JavaScript class then in the doc setup up the PHP object. The rest
    is done automatically and if the user has JavaScript enabled client-side
    checking will be enabled.

    What one must be careful of it that their JavaScript validation does not
    cause an endless loop when can happen with improper blur|focus handling...

    --
    Take care,

    Jonathan
    -------------------
    LITTLE WORKS STUDIO
    http://www.LittleWorksStudio.com
     
    Jonathan N. Little, Jun 18, 2006
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Chris Leffer

    Regular expression for punctuation

    Chris Leffer, Jul 9, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    437
    Chris Leffer
    Jul 9, 2003
  2. =?Utf-8?B?bWdAdGhld29ybGQuY29t?=

    Prevent entering data into DB twice

    =?Utf-8?B?bWdAdGhld29ybGQuY29t?=, Jun 9, 2004, in forum: ASP .Net
    Replies:
    3
    Views:
    573
    ASP.Confused
    Jun 9, 2004
  3. =?Utf-8?B?Qw==?=

    restrict the user entering nonalphanumeric keys?

    =?Utf-8?B?Qw==?=, Jun 13, 2007, in forum: ASP .Net
    Replies:
    1
    Views:
    578
    =?Utf-8?B?TWlsb3N6IFNrYWxlY2tpIFtNQ0FEXQ==?=
    Jun 13, 2007
  4. Chris Carlen
    Replies:
    1
    Views:
    627
    Gabriel Genellina
    Sep 18, 2007
  5. PW

    Prevent entry of punctuation

    PW, Jun 18, 2006, in forum: ASP General
    Replies:
    1
    Views:
    129
    Evertjan.
    Jun 18, 2006
Loading...

Share This Page