Tim Fox wrote:

> We're developing a site using the now familiar 'model 2' architecture.
>
> Ie we have a controller servlet through which all requests are routed,
> and then, depending on the action requested a "web action" classes is
> instantiated and a method is called on it.
>
> This, in turn instantiates any business objects (these would be ejb's if
> we were using ejb), performing any business operations and returning
> results.
>
> Currently at this stage we initialise "result beans" with the results of
> the business operations and put them in request scope, then forward to
> the jsp page which retrieves the beans, extracts the data from them,
> formats it on the page (with custom tags), thus producing the page for
> the user.
>
> My dilemma is whether to use the results beans or not - why don't I just
> put the business objects directly into the request object while in the
> web-action, and let the jsp page extract the data (by calling the
> accessor methods etc.) directly from them?
>
> In many ways this would make the architecture simpler and we're still
> not "mixing roles" since the business object knows nothing of the jsp
> page.
>

That is true ... but what about the other way?  Aren't you making your JSP page
understand the internal structure of your business objects?

For many people this will not be a problem -- presentation is quite often
intimately linked with the available properties of the underlying business
objects.  It's also true that business objects in many environments tend to change
more slowly than presentation (and the most common change is just adding fields).
Major changes in the underlying business model can (at least theoretically) be
hidden if you are using result beans, but this may not be an issue for you.

I would not see a problem using the business objects as results if you are aware
that you are creating this linkage, and it won't cause you a problem later.


>
> The main reason why we haven't always done it this way is due to the
> parsing of html "strange characters" - an explanation is in order:
>
> Say I have a page which displays a customer name. Now if by chance (yes
> - it's very unlikely but we have to cater for the possibility) the
> customer's name is 'John <' - the jsp page extracts the name directly
> from the business object and displays it on the page. What we actually
> see on the page is 'John <' - since the character sequence '&lt;'
> represents < in html.
>
> Another example would be if the customer's name was '<script
> language='JavaScript'>alert('I am a trojan horse');</script>'-  you can
> see what would happen when the page is returned to the user!
>
> So... most strings that we display on jsp pages have to first be put
> through a method which converts all these 'strange characters' to their
> html escape sequences (& goes to &amp; < goes to &lt;) - the method is
> just a big case statement.
>
> The question is: Where do I call this method? Do I:
>
> a) Put it in the business object? I'd rather not since that's mixing
> presentation with business logic
> eg
> public class Customer
> {
> ...
> public String getName() {return _name; }
> public String getParsedName() { return Utils.parseString(_name;)}
> ...
> }
>
> b) Use result beans?
> public class TextBean
> {
>     private String _text = "";
>     public TextBean(String text)
>     {
>         _text = text;
>     }
>     public String getText() { return _text; }
>     public String getParsedText() { return Utils.parseString(_text);}
> ...
> }
> The advantage of this approach is that it nicely separates the business
> and presenttion logic.
> But it involves much more code and an extra logical 'layer' which we are
> only using for parsing these html characters - it seems a waste to me -
> an extra tier purely due to a side effect of html.
>
> c) Do the parsing in the page?
>
> <jsp:useBean id='customer' class='...' />
> <h1>Here is the customer</h1>
> <%=Utils.parseString(customer.getName()); %>
>
> This removes the overhead of having an extra result-bean layer but means
> I have to put calls to Utils.parseString everywhere I use data from a
> business object -this messes up my pages.
>
> I'd be interested to know any 'best practice' on the above dilemma,
> since I guess it's something any serious web developer must have come up
> against at some time - having said that in practically every jsp example
> I've seen, the page uses the business object directly - which doesn't
> seem to be a solution to me.
>

One additional option to consider -- if your business rules say that (for example)
it is not valid to have an HTML tag in a customer name field, you could trap it at
input time (usually only needed in one place), rather than output time (customer
name fields tend to get used in lots of places, and it's easy to forget your
filtering in one or two of them).

To do this, my approach would be to have the setName() method throw an
IllegalArgumentException, or to have your validate() method return an error message
talking about this -- depending on how you are doing your input validations.

This is just the old "garbage in garbage out" cliche -- if I can prevent garbage
from getting inside in the first place, I have to worry less about spewing it back
out again :-).

>
> Looking forward to hearing some ideas...
>
> --
> Tim Fox (¦¬o)
>

Craig McClanahan

===========================================================================
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

Reply via email to