It then stores this instance into the session and gives us a
reference to it.
All this works okay, but imagine that one day we have created a real data source,
and so now we want to have the data source ASO like this:
@ApplicationState
private RealDataSource dataSource;
We would have to find all the references to this ASO and change them then. Not
impossible, but this isn't a good design. To avoid this, we create the IDataSource
interface, and our MockDataSource implements it. Ideally, we would wish the ASO
to be defined in a generic way, like this:
@ApplicationState
private IDataSource dataSource;
This way, we could have any implementation of IDataSource working as an
ASO??”they will all look exactly the same for the pages. But how to tell Tapestry
which class to instantiate when we define an ASO as an interface? This is exactly
what we are going to find out now.
We shall see some lengthy names of Tapestry-specific classes, but don't be afraid.
The logic of what we are going to do is quite simple.
Simple Components
[ 124 ]
From the very beginning, we had a package named com.packtpub.celebrities.
services in our application, and a single class, AppModule in it, generated for us
by Maven.
Pages:
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169