jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sh...@apache.org
Subject cvs commit: jakarta-taglibs/input README
Date Sun, 23 Sep 2001 17:37:42 GMT
shawn       01/09/23 10:37:42

  Modified:    input    README
  Log:
  (please ignore - sorry)
  
  Revision  Changes    Path
  1.3       +138 -137  jakarta-taglibs/input/README
  
  Index: README
  ===================================================================
  RCS file: /home/cvs/jakarta-taglibs/input/README,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- README	2001/07/14 16:05:02	1.2
  +++ README	2001/09/23 17:37:42	1.3
  @@ -1,137 +1,138 @@
  -
  -                            The "Input" Tag Library
  -                                       
  -What is the "Input" tag library?
  -
  -   The "input" tag extension library lets you present HTML <form>
  -   elements that are tied to the ServletRequest that caused the current
  -   JSP page to run. That is, using this library, you can easily
  -   prepopulate form elements with prior values that the user has chosen
  -   -- or with default values for the first time a user hits a web page.
  -   This is useful when you need to present the same page to the user
  -   several times (e.g., for server-side validation).
  -   
  -   You can also automatically build up <select> boxes, making it easier
  -   to build data-driven forms. And even if you don't present the same
  -   page multiple times, you may want form elements that have default
  -   values; this library lets you do that without writing excessive logic.
  -   
  -Rationale
  -
  -   Most web-based, server-side logic is accessed by users of HTML forms.
  -   Since for many applications, input validation is best done on the
  -   server side (for reasons of security, removal of business logic from
  -   the presentation layer, and so on), a typical process of input entry
  -   involves the following cycle (represented as pseudo-code because I'm
  -   in a lazy mood and don't need to describe it better):
  -
  -        browser requests form
  -        do {
  -            web server displays form
  -            user enters information and clicks "submit"
  -            browser POSTs information to web server
  -        } while (server determines that information is incomplete or invalid)
  -        server displays response to successful and complete input
  -
  -   With each presentation of the form, It generally makes sense to
  -   display the user's prior response in order to facilitate the
  -   explanation of why it's invalid. For example, it's considerably more
  -   helpful to a user to show something like:
  -
  -        Problems encountered:
  -        * Invalid email address!
  -          (Email addresses are of the form user@host.domain)
  -        ------------------------------
  -
  -           Name:  Shawn Bayern
  -        ** Email: bayern@incomplete
  -           Sex:   Male
  -           [etc.]
  -
  -   than simply to say "invalid email address" and present an empty spot
  -   on the form next to "Email."
  -   
  -   The problem that authors of systems of this type face is that there's
  -   no strong binding between HTML and data; it's therefore tedious to
  -   construct an HTML form that contains the user's prior response. To
  -   give you an idea, here's a section of HTML and Java from a JSP project
  -   I just finished (quoted approximately):
  -
  -        <select ...>
  -        <% for (int i = 1; i <= x; i++) { %>
  -          <option <%= !firstRunThrough
  -                ? sel(Integer.toString(i), prior)
  -                : sel(i,now.get(default)) %>
  -                ><%= i %></option>
  -        <% } %>
  -        </select>
  -
  -   And it's only that "clean" because I abstracted away two different
  -   sel() functions, one that takes ints and one that takes Strings, both
  -   of which return the String "selected" if their arguments match. These
  -   functions are included at the top of every page that needs them.
  -   
  -   This sort of application cries out for some sort of macro- or
  -   meta-language, and tag libraries for JSP fit in quite nicely. This
  -   sort of problem is a clear-cut case where repetitive work can be cut
  -   down through the use of something that acts as the moral equivalent of
  -   a macro language.
  -   
  -   I've therefore decided to write and provide contribute to the Jakarta
  -   project -- hoping to make web-application developers' lives a little
  -   easier -- a custom tag library called "input" that presents HTML form
  -   elements that are prepopulated with default input. The developer
  -   selects the default input and uses Maps and other objects as necessary
  -   to communicate between the page and the tag library in cases where
  -   input benefits from (to the point where it's almost accurate to say
  -   "requires") something more structured than Strings (which are the
  -   default and usual mediator). The tag library is designed with
  -   ease-of-use and ease of reading code that uses it in mind.
  -   
  -Miscellaneous notes
  -
  -   To make the library more useful, I've taken care to make sure that it
  -   quotes appropriate HTML entities correctly, itself, in attribute
  -   values and textboxes so that users can input characters like & and ",
  -   and your application can do the right thing automatically. You don't
  -   have to worry about whether the user has entered a " in a web form,
  -   which would screw up the HTML you output back to the user unless
  -   handled:
  -
  -        <input type="text" name="blah"
  -            value="you typed a "quoted" string the last time" />
  -
  -   Instead of the tag above, the library will output
  -
  -        <input type="text" name="blah"
  -            value="you typed a &quot;quoted&quot; string the last time" />
  -
  -   This library differs from similar ones in a number of ways. It
  -   attempts to be more general than the similar tags that JRun's tag
  -   library supports; this one is open-source, first of all, which I don't
  -   believe JRun's is, and it isn't tied to HTML 4.0 attributes. Since you
  -   pass in an "attributes" map, you can include whatever attribute/value
  -   pairs you'd like.
  -   
  -   Joseph Ottinger's [1]Form Taglib is thorough and reasonably similar to
  -   mine in terms of what it can do. I've optimized mine for a special
  -   case -- tying data to the ServletRequest object -- and tried to make
  -   it particularly easy to use regardless of how your application
  -   structures its data. That is, you don't have to use JavaBeans or
  -   create any new classes at all to use this library. You might find that
  -   Ottinger's fits your needs better or works more generally with your
  -   data, and his library provides support for building up an entire <form>,
  -   JavaScript validation, and so on -- stuff I've stayed away from for
  -   reasons entirely related to personal opinions and nothing more. (I
  -   personally use server-side validation more than client-side validation
  -   for just about everything.) His library seems great, overall; pick
  -   whichever one seems to make your life easier at the time you're
  -   deciding.
  -   
  -   
  -    Shawn Bayern
  -    shawn.bayern@oooo.com
  -
  -References
  -
  -   1. http://adjacency.org/formtags.jsp
  +
  +                            The "Input" Tag Library
  +                                       
  +What is the "Input" tag library?
  +
  +   The "input" tag extension library lets you present HTML <form>
  +   elements that are tied to the ServletRequest that caused the current
  +   JSP page to run. That is, using this library, you can easily
  +   prepopulate form elements with prior values that the user has chosen
  +   -- or with default values for the first time a user hits a web page.
  +   This is useful when you need to present the same page to the user
  +   several times (e.g., for server-side validation).
  +   
  +   You can also automatically build up <select> boxes, making it easier
  +   to build data-driven forms. And even if you don't present the same
  +   page multiple times, you may want form elements that have default
  +   values; this library lets you do that without writing excessive logic.
  +   
  +Rationale
  +
  +   Most web-based, server-side logic is accessed by users of HTML forms.
  +   Since for many applications, input validation is best done on the
  +   server side (for reasons of security, removal of business logic from
  +   the presentation layer, and so on), a typical process of input entry
  +   involves the following cycle (represented as pseudo-code because I'm
  +   in a lazy mood and don't need to describe it better):
  +
  +        browser requests form
  +        do {
  +            web server displays form
  +            user enters information and clicks "submit"
  +            browser POSTs information to web server
  +        } while (server determines that information is incomplete or invalid)
  +        server displays response to successful and complete input
  +
  +   With each presentation of the form, It generally makes sense to
  +   display the user's prior response in order to facilitate the
  +   explanation of why it's invalid. For example, it's considerably more
  +   helpful to a user to show something like:
  +
  +        Problems encountered:
  +        * Invalid email address!
  +          (Email addresses are of the form user@host.domain)
  +        ------------------------------
  +
  +           Name:  Shawn Bayern
  +        ** Email: bayern@incomplete
  +           Sex:   Male
  +           [etc.]
  +
  +   than simply to say "invalid email address" and present an empty spot
  +   on the form next to "Email."
  +   
  +   The problem that authors of systems of this type face is that there's
  +   no strong binding between HTML and data; it's therefore tedious to
  +   construct an HTML form that contains the user's prior response. To
  +   give you an idea, here's a section of HTML and Java from a JSP project
  +   I just finished (quoted approximately):
  +
  +        <select ...>
  +        <% for (int i = 1; i <= x; i++) { %>
  +          <option <%= !firstRunThrough
  +                ? sel(Integer.toString(i), prior)
  +                : sel(i,now.get(default)) %>
  +                ><%= i %></option>
  +        <% } %>
  +        </select>
  +
  +   And it's only that "clean" because I abstracted away two different
  +   sel() functions, one that takes ints and one that takes Strings, both
  +   of which return the String "selected" if their arguments match. These
  +   functions are included at the top of every page that needs them.
  +   
  +   This sort of application cries out for some sort of macro- or
  +   meta-language, and tag libraries for JSP fit in quite nicely. This
  +   sort of problem is a clear-cut case where repetitive work can be cut
  +   down through the use of something that acts as the moral equivalent of
  +   a macro language.
  +   
  +   I've therefore decided to write and provide contribute to the Jakarta
  +   project -- hoping to make web-application developers' lives a little
  +   easier -- a custom tag library called "input" that presents HTML form
  +   elements that are prepopulated with default input. The developer
  +   selects the default input and uses Maps and other objects as necessary
  +   to communicate between the page and the tag library in cases where
  +   input benefits from (to the point where it's almost accurate to say
  +   "requires") something more structured than Strings (which are the
  +   default and usual mediator). The tag library is designed with
  +   ease-of-use and ease of reading code that uses it in mind.
  +   
  +Miscellaneous notes
  +
  +   To make the library more useful, I've taken care to make sure that it
  +   quotes appropriate HTML entities correctly, itself, in attribute
  +   values and textboxes so that users can input characters like & and ",
  +   and your application can do the right thing automatically. You don't
  +   have to worry about whether the user has entered a " in a web form,
  +   which would screw up the HTML you output back to the user unless
  +   handled:
  +
  +        <input type="text" name="blah"
  +            value="you typed a "quoted" string the last time" />
  +
  +   Instead of the tag above, the library will output
  +
  +        <input type="text" name="blah"
  +            value="you typed a &quot;quoted&quot; string the last time" />
  +
  +   This library differs from similar ones in a number of ways. It
  +   attempts to be more general than the similar tags that JRun's tag
  +   library supports; this one is open-source, first of all, which I don't
  +   believe JRun's is, and it isn't tied to HTML 4.0 attributes. Since you
  +   pass in an "attributes" map, you can include whatever attribute/value
  +   pairs you'd like.
  +   
  +   Joseph Ottinger's [1]Form Taglib is thorough and reasonably similar to
  +   mine in terms of what it can do. I've optimized mine for a special
  +   case -- tying data to the ServletRequest object -- and tried to make
  +   it particularly easy to use regardless of how your application
  +   structures its data. That is, you don't have to use JavaBeans or
  +   create any new classes at all to use this library. You might find that
  +   Ottinger's fits your needs better or works more generally with your
  +   data, and his library provides support for building up an entire <form>,
  +   JavaScript validation, and so on -- stuff I've stayed away from for
  +   reasons entirely related to personal opinions and nothing more. (I
  +   personally use server-side validation more than client-side validation
  +   for just about everything.) His library seems great, overall; pick
  +   whichever one seems to make your life easier at the time you're
  +   deciding.
  +   
  +   
  +    Shawn Bayern
  +    shawn.bayern@oooo.com
  +
  +References
  +
  +   1. http://adjacency.org/formtags.jsp
  +
  
  
  

Mime
View raw message