I dont really see why you wouldnt use your a) solution since its technically not
part of the "presentation" @ all. The value you are returning is simply a
different type and inside a page you could call on both:
<%= customer.getName() %>
<%= customer.getParsedName() %>
I personally find more value sticking util directives and methods inside the beans
themselves so that they are always there to reduce later work. (Your c option is
definetley an overhaul).
Just my opinion.
- Jon
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.
>
> 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 '<'
> 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 & < goes to <) - 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.
>
> Looking forward to hearing some ideas...
>
> --
> Tim Fox (��o)
>
> Senior developer
> Hyperlink plc
> http://hyperlink.com
>
> email: [EMAIL PROTECTED]
> phone: +44 (0) 207 240 8121
>
> ===========================================================================
> 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
