DTO, DAO - Displaying/Formatting Data in the Presentation Layer
I need display multiple fields from a DTO throughout the presentation layer. What is the best way to format display data without duplicating the logic throughout presentation layer?
Example
I have a Person DTO that has first name, last name, and suffix 'getters' and am constantly showing the data out as "first last, suffix"
Options
1 - Create a utility class that formats the name of the Person DTO.
publicclass DisplayUtil{
publicstatic String DisplayName(PersonDTO person){
return person.getFirstName() +" " + person.getLastName() +", " + person.getSuffix();
}
}
2 - Add a getter into the DTO that gets the data
publicclass PersonDto{
//Other fields, getters, and setters
public String getName(){
return person.getFirstName() +" " + person.getLastName() +", " + person.getSuffix();
}
}
3 - Create a domain object (aka business object) using the "entity inherits from transfer object strategy".
publicclass Personextends PersonDto{
public String getName(){
return person.getFirstName() +" " + person.getLastName() +", " + person.getSuffix();
}
}
The easiest to implement now would be Option 2 above but it distorts what the DTO is supposed to be used for (which is transferring data).
What have you done in the past? What is an "acceptable" best practice? Are there other options that I haven't listed above that you use?
[2461 byte] By [
jaredpa] at [2007-11-27 4:19:34]
# 1
Option 3 is the preferred way.1 is too loose and 2 discomforts the DTO pattern.
# 2
> I need display multiple fields from a DTO throughout
> the presentation layer. What is the best way to
> format display data without duplicating the logic
> throughout presentation layer?
The best way to format display data on the Presentaion tier depends almost entirely upon the presentation requirements of the application and the technologies chosen for implementation.
One way to display data on a cell phone or PDA browser might be different than another way to display data in an HTML web browser.
Or, the Presentation tier might be implemented with a Swing GUI.
One thing about the Data Transfer Object design pattern. The DTO is only used to "transfer" data. It is not supposed to be used to actually display data. The technology on the Presentation tier is responsible for actually displaying ("presenting") the data that it receives from a DTO.
None of the options specified are the best way, or even good ways. The best way to implement a Data Transfer Object is using the JavaBeans format.
public class Person {
private String firstName;
private String lastName;
private String suffixName;
public String getFirstName() {
}
public void setFirstName(String _x) {
}
...
}
The objects on the Presentation tier will then be responsible for "presenting" data in the correct format.
By designing this way, you maintain the most flexibility.
My personal best is to use the business object also as a transfer object and design a Struts ActionForm class to present the data in a web browser.
# 3
The DTO for my example would reflect exactly what you have specified and could use a Struts Action as the controller piece.
So, from what you advise you would have the following code in <b>all</b> of the JSP pages of the Struts app?
<c:out value="${person.firstName} ${person.lastName}" />
<c:logic test="${not empty person.suffix}">
<c:out value=", ${person.suffix}" />
</c:logic>
The problem that I see with this is that changes would be incredibly difficult at a later date, since every page contains the logic about displaying the proper name format. (Say the client wanted to change to always display the last name first instead of the first name for all the pages. With this logic code being on every "template", their could be hundreds of pages to change. This is where I could see the benefit of a utility class like Option 1.)
# 4
[nobr]> So, from what you advise you would have the following
> code in <b>all</b> of the JSP pages of the Struts
> app?
> > <c:out value="${person.firstName} ${person.lastName}"
> />
> <c:logic test="${not empty person.suffix}">
> <c:out value=", ${person.suffix}" />
> </c:logic>
>
>
> The problem that I see with this is that changes
> would be incredibly difficult at a later date, since
> every page contains the logic about displaying the
> proper name format. (Say the client wanted to change
> to always display the last name first instead of the
> first name for all the pages. With this logic code
> being on every "template", their could be hundreds of
> pages to change. This is where I could see the
> benefit of a utility class like Option 1.)
This is what the include directive is for. The JSP tags in your example should not exist (physically ) in each JSP file. They should be stored in a single JSP fragment file.
The JSP fragment file is then "included" in each page via include directive. If you need to change anything for this at a later date, then you go to the single fragment file and make the change once.
<html>
<head><title>Including Shared Stuff in JSP Pages</title></head>
<body>
<%@include file="shared/text.jspf" %><br/>
<font size="10">What It Do</font><br/>
<jsp:include page="shared/text.jspf" />
</body>
</html>
When each JSP file is converted to a Java servlet by the JSP Engine, it will grab the shared fragment and include it in the code for the servlet.[/nobr]
# 5
I think you missed the point of the example...
I'm not talking about standard header, footers, and page fragments, I'm talking about the data displayed on specific pages.
Say for example my Person object was part of a larger payroll program. There could be an invoice page, a receipt page, a confirmation of payment page, a user information page, and the list goes on.
The confirmation page could have:
--
Thanks for purchasing blah blah blah from me. Your order information is below.
Name: {First Last, Suffix}
Items: {Quantity} x {Item Name}
--
Then a seperate invoice page could have:
--
These were the following orders on Monday:
//Show table of names with invoice numbers
Name: {First Last, Suffix}
Invoice: {Invoice Number}
--
Then on another page - like say customer information page
--
Name: {First Last, Suffix}
Address: {Address}
--
What you're saying is to have a standard include? How would that work with 3 example pages above? All three examples above present different views of the same data. This would mean that one included page couldn't possible work (unless you had a page fragment for just the name and that would be ridiculous).
To rephrase my original inquiry, I'm looking for a way my presentation layer can display multiple PersonDTO fields in a specific format, which can be easily changed at a later date.
# 6
> What you're saying is to have a standard
include? How would that work with 3 example
pages above? All three examples above present
different views of the same data. This would mean
that one included page couldn't possible work (unless you had a page fragment for just the name and that would be ridiculous).
Why do you think a page fragment for just the JSP tags used to display the name is ridiculous? Wouldn't it be better to have this shared bit in one place rather that in hundreds of places?
Creating mmore code for the sake of creating more code just to create more code is poor design.
Your original inquiry is based on a flawed design. I presented a more efficient way to handle the issue of sharing common data amongst multiple servlets (in the form of JSP pages).
You decide how you want to do it :o)
I have created fragment files for a single copyright statement inside a
tag. And the fragement is used by thousands of JSP pages. To change the copyright year, I go to the one file and make a single change.
# 7
Why do you think a page fragment for just the JSP tags used to display the name is ridiculous? Wouldn't it be better to have this shared bit in one place rather that in hundreds of places?
Creating mmore code for the sake of creating more code just to create more code is poor design. Your original inquiry is based on a flawed design. I presented a more efficient way to handle the issue of sharing common data amongst multiple servlets (in the form of JSP pages).
You decide how you want to do it :o)
I have created fragment files for a single copyright statement inside a p
tag.
And the fragment is used by thousands of JSP pages. To change the copyright year, I go to the one file and make a single change.
# 8
> I'm not talking about standard header, footers, and
> page fragments, I'm talking about the data displayed
> on specific pages.
The text in the header, footer and "page fragments" are data displayed on specific pages. This is common data that is shared on multiple specific pages.
The data for the person is also data that is displayed on specific pages.
The specific pages that do not display the person data do not have an include directive for the fragment. Simple.
The pages that do display the person data do have the directive. Again, simple.
A utility class created to display data from a data transfer object seems like a poor design. Just my simple opinion. Coming up with small simple solutions for small details like displaying data from a transfer object free up your mind to handle bigger, more complex things.
Good luck!
# 9
so for the three page examples that I posted before you are saying:
1) Create a new page for the name formatting
Name.jspf
--
<c:out value="${person.firstName} ${person.lastName}" />
<c:logic test="${not empty person.suffix}">
<c:out value=", ${person.suffix}" />
</c:logic>
--
2) Include that page for name formatting in the pages that use it
Confirmation page
--
Thanks for purchasing blah blah blah from me. Your order information is below.
Name: <jsp:include page="Name.jspf" />
Items: {Quantity} x {Item Name}
--
Invoice page
--
These were the following orders on Monday:
//Show table of names with invoice numbers
Name: <jsp:include page="Name.jspf" />
Invoice: {Invoice Number}
--
Customer information page
--
Name: <jsp:include page="Name.jspf" />
Address: {Address}
--
This just seems odd to me. Coming from a .NET background, there are specific facilities to provide custom formatting for displaying data.
http://www.codeproject.com/csharp/custstrformat.asp
It just seems like string formatting for custom objects (in my case, PersonDTO) should have been implemented by now in the Presentation/JSP/JSF.
Thanks GhostRadioTwo for sharing your knowledge and insight.
# 10
Like I mentioned earlier, there are many ways to handle displaying data. And there are many implementation possibilities for the Presentation tier.
I'm sure that a "presentation" programmer or developer could come up with a different design, possibly using JSF.
My personal experience is on designing architecture and the Business/Integration tiers.
From a time and maintainability perspective, creating a specific class to derived data from a transfer object is not required.
There are no size limitations on what can be a fragment. The compiler does not care whether there are 100 bytes or 1000 bytes. When the JSP engine compiles the JSP page it stores all the code in one place anyway.
1. Create a fragment file: name.jspf
2. Put fragment file in a shared directory, e.g. shared
3. Include that fragment for name formating in the pages that use it.
Thanks for purchasing. Your order confirmation is below:
<bean:message key="label.name"/><%@include file="shared/name.jspf" %>
Aside, the message element of the bean tag library works in the same fashion. Labels and shared text goes into the application.resources file. Page designers then use the bean tag library to include references to the shared data.
The include directive is a specific facility for sharing data on multiple JSP pages.
There are specific facilities for custom formatting for displaying data. (See Struts Layout tag library for more info.)
Also read up on the Java Server Faces framework for more "presentation" strategies.
# 11
> There are no size limitations on what can be a
> fragment. The compiler does not care whether there
> are 100 bytes or 1000 bytes. When the JSP engine
> compiles the JSP page it stores all the code in one
> place anyway.
As a distantly related note keep in mind that there are in fact limits on java code. At least in the past (perhaps with JSP, perhaps something else) the construction process would end up creating a single method. And that would eventually reach a limit.
# 12
Java code doesn't work without a CPU either :o)
# 13
> Java code doesn't work without a CPU either :o)Yes, but I haven't seen anyone here complaining about that.I have seen people here complaining when their JSP code (via the auto contruction process) reached the byte code method limit.
# 14
> I have seen people here complaining when their JSP
> code (via the auto contruction process) reached the
> byte code method limit.
Interesting. In regards to this post and what we are writing about, this is not an issue. The fragment for the JSP elements for displaying a name would hardly threaten that byte code limit.
Byte code method limit.
No JSP page designer should ever even come close to reaching this limit, in my opinion.
Trying to cram way too much text information on a page. Or, maybe graphics have not been optimized for web delivery. Or, too many graphics.
In real world application, it is hard for me to imagine that the byte code method limit is something to worry about when creating fragement files or writing single-file JSP pages.
In regards to theory and forum-speak, yes, you made a good point for readers that like to take single sentences and isolate them from the context and the meaning of the sentences around them.
My comment literally, about JSP pages having no size limitations is then incorrect.
My suggestion to solve the issue of sharing data amongst multiple JSP pages using the include directive is still valid, in my opinion.
/>
# 15
>
> In real world application, it is hard for me to
> imagine that the byte code method limit is something
> to worry about when creating fragement files or
> writing single-file JSP pages.
>
There are other cases where the limit can be reached. Examples I know are in generated rule code and constant inclusion (string and numeric.)
> In regards to theory and forum-speak, yes, you made a
> good point for readers that like to take single
> sentences and isolate them from the context and the
> meaning of the sentences around them.
>
> My comment literally, about JSP pages having no size
> limitations is then incorrect.
>
> My suggestion to solve the issue of sharing data
> amongst multiple JSP pages using the include
> directive is still valid, in my opinion.
>
I didn't say it was invalid.
I was correcting the impression that there are no fixed limits. Running in to such a limit can be quite a surprise if you are unaware that such a limit exists. Most people will not run in to it. Some will.
People do run in to it, so it shouldn't be ignored. And it happens enough that it isn't theorectical. Constrast this with C++ code which will have limits as well. But unlike the numerous cases that I have seen this occur in java I have only ever seen it once in C++. It happened to me with 3rd party rule generation code and I had never even consider that it was possible up until that point and obviously the creators of the 3rd party tool had never considered it either.
# 16
Good points. C++ is a more 'heavy duty' language than Java. In most cases the JRE and Java Compiler are written in C++.In a rough sense Java is a 'softer' version of C++.C# is an implementation of C++ assimilating the 'softer' characteristics of Java.
# 17
> Good points. C++ is a more 'heavy duty' language than
> Java. In most cases the JRE and Java Compiler are
> written in C++.
>
> In a rough sense Java is a 'softer' version of C++.
>
> C# is an implementation of C++ assimilating the
> 'softer' characteristics of Java.
And until this point I hadn't consider that there is probably a hard limit in C# (.Net) as well but I don't know what it is.
