I would say, yes, you are wrong in this case.
You would use a JavaBean from the getgo. Lets do a simple example. A name
field..just one field. You would have a JavaBean like so:
public class NameBean
{
private String name = "";
public String getName()
{
return name;
}
public void setName(String value)
{
name = value;
}
}
Now, from the very beginning, your JSP page uses this bean to display the
beans results. Since the very first use, the bean is EMPTY, you will see
empty fields:
<jsp:useBean id="NameBean" scope="request" class="mypackage.NameBean" />
<html><head><title></title></head>
<body>
<form action="/servlet/ControllerServlet" method="post">
<b>Enter your name:</b> <input type="text" name="Name" value="<%=
NameBean.getName() %>">
<input type="submit" name="submit" value="submit">
</form>
</body>
</html>
Now, in the simple example, your controller servlet discovers a problem. It
would simply populate the NameBean with the NAME sent to it in the form in
the first place. So..it might look something like this:
public void doPost(...)
{
// get parameter
String name = request.getParamter("Name");
// do some logic...
// an error occurs..forward back to name page.
// place name in bean and forward
NameBean bean = new NameBean();
bean.setName( name );
request.setAttribute("NameBean", bean);
RequestDispatcher rd = getContext().getRequestDispatcher("/name.jsp");
rd.forward(request,response);
}
So..I left out some code above..but you get the idea hopefully. Your
controller servlet, whether it uses the Action class system like Craig,
Daniel and I have been talking about, or sub-servlets that derive..however
you do it, it would be up to you to populate the bean again, and forward
BACK to the original page, instead of going on to say a "thank you" page or
something.
In my pages, I include a header.inc, which is an include file full of html
and some scriplet code for conditional display logic. Its my understanding
that it is perfectly fine to use scriplets for display logic.
So, I might have something like this:
<%
if( request.getAttribute("EXCEPTION") != null )
{
%>
<%= request.getAttribute("EXCEPTION") %>
<%
}
%>
The reason is, in my controller servlet, I set any exceptions that occur
during the servlet into the request as an attribute (sorry..I decided to use
a "non" standard approach since my application is specific to one use in our
company) so that the header.inc file can check for an exception and display
the message it returns. Ofcourse, its up to each THROW clause to make sure
they put an english sentence in there..and not allow the more cryptic java
error messages to be displayed.
Anyways..this is but one way to do it. I am sure there are many more.
Hope that helps.
> -----Original Message-----
> From: A mailing list about Java Server Pages specification and reference
> [mailto:[EMAIL PROTECTED]]On Behalf Of blbol aimn ; bse meng
> Sent: Tuesday, March 28, 2000 7:05 AM
> To: [EMAIL PROTECTED]
> Subject: Model 2 and form validation
>
>
> Hi to all of you
>
> I might be wrong about what I want to say so please correct me:
>
> It seems to me that it is not appropriate to use model 2 when you have
> form
> validation and there is a need to examine user data at the server as in
> the case of looking up a database. The reason is if the user entered an
> email address that already exists in the database, then you want to bring
> register.jsp form back to the user along with his error and all info
> he/she entered previously such as his name and address. Now someone might
> say that you can pass these old info back to register.jsp from a
> controller servlet in the form of hidden variables. If you do that, then
> register.jsp does not look a view any more as it has to get all these
> hidden variables and put them in the register.jsp form.
>
> What do you guys think?
>
> Thanks.
>
> ==================================================================
> =========
> To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
> JSP-INTEREST".
> Some relevant FAQs on JSP/Servlets can be found at:
>
> http://java.sun.com/products/jsp/faq.html
> http://www.esperanto.org.nz/jsp/jspfaq.html
> http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
> http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
>
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
