yes, yes Craig ! That is exactly what we are doing
(or trying to do :-) What we need from servers dynamic
(in my opinion of course) is just ability to load
classes/run methods. The product we are using (alaJSP)
is all about that.
But in my opinion this approach is hided by JSP specs/documents
contains a lot of stuff that really belongs to servlets.
Looks like JSP trying to have all relevant stuff from ASP
world but do you really need that ? It is a nightmare to
support big ASP projects. And for example what are you doing
with taglibs ? How these elements can be placed in your
model splited html/java ? And lacking of that explanation is
a reason of question we are talking about.
And your as well very strong explanation (used much more clear
English then my :-) as seems to me shows the real way to use JSP.
---------------------------------------------
"Craig McClanahan" <[EMAIL PROTECTED]> wrote:
Dmitri Namiot wrote:
> looks like very logical and clear model, but see:
> you submit your forms to servelt. (I also like
> one servlet per application, just more easy to
> maintain). So your logic (application logic) is
> supported by servlet. What in that case the added
> value from JSP-beans to web-application ?
> Yes, we have some business rules implementation,
> localized within some java classes. But we can use these
> classes from servlet. I am feeling myself some trouble
> to split beans/servlets during own "jsp-projects" for the
> clients. Looks like in the most cases it is still "servlet-
> projects" because any attempt to add some dynamic/behavior
> to your JSP pages directly means java-coding within the page
> what is not a good.
>
Let's review the MVC roles of the various components for a moment:
* Servlet == Controller. It decides which business logic
method to call, and then calls it.
* Beans == Model. The business logic does something,
and usually creates results that need to be displayed or
saved for later use.
* JSP Page == View. It displays the results.
To make this concrete, let's assume a very simple form that let's you ask for
a particular
customer to be displayed:
<form method="post" action="/myservlet/displayCustomer">
Account Number:
<input type="text" name="account">
<input type="submit">
</form>
The servlet that receives this would look at the "/displayCustomer" part of
the URI (this is
not the only way to do it, but it's easy) and calls a business method to
perform the lookup.
The business logic extracts the account number, and uses it to perform a JDBC
lookup of a row
in the CUSTOMERS table.
Now, the question becomes, "how do I transfer the column values for this
customer to the JSP
page for display?" A really simple way is to create a CustomerBean that
represents this
customer, with properties for each column you care about. Say, ...
CustomerBean cb = new CustomerBean();
cb.setName(resultset.getString("name"));
cb.setAddress(resultset.getAddress("address"));
// and so on
To transfer the bean to the JSP page, you need to pass it somehow. There's
three choices --
with the request, in the session, or in the servlet context. Because we only
need this
customer for long enough to display it, the request is the right way. Let's
store this bean,
and then forward control to the correct JSP page for displaying the result.
request.setAttribute("customerBean", cb);
RequestDispatcher rd =
getServletContext().getRequestDispatcher("/displayCustomer.jsp");
rd.forward(request, response);
In the "/displayCustomer.jsp" JSP page, you can now refer to the bean that was
passed just
like any other bean:
<jsp:useBean id="customerBean" scope="request"
type="CustomerBean" />
Customer Name: <%= customerBean.getName() %>
Customer Address: <%= customerBean.getAddress() %>
No Java logic in the JSP page is required except the scriptlet fragments to
get the property
values.
So, we used a bean to represent (or "model") data that was in the database.
We created the
bean in the servlet, and passed it to the JSP page. After the page is done,
the bean is
thrown away (because we passed it as a request attribute). You'd use one of
the other scopes
for things that needed to last longer than the current request.
Why go to all the extra work? Well, consider the impact of a couple possible
changes that
might happen to your application later:
* You might go back and change the look and feel of the
customer display page. You can do this with no impact
on the servlet or the business logic.
* You might change the database from which you read
customer information -- perhaps you now have to join
two different tables to create a customer bean. You can
do this by modifying only the business logic -- the JSP
page doesn't care at all how the customer bean got
created; all it needs to know is that the business logic
left it there.
Craig McClanahan
ColdJava: java server side programming
http://coldjava.hypermart.net
____________________________________________________________________
Get your own FREE, personal Netscape WebMail account today at
http://webmail.netscape.com.
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
