Run the application, and it should work exactly as it did before. As you see, there are
three different ways to define a component on a page:
Explicitly in the template.
Invisibly in the template.
In the page class.
With the last option, we achieve the cleanest separation between code and
presentation, but, to my taste, those complicated annotations look a bit ugly. On
the other hand, having just one attribute, t:id, in the page template to represent a
potentially complex component is a valuable feature of Tapestry. This can become
important in applications with complex design or if you want to make the interaction
between designers and developers absolutely minimal.
Right now, while adding new pages, we place templates directly at the root of the
web application and page classes under the pages sub-package of the application's
package, com.packtpub.t5first. However, if we wish, we can give our project an
additional structure.
??? ??? ???
The Foundations of Tapestry
[ 70 ]
Structuring the Application
As the number of pages in our application grows, we might want to structure them
in a particular manner. For example, if there is some order handling functionality,
we might find it convenient to put all the order-related pages into the \order
subdirectory.
Pages:
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101