Re: How to pass an integer array from a form to a JSP page
In javascript do not pre-size the array, let it grow as it needs to by adding on to the end as needed (javascript can do this). This way you will not get all those additional trailing comma's. In your servelt if you decide you do want to parse the string use the StringTokenizer class. -Original Message- From: C. Orlando Monzon [SMTP:[EMAIL PROTECTED]] Sent: 31 October 2002 06:10 To: [EMAIL PROTECTED] Subject: Re: How to pass an integer array from a form to a JSP page Thanks for your suggestions. I was able to pass the array as a String. String myarra = request.getParameter(field_name); in my javascript still have the array(256) and when I submit the form a function assign myarrayHTML to the field_name. It passed like 4,5,3 Well the String get commas after my entry when I did not fill the array with 256 elements as it is the size of the array. Well, I got the conclusion that I do not need to change the String (that has my array) because in the createStament of JDBC I could use the string. I need ofcourse to fix the String to be a good String to include in the String that represents my Query. So I hope this way I will get my array of integers in my database. Question which function or package I need to use to get rid of the commas after my entries or to make my string nice to be included in my query? Thanks a lot Orlando == = To unsubscribe: mailto [EMAIL PROTECTED] with body: signoff JSP-INTEREST. For digest: mailto [EMAIL PROTECTED] with body: set JSP-INTEREST DIGEST. Some relevant FAQs on JSP/Servlets can be found at: http://archives.java.sun.com/jsp-interest.html http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.jsp http://www.jguru.com/faq/index.jsp http://www.jspinsider.com -- It is the strict policy of Truworths that its e-mail facility and all e-mail communications emanating therefrom, should be utilised for business purposes only and should conform to high professional and business standards. Truworths has stipulated certain regulations in terms whereof strict guidelines relating to the use and content of e-mail communications are laid down. The use of the Truworths e-mail facility is not permitted for the distribution of chain letters or offensive mail of any nature whatsoever. Truworths hereby distances itself from and accepts no liability in respect of the unauthorised use of its e-mail facility or the sending of e-mail communications for other than strictly business purposes. Truworths furthermore disclaims liability for any unauthorised instruction for which permission was not granted.Truworths Limited accepts no liability for any consequences arising from or as a result of reliance on this message unless it is in respect of bona fide Truworths business for which proper authorisation has been granted. Any recipient of an unacceptable communication, a chain letter or offensive material of any nature is requested to notify the Truworths e-mail administrator ([EMAIL PROTECTED]) immediately in order that appropriate action can be taken against the individual concerned. === To unsubscribe: mailto [EMAIL PROTECTED] with body: signoff JSP-INTEREST. For digest: mailto [EMAIL PROTECTED] with body: set JSP-INTEREST DIGEST. Some relevant FAQs on JSP/Servlets can be found at: http://archives.java.sun.com/jsp-interest.html http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.jsp http://www.jguru.com/faq/index.jsp http://www.jspinsider.com
Re: session nonpersistence
what if they move your account to a different server causing your urls to change to for e.g. www19.addr.com/~mgarde/somepage.html Now aint that gonna suck? -Original Message- From: Monte Gardner [SMTP:[EMAIL PROTECTED]] Sent: 31 October 2002 03:57 To: [EMAIL PROTECTED] Subject: Re: session nonpersistence I think I may have found the problem. My webserver (I rent space on a commercial webserver) does a strange thing with regards to URL's: when I type in www.addr.com/~mgardne/somepage.html the browser actually gets redirected to www22.addr.com/~mgardne/somepage.html the www gets changed to www22. I think the servlet container was looking at some of my URL's and getting confused as to what was coming from where or something. Anyway, I hard coded some of my url's to absolute urls's with the http://www22.addr.com in them, and my sessions work now. not a pretty fix I know, but atleast I have it working. --Monte Glenn Gardner On Wed, 30 Oct 2002, Monte Gardner wrote: soemoen else mentioned something about this. How do I tell if they are in dfferenet web-apps. all pages are in the same physical directory on the server. --Monte Glenn Gardner On Wed, 30 Oct 2002, Nimmons, Buster wrote: Also, if he jsp pages are in different web apps then each web application gets it's own session object and the objects are not replicated -Original Message- From: Shawn Bayern [mailto:bayern;ESSENTIALLY.NET] Sent: Wednesday, October 30, 2002 9:32 AM To: [EMAIL PROTECTED] Subject: Re: session nonpersistence On Wed, 30 Oct 2002, Monte Gardner wrote: I have a series of JSP pages that begin with a standard userid/password login. The page that receives the login request (shop.jsp) stores the id in the session like this session.setAttribute(id,id); when I print out session.getAttribute(id); on the same page, it prints the id of the user. However, once the user goes to the next page where he views products, and I try to print out the user id with session.getAttribute(id) or request.getSession().getAttribute(id) It prints out null. I have a previous project on the same server in which I did about the same thing, and it seems to work fine so I can't see what I'm doing different between the two. What can cause the session to forget stuff like this? Since HTTP is stateless, something actively needs to preserve the session; for instance, a session identifier can be conveyed by a cookie or as an addendum to the URL. It's possible that your browser isn't sending cookies back to the server; if it's not, and if you're not going out of your way to include the session identifier in links back to your application, then the server has no way of tying your multiple requests together into a session. To ensure you support sessions for browsers that aren't using cookies, make sure to encode the URL into all URLs that the application sends and that also point back to the application. The easiest way to ensure this in a JSP page is by printing all URLs through JSTL's c:url tag. -- Shawn Bayern JSTL in Action http://www.jstlbook.com == = To unsubscribe: mailto [EMAIL PROTECTED] with body: signoff JSP-INTEREST. For digest: mailto [EMAIL PROTECTED] with body: set JSP-INTEREST DIGEST. Some relevant FAQs on JSP/Servlets can be found at: http://archives.java.sun.com/jsp-interest.html http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.jsp http://www.jguru.com/faq/index.jsp http://www.jspinsider.com == = To unsubscribe: mailto [EMAIL PROTECTED] with body: signoff JSP-INTEREST. For digest: mailto [EMAIL PROTECTED] with body: set JSP-INTEREST DIGEST. Some relevant FAQs on JSP/Servlets can be found at: http://archives.java.sun.com/jsp-interest.html http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.jsp http://www.jguru.com/faq/index.jsp http://www.jspinsider.com == = To unsubscribe: mailto [EMAIL PROTECTED] with body: signoff JSP-INTEREST. For digest: mailto [EMAIL PROTECTED] with body: set JSP-INTEREST DIGEST. Some relevant FAQs on JSP/Servlets can be found at: http://archives.java.sun.com/jsp-interest.html http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.jsp http://www.jguru.com/faq/index.jsp http://www.jspinsider.com == = To unsubscribe: mailto [EMAIL PROTECTED] with body: signoff JSP-INTEREST. For digest: mailto [EMAIL PROTECTED]
Re: Document Security
I think that this is almost an impossible task. The only near conceivable way, is perhaps by containing the information within a Java Applet on your page. This would require a Java PDF reader, which would then access the file from an undisclosed location, without any options to save or print. But a very determined user could take screen shots and print those out. So, you can try to control access in a very round-about way, but I don't think you can ever fully prevent unwanted access. Regards, Peter Dolukhanov -Original Message- From: A mailing list about Java Server Pages specification and reference [mailto:JSP-INTEREST;JAVA.SUN.COM] On Behalf Of Vibha Jindal Sent: 01 November 2002 05:20 To: [EMAIL PROTECTED] Subject: Document Security Hi, This is off-topic, but I would appreciate if someone can guide me... I have certain documents, say pdf, on the server, and I want to allow certain users to access my documents and view them... The user should not be able to save, print etc. the document. Also, he should not be able to use/manipulate the temporary file that is created. Can someone please guide me? Thanks Regards, Vibha === To unsubscribe: mailto [EMAIL PROTECTED] with body: signoff JSP-INTEREST. For digest: mailto [EMAIL PROTECTED] with body: set JSP-INTEREST DIGEST. Some relevant FAQs on JSP/Servlets can be found at: http://archives.java.sun.com/jsp-interest.html http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.jsp http://www.jguru.com/faq/index.jsp http://www.jspinsider.com === To unsubscribe: mailto [EMAIL PROTECTED] with body: signoff JSP-INTEREST. For digest: mailto [EMAIL PROTECTED] with body: set JSP-INTEREST DIGEST. Some relevant FAQs on JSP/Servlets can be found at: http://archives.java.sun.com/jsp-interest.html http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.jsp http://www.jguru.com/faq/index.jsp http://www.jspinsider.com
Re: Document Security
A very very determined user can also find a way to intercept the stream going to the applet in the browser and make a copy of it, so the stream would need to be encrypted, however since the applet needs to decode it, it will need to have the key, which imples that a very^3 user could decompile the applet and pull it out. So I agree with Peter, basically by sending the document to thier computer you are giving them the document. This problem is better solved with wetware policy. If you don't trust them, don't give them the documents. Computers and the Internet are NOT there to give you additional control over people (despite Micro$oft$ EULA). In fact to my thinking the opposite is true. They are there to give all people more power and freedom. -Original Message- From: Peter Dolukhanov [SMTP:[EMAIL PROTECTED]] Sent: 01 November 2002 11:40 To: [EMAIL PROTECTED] Subject: Re: Document Security I think that this is almost an impossible task. The only near conceivable way, is perhaps by containing the information within a Java Applet on your page. This would require a Java PDF reader, which would then access the file from an undisclosed location, without any options to save or print. But a very determined user could take screen shots and print those out. So, you can try to control access in a very round-about way, but I don't think you can ever fully prevent unwanted access. Regards, Peter Dolukhanov -Original Message- From: A mailing list about Java Server Pages specification and reference [mailto:JSP-INTEREST;JAVA.SUN.COM] On Behalf Of Vibha Jindal Sent: 01 November 2002 05:20 To: [EMAIL PROTECTED] Subject: Document Security Hi, This is off-topic, but I would appreciate if someone can guide me... I have certain documents, say pdf, on the server, and I want to allow certain users to access my documents and view them... The user should not be able to save, print etc. the document. Also, he should not be able to use/manipulate the temporary file that is created. Can someone please guide me? Thanks Regards, Vibha === To unsubscribe: mailto [EMAIL PROTECTED] with body: signoff JSP-INTEREST. For digest: mailto [EMAIL PROTECTED] with body: set JSP-INTEREST DIGEST. Some relevant FAQs on JSP/Servlets can be found at: http://archives.java.sun.com/jsp-interest.html http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.jsp http://www.jguru.com/faq/index.jsp http://www.jspinsider.com == = To unsubscribe: mailto [EMAIL PROTECTED] with body: signoff JSP-INTEREST. For digest: mailto [EMAIL PROTECTED] with body: set JSP-INTEREST DIGEST. Some relevant FAQs on JSP/Servlets can be found at: http://archives.java.sun.com/jsp-interest.html http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.jsp http://www.jguru.com/faq/index.jsp http://www.jspinsider.com -- It is the strict policy of Truworths that its e-mail facility and all e-mail communications emanating therefrom, should be utilised for business purposes only and should conform to high professional and business standards. Truworths has stipulated certain regulations in terms whereof strict guidelines relating to the use and content of e-mail communications are laid down. The use of the Truworths e-mail facility is not permitted for the distribution of chain letters or offensive mail of any nature whatsoever. Truworths hereby distances itself from and accepts no liability in respect of the unauthorised use of its e-mail facility or the sending of e-mail communications for other than strictly business purposes. Truworths furthermore disclaims liability for any unauthorised instruction for which permission was not granted.Truworths Limited accepts no liability for any consequences arising from or as a result of reliance on this message unless it is in respect of bona fide Truworths business for which proper authorisation has been granted. Any recipient of an unacceptable communication, a chain letter or offensive material of any nature is requested to notify the Truworths e-mail administrator ([EMAIL PROTECTED]) immediately in order that appropriate action can be taken against the individual concerned. === To unsubscribe: mailto [EMAIL PROTECTED] with body: signoff JSP-INTEREST. For digest: mailto [EMAIL PROTECTED] with body: set JSP-INTEREST DIGEST. Some relevant FAQs on JSP/Servlets can be found at: http://archives.java.sun.com/jsp-interest.html http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.jsp http://www.jguru.com/faq/index.jsp http://www.jspinsider.com
Re: session nonpersistence
Some containers allow you to set specific attributes for the session cookies. You could set a cookie domain of .addr.com so that your session cookie will flow back to any of the host names within a domain. -Original Message- From: Adrian Janssen [mailto:ajanssen;TRUWORTHS.CO.ZA] Sent: Friday, November 01, 2002 3:33 AM To: [EMAIL PROTECTED] Subject: Re: session nonpersistence what if they move your account to a different server causing your urls to change to for e.g. www19.addr.com/~mgarde/somepage.html Now aint that gonna suck? -Original Message- From: Monte Gardner [SMTP:[EMAIL PROTECTED]] Sent: 31 October 2002 03:57 To: [EMAIL PROTECTED] Subject: Re: session nonpersistence I think I may have found the problem. My webserver (I rent space on a commercial webserver) does a strange thing with regards to URL's: when I type in www.addr.com/~mgardne/somepage.html the browser actually gets redirected to www22.addr.com/~mgardne/somepage.html the www gets changed to www22. I think the servlet container was looking at some of my URL's and getting confused as to what was coming from where or something. Anyway, I hard coded some of my url's to absolute urls's with the http://www22.addr.com in them, and my sessions work now. not a pretty fix I know, but atleast I have it working. --Monte Glenn Gardner On Wed, 30 Oct 2002, Monte Gardner wrote: soemoen else mentioned something about this. How do I tell if they are in dfferenet web-apps. all pages are in the same physical directory on the server. --Monte Glenn Gardner On Wed, 30 Oct 2002, Nimmons, Buster wrote: Also, if he jsp pages are in different web apps then each web application gets it's own session object and the objects are not replicated -Original Message- From: Shawn Bayern [mailto:bayern;ESSENTIALLY.NET] Sent: Wednesday, October 30, 2002 9:32 AM To: [EMAIL PROTECTED] Subject: Re: session nonpersistence On Wed, 30 Oct 2002, Monte Gardner wrote: I have a series of JSP pages that begin with a standard userid/password login. The page that receives the login request (shop.jsp) stores the id in the session like this session.setAttribute(id,id); when I print out session.getAttribute(id); on the same page, it prints the id of the user. However, once the user goes to the next page where he views products, and I try to print out the user id with session.getAttribute(id) or request.getSession().getAttribute(id) It prints out null. I have a previous project on the same server in which I did about the same thing, and it seems to work fine so I can't see what I'm doing different between the two. What can cause the session to forget stuff like this? Since HTTP is stateless, something actively needs to preserve the session; for instance, a session identifier can be conveyed by a cookie or as an addendum to the URL. It's possible that your browser isn't sending cookies back to the server; if it's not, and if you're not going out of your way to include the session identifier in links back to your application, then the server has no way of tying your multiple requests together into a session. To ensure you support sessions for browsers that aren't using cookies, make sure to encode the URL into all URLs that the application sends and that also point back to the application. The easiest way to ensure this in a JSP page is by printing all URLs through JSTL's c:url tag. -- Shawn Bayern JSTL in Action http://www.jstlbook.com == = To unsubscribe: mailto [EMAIL PROTECTED] with body: signoff JSP-INTEREST. For digest: mailto [EMAIL PROTECTED] with body: set JSP-INTEREST DIGEST. Some relevant FAQs on JSP/Servlets can be found at: http://archives.java.sun.com/jsp-interest.html http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.jsp http://www.jguru.com/faq/index.jsp http://www.jspinsider.com == = To unsubscribe: mailto [EMAIL PROTECTED] with body: signoff JSP-INTEREST. For digest: mailto [EMAIL PROTECTED] with body: set JSP-INTEREST DIGEST. Some relevant FAQs on JSP/Servlets can be found at: http://archives.java.sun.com/jsp-interest.html http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.jsp http://www.jguru.com/faq/index.jsp http://www.jspinsider.com == = To unsubscribe: mailto [EMAIL PROTECTED] with body: signoff JSP-INTEREST. For digest: mailto [EMAIL PROTECTED] with body: set JSP-INTEREST DIGEST. Some relevant FAQs on JSP/Servlets can be found at:
Re: session nonpersistence
Yea I hear you. I think If I just make sure that the root page is accessed with the proper URL, the rest of the relative URl's will resolve against that one, so maybe I don't have to hard code all of them. I'm still looking at the problem and maybe I'll find a more elegant solution, but the main thing is to get it to work in the enivronment that it is in. --Monte Glenn Gardner On Fri, 1 Nov 2002, Adrian Janssen wrote: what if they move your account to a different server causing your urls to change to for e.g. www19.addr.com/~mgarde/somepage.html Now aint that gonna suck? -Original Message- From: Monte Gardner [SMTP:[EMAIL PROTECTED]] Sent: 31 October 2002 03:57 To: [EMAIL PROTECTED] Subject: Re: session nonpersistence I think I may have found the problem. My webserver (I rent space on a commercial webserver) does a strange thing with regards to URL's: when I type in www.addr.com/~mgardne/somepage.html the browser actually gets redirected to www22.addr.com/~mgardne/somepage.html the www gets changed to www22. I think the servlet container was looking at some of my URL's and getting confused as to what was coming from where or something. Anyway, I hard coded some of my url's to absolute urls's with the http://www22.addr.com in them, and my sessions work now. not a pretty fix I know, but atleast I have it working. --Monte Glenn Gardner On Wed, 30 Oct 2002, Monte Gardner wrote: soemoen else mentioned something about this. How do I tell if they are in dfferenet web-apps. all pages are in the same physical directory on the server. --Monte Glenn Gardner On Wed, 30 Oct 2002, Nimmons, Buster wrote: Also, if he jsp pages are in different web apps then each web application gets it's own session object and the objects are not replicated -Original Message- From: Shawn Bayern [mailto:bayern;ESSENTIALLY.NET] Sent: Wednesday, October 30, 2002 9:32 AM To: [EMAIL PROTECTED] Subject: Re: session nonpersistence On Wed, 30 Oct 2002, Monte Gardner wrote: I have a series of JSP pages that begin with a standard userid/password login. The page that receives the login request (shop.jsp) stores the id in the session like this session.setAttribute(id,id); when I print out session.getAttribute(id); on the same page, it prints the id of the user. However, once the user goes to the next page where he views products, and I try to print out the user id with session.getAttribute(id) or request.getSession().getAttribute(id) It prints out null. I have a previous project on the same server in which I did about the same thing, and it seems to work fine so I can't see what I'm doing different between the two. What can cause the session to forget stuff like this? Since HTTP is stateless, something actively needs to preserve the session; for instance, a session identifier can be conveyed by a cookie or as an addendum to the URL. It's possible that your browser isn't sending cookies back to the server; if it's not, and if you're not going out of your way to include the session identifier in links back to your application, then the server has no way of tying your multiple requests together into a session. To ensure you support sessions for browsers that aren't using cookies, make sure to encode the URL into all URLs that the application sends and that also point back to the application. The easiest way to ensure this in a JSP page is by printing all URLs through JSTL's c:url tag. -- Shawn Bayern JSTL in Action http://www.jstlbook.com == = To unsubscribe: mailto [EMAIL PROTECTED] with body: signoff JSP-INTEREST. For digest: mailto [EMAIL PROTECTED] with body: set JSP-INTEREST DIGEST. Some relevant FAQs on JSP/Servlets can be found at: http://archives.java.sun.com/jsp-interest.html http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.jsp http://www.jguru.com/faq/index.jsp http://www.jspinsider.com == = To unsubscribe: mailto [EMAIL PROTECTED] with body: signoff JSP-INTEREST. For digest: mailto [EMAIL PROTECTED] with body: set JSP-INTEREST DIGEST. Some relevant FAQs on JSP/Servlets can be found at: http://archives.java.sun.com/jsp-interest.html http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.jsp http://www.jguru.com/faq/index.jsp http://www.jspinsider.com == = To unsubscribe: mailto [EMAIL PROTECTED] with body:
Re: [ANN] Part 3 of my JSTL article at ONJava.com
Hans,
Thank you for the long detailed response. It helped confirm my gut
feeling that JSTL will make it easier both for junior and experienced
web developers.
By the way, I believe I found a typo in your article about SQL at
http://www.onjava.com/pub/a/onjava/2002/09/11/jstl2.html?page=3
You use
Config.set(application, Config.SQL_DATASOURCE, ds);
It should be Config.SQL_DATA_SOURCE
Again, thank you for your thoughtful response.
Regards,
Dror
On Thu, Oct 31, 2002 at 12:15:08PM -0800, Hans Bergsten wrote:
Dror Matalon wrote:
Hans,
I just read the article which is very interesting for people that want
to use libraries to develop JSTL style tags.
In reading the article, I realized that I had a nagging question
about JSTL, tag libraries, etc vs JSP.
Before I answer, let's just clarify what JSTL vs JSP means. JSTL is
defined as a tag library that can be implemented (by anyone, but
typically by container implementors) using the standard JSP API for
custom tag libraries. So there's really no JSTL vs JSP; using JSTL
_is_ using JSP, just as using the standard jsp:useBean, scriptlets,
etc. means using JSP.
The only difference between JSTL and any other tag library is that JSTL
is defined by a spec, and therefore more likely to be supported by all
containers (eventually) without having to install it. This also means
that a container vendor can choice to support it by generating highly
optimized code when converting a JSP page to a servlet, e.g. generate
a regular Java if statement instead of calls to the tag handler for
c:if.
With this in mind, I therefore assume that you really wonder about
using custom tag libraries, such as JSTL, vs using Java code in
scriptlets based on your comments below. That's a fair question (even
though it's been asked and answered many times on this list and
elsewhere ;-)
To quote from your article some code:
table
xmp:forEachDay var=curr
c:set var=bg value=white /
xmp:ifSunday
c:set var=bg value=red /
/xmp:ifSunday
tr bgcolor=c:out value=${bg} /
td
fmt:formatDate value=${curr.time}
pattern=EE dd, MMM /
/td
/tr
/xmp:forEachDay
/table
Is JSTL clearly easier than JSP? I'll admit that I'm biased. As
someone who know Java this looks more complicated than doing the
same or similar things with JSP. But rather than use anecdotal
evidence one way or another I'd be intrested in more systematic
research on this.
The best way I can answer this question is to show how this
example can be written with Java code in scriptlets instead:
%
Calendar calendar = new GregorianCalendar();
calendar.set(Calendar.DAY_OF_MONTH, 1);
int lastDay = calendar.getActualMaximum(Calendar.DAY_OF_MONTH);
int thisMonth = calendar.get(Calendar.MONTH);
int currMonth = thisMonth;
int currDay = calendar.get(Calendar.DAY_OF_MONTH);
SimpleDateFormat dateFormat = new SimpleDateFormat(EE dd, MM yyy);
%
table
%
while (currMonth == thisMonth currDay = lastDay) {
String bg = white;
if (calendar.get(Calendar.DAY_OF_WEEK) == Calendar.SUNDAY) {
bg = red;
}
%
tr bgcolor=%= bg %
td
%= dateFormat.format(calendar.getTime()) %
/td
/tr
%
calendar.set(Calendar.DAY_OF_MONTH,
calendar.get(Calendar.DAY_OF_MONTH) + 1);
currMonth = calendar.get(Calendar.MONTH);
currDay = calendar.get(Calendar.DAY_OF_MONTH);
}
%
/table
Which version looks looks easier to you? The, of course, answer
depends on your background. In both versions, it's clearly
programming; the primary difference is syntax, but there are also
a few other important differences:
1) Code size
The scripting version is double the size of the JSTL version
(30 lines vs 14 lines)
2) Knowledge requirements
For the scripting version I need to know about the Calendar and
how to set and get its values, and the SimpleDateFormat class.
For the JSTL version, I need to know about the custom tags,
their attributes, and the properties of the exposed data I can
access using the EL.
3) Syntax error handling
With the scripting version, if I make a syntax error, I get cryptic
javac error messages (e.g. 'catch' without 'try') with line
numbers that refer to the generated servlet source code.
With the JSTL version, I (mostly) get error messages that identify
the custom action and attribute names with line numbers that refer
to the JSP page source.
4) Development tools
If I put the Java code (custom actions, beans) in standard class
files, I can develop the code with a regular Java IDE or syntax
aware text editor (e.g. emacs), and debug it using standard Java
debuggers.
If I
Handling multiple form submits
Hi, I'm working on an ecommerce application based on JSP/EJB. The problem that I have is when the user clicks the checkout button multiple times, multiple requests are sent to the jsp. I'm looking for a solution that is not based on javascript (basically at the client side). Wondering if anyone has any thoughts on this. Thanks Priscilla === To unsubscribe: mailto [EMAIL PROTECTED] with body: signoff JSP-INTEREST. For digest: mailto [EMAIL PROTECTED] with body: set JSP-INTEREST DIGEST. Some relevant FAQs on JSP/Servlets can be found at: http://archives.java.sun.com/jsp-interest.html http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.jsp http://www.jguru.com/faq/index.jsp http://www.jspinsider.com
Re: Handling multiple form submits
hi, If you don't want the request submitted a second time at all, you will have to use javascript. Otherwise, there is something called sensitive form resubmits and a relatively standard way of handling the situation. You can find some info about it here: http://www.kobrix.com/view_contribution.jsp?cid=7 This is in the context of our own product, but the general solution is described as well. Best, Boris Borislav Iordanov Chief Architect TICL - a RAD toolkit for server-side Java http://www.kobrix.com -Original Message- From: A mailing list about Java Server Pages specification and reference [mailto:JSP-INTEREST;JAVA.SUN.COM] On Behalf Of priscilla augustin Sent: Friday, November 01, 2002 2:29 PM To: [EMAIL PROTECTED] Subject: Handling multiple form submits Hi, I'm working on an ecommerce application based on JSP/EJB. The problem that I have is when the user clicks the checkout button multiple times, multiple requests are sent to the jsp. I'm looking for a solution that is not based on javascript (basically at the client side). Wondering if anyone has any thoughts on this. Thanks Priscilla == = To unsubscribe: mailto [EMAIL PROTECTED] with body: signoff JSP-INTEREST. For digest: mailto [EMAIL PROTECTED] with body: set JSP-INTEREST DIGEST. Some relevant FAQs on JSP/Servlets can be found at: http://archives.java.sun.com/jsp-interest.html http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.jsp http://www.jguru.com/faq/index.jsp http://www.jspinsider.com === To unsubscribe: mailto [EMAIL PROTECTED] with body: signoff JSP-INTEREST. For digest: mailto [EMAIL PROTECTED] with body: set JSP-INTEREST DIGEST. Some relevant FAQs on JSP/Servlets can be found at: http://archives.java.sun.com/jsp-interest.html http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.jsp http://www.jguru.com/faq/index.jsp http://www.jspinsider.com
Re: Handling multiple form submits
Have a session bean that handles the checkout. If you synchronize the method the user called, only the first call will go through while the others wait. When the method is called by second one you can check to see if they've already checked out. You have to make sure to get synchronization on the client base, not application or request. - Original Message - From: priscilla augustin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, November 01, 2002 2:29 PM Subject: Handling multiple form submits Hi, I'm working on an ecommerce application based on JSP/EJB. The problem that I have is when the user clicks the checkout button multiple times, multiple requests are sent to the jsp. I'm looking for a solution that is not based on javascript (basically at the client side). Wondering if anyone has any thoughts on this. Thanks Priscilla === To unsubscribe: mailto [EMAIL PROTECTED] with body: signoff JSP-INTEREST. For digest: mailto [EMAIL PROTECTED] with body: set JSP-INTEREST DIGEST. Some relevant FAQs on JSP/Servlets can be found at: http://archives.java.sun.com/jsp-interest.html http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.jsp http://www.jguru.com/faq/index.jsp http://www.jspinsider.com === To unsubscribe: mailto [EMAIL PROTECTED] with body: signoff JSP-INTEREST. For digest: mailto [EMAIL PROTECTED] with body: set JSP-INTEREST DIGEST. Some relevant FAQs on JSP/Servlets can be found at: http://archives.java.sun.com/jsp-interest.html http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.jsp http://www.jguru.com/faq/index.jsp http://www.jspinsider.com
Re: [ANN] Part 3 of my JSTL article at ONJava.com
Dror Matalon wrote: Hans, Thank you for the long detailed response. It helped confirm my gut feeling that JSTL will make it easier both for junior and experienced web developers. Great. By the way, I believe I found a typo in your article about SQL at http://www.onjava.com/pub/a/onjava/2002/09/11/jstl2.html?page=3 You use Config.set(application, Config.SQL_DATASOURCE, ds); It should be Config.SQL_DATA_SOURCE Ah, yeah, you're right. I'll try to get that fixed. Again, thank you for your thoughtful response. You're welcome. Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com JavaServer Pageshttp://TheJSPBook.com === To unsubscribe: mailto [EMAIL PROTECTED] with body: signoff JSP-INTEREST. For digest: mailto [EMAIL PROTECTED] with body: set JSP-INTEREST DIGEST. Some relevant FAQs on JSP/Servlets can be found at: http://archives.java.sun.com/jsp-interest.html http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.jsp http://www.jguru.com/faq/index.jsp http://www.jspinsider.com
Re: Handling multiple form submits
I don't know if this is any better then javaScript, but you could write a small applet with a button which disables itself after the first click. -- just a thought --Monte Glenn Gardner On Fri, 1 Nov 2002, priscilla augustin wrote: Hi, I'm working on an ecommerce application based on JSP/EJB. The problem that I have is when the user clicks the checkout button multiple times, multiple requests are sent to the jsp. I'm looking for a solution that is not based on javascript (basically at the client side). Wondering if anyone has any thoughts on this. Thanks Priscilla === To unsubscribe: mailto [EMAIL PROTECTED] with body: signoff JSP-INTEREST. For digest: mailto [EMAIL PROTECTED] with body: set JSP-INTEREST DIGEST. Some relevant FAQs on JSP/Servlets can be found at: http://archives.java.sun.com/jsp-interest.html http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.jsp http://www.jguru.com/faq/index.jsp http://www.jspinsider.com === To unsubscribe: mailto [EMAIL PROTECTED] with body: signoff JSP-INTEREST. For digest: mailto [EMAIL PROTECTED] with body: set JSP-INTEREST DIGEST. Some relevant FAQs on JSP/Servlets can be found at: http://archives.java.sun.com/jsp-interest.html http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.jsp http://www.jguru.com/faq/index.jsp http://www.jspinsider.com
Re: Handling multiple form submits
Ok, having a flag set in the session and checking it before a checkout will get me out of doing the checkout more than once. But the problem I face here is, when the browser sends multiple requests, it always waits for the response from the last request. But in my case, the first request will do the checkout. Do I have to keep track of all the threads associated with the requests, and once the flag is reset by the first request, get the thread associated with the last request and redirect to the thankyou page? Thanks Priscilla -Original Message- From: Borislav Iordanov [mailto:borislav;KOBRIX.COM] Sent: Friday, November 01, 2002 11:50 AM To: [EMAIL PROTECTED] Subject: Re: Handling multiple form submits hi, If you don't want the request submitted a second time at all, you will have to use javascript. Otherwise, there is something called sensitive form resubmits and a relatively standard way of handling the situation. You can find some info about it here: http://www.kobrix.com/view_contribution.jsp?cid=7 This is in the context of our own product, but the general solution is described as well. Best, Boris Borislav Iordanov Chief Architect TICL - a RAD toolkit for server-side Java http://www.kobrix.com -Original Message- From: A mailing list about Java Server Pages specification and reference [mailto:JSP-INTEREST;JAVA.SUN.COM] On Behalf Of priscilla augustin Sent: Friday, November 01, 2002 2:29 PM To: [EMAIL PROTECTED] Subject: Handling multiple form submits Hi, I'm working on an ecommerce application based on JSP/EJB. The problem that I have is when the user clicks the checkout button multiple times, multiple requests are sent to the jsp. I'm looking for a solution that is not based on javascript (basically at the client side). Wondering if anyone has any thoughts on this. Thanks Priscilla == = To unsubscribe: mailto [EMAIL PROTECTED] with body: signoff JSP-INTEREST. For digest: mailto [EMAIL PROTECTED] with body: set JSP-INTEREST DIGEST. Some relevant FAQs on JSP/Servlets can be found at: http://archives.java.sun.com/jsp-interest.html http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.jsp http://www.jguru.com/faq/index.jsp http://www.jspinsider.com === To unsubscribe: mailto [EMAIL PROTECTED] with body: signoff JSP-INTEREST. For digest: mailto [EMAIL PROTECTED] with body: set JSP-INTEREST DIGEST. Some relevant FAQs on JSP/Servlets can be found at: http://archives.java.sun.com/jsp-interest.html http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.jsp http://www.jguru.com/faq/index.jsp http://www.jspinsider.com === To unsubscribe: mailto [EMAIL PROTECTED] with body: signoff JSP-INTEREST. For digest: mailto [EMAIL PROTECTED] with body: set JSP-INTEREST DIGEST. Some relevant FAQs on JSP/Servlets can be found at: http://archives.java.sun.com/jsp-interest.html http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.jsp http://www.jguru.com/faq/index.jsp http://www.jspinsider.com
Re: Handling multiple form submits
When you check that they've already checked out, just send them to the thank-you page. - Original Message - From: Augustin, Priscilla [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, November 01, 2002 3:11 PM Subject: Re: Handling multiple form submits Ok, having a flag set in the session and checking it before a checkout will get me out of doing the checkout more than once. But the problem I face here is, when the browser sends multiple requests, it always waits for the response from the last request. But in my case, the first request will do the checkout. Do I have to keep track of all the threads associated with the requests, and once the flag is reset by the first request, get the thread associated with the last request and redirect to the thankyou page? Thanks Priscilla -Original Message- From: Borislav Iordanov [mailto:borislav;KOBRIX.COM] Sent: Friday, November 01, 2002 11:50 AM To: [EMAIL PROTECTED] Subject: Re: Handling multiple form submits hi, If you don't want the request submitted a second time at all, you will have to use javascript. Otherwise, there is something called sensitive form resubmits and a relatively standard way of handling the situation. You can find some info about it here: http://www.kobrix.com/view_contribution.jsp?cid=7 This is in the context of our own product, but the general solution is described as well. Best, Boris Borislav Iordanov Chief Architect TICL - a RAD toolkit for server-side Java http://www.kobrix.com -Original Message- From: A mailing list about Java Server Pages specification and reference [mailto:JSP-INTEREST;JAVA.SUN.COM] On Behalf Of priscilla augustin Sent: Friday, November 01, 2002 2:29 PM To: [EMAIL PROTECTED] Subject: Handling multiple form submits Hi, I'm working on an ecommerce application based on JSP/EJB. The problem that I have is when the user clicks the checkout button multiple times, multiple requests are sent to the jsp. I'm looking for a solution that is not based on javascript (basically at the client side). Wondering if anyone has any thoughts on this. Thanks Priscilla == = To unsubscribe: mailto [EMAIL PROTECTED] with body: signoff JSP-INTEREST. For digest: mailto [EMAIL PROTECTED] with body: set JSP-INTEREST DIGEST. Some relevant FAQs on JSP/Servlets can be found at: http://archives.java.sun.com/jsp-interest.html http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.jsp http://www.jguru.com/faq/index.jsp http://www.jspinsider.com === To unsubscribe: mailto [EMAIL PROTECTED] with body: signoff JSP-INTEREST. For digest: mailto [EMAIL PROTECTED] with body: set JSP-INTEREST DIGEST. Some relevant FAQs on JSP/Servlets can be found at: http://archives.java.sun.com/jsp-interest.html http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.jsp http://www.jguru.com/faq/index.jsp http://www.jspinsider.com === To unsubscribe: mailto [EMAIL PROTECTED] with body: signoff JSP-INTEREST. For digest: mailto [EMAIL PROTECTED] with body: set JSP-INTEREST DIGEST. Some relevant FAQs on JSP/Servlets can be found at: http://archives.java.sun.com/jsp-interest.html http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.jsp http://www.jguru.com/faq/index.jsp http://www.jspinsider.com === To unsubscribe: mailto [EMAIL PROTECTED] with body: signoff JSP-INTEREST. For digest: mailto [EMAIL PROTECTED] with body: set JSP-INTEREST DIGEST. Some relevant FAQs on JSP/Servlets can be found at: http://archives.java.sun.com/jsp-interest.html http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.jsp http://www.jguru.com/faq/index.jsp http://www.jspinsider.com
