Instead of using a utility method I would use delegation of the JSPWriter to write
the output in the JSP page. That way a developer doesn't add new code and "forget"
to call the utility method on the output text. For example You can create a class
as follows:
public class SafeHtmlWriter extends Writer
{
public SafeHtmlWriter(Writer delegate) { m_delegate = delegate; }
public void write(char cbuf[], int off, int len) throws IOException
{
// Convert any '<' characters in the array to '<'
String res = "";
for(int i = off; i<off+len; i++)
{
if (cbuf[i] == '<')
res += "<";
else if (cbuf[i] == '&')
res == "&";
else
res += cbuf[i];
}
char newbytes[] = res.toCharArray();
m_delegate.write(newbytes, 0, newbytes.length);
}
public void flush() throws IOException { m_delegate.flush(); }
public void close() throws IOException { m_delegate.close(); }
private Writer m_delegate;
}
The SafeHtmlWriter class delegates most of its work to the delegate Writer class but
when write() method is called it converts the characters before calling the
delegate.
In your JSP page you can wrap the JSPWriter class with this SafeHtmlWriter class and
assign the SafeHtmlWriter class to the out variable. Then whenever you do something
like:
<%= .... %>
It will use SafeHtmlWriter instead of JSPWriter.
I haven't actually tried this in JSP, only in Servlets, but I am pretty sure it will
work.
--Chris Colebourn
Senior Software Engineer
eBussiness Technologies
[EMAIL PROTECTED]
ismaelb wrote:
> interesting point mate.
> We're also developing a website using the model 2 architecture and we've
> encountered similar design
> issues. The method we used was a custom tag/action which converted text into its
> its ansi equivalent.
> Great point though...you should post more often.
>
> 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
===========================================================================
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
