We work with an application using multiple databases. So depending on
the logged user a different datasource might be used. Tapestry IoC made
it a breeze to hide this logic away from the pages and just @inject the
services.
We have a highly tier-ed application where all low lever logic is define
in a BaseTapestry-module on top of which the different thin
implementations are build. Through the IoC it is a very easy to
configure any of the default behaviour in the base module through the
Configuration. One example is the instantation of our own SpringContext.
Just contribute, or overrrite a bunch of paths to *beans.xml and
property definitions and you'll load a completely different set of
spring configurations. By using reasonable defaults, this allows us to
truely build a no configuration application. Checkout and it runs.
I have yet to find an area in tapestry that you cannot change to you own
custom liking. That in combination with "it just works out of the box"
makes me a true believer.
The choice to move to Tapestry5 about 2 years ago has been one of our
best technology shifts!
Cheers,
Joost
Howard Lewis Ship wrote:
Outside of framework building (of course) my more mundane tasks:
Building DAO services around Hibernate, to reduce code clutter.
Building a deferred job execution service, to process operations in
the background.
Integrating with significant subsystems, like Quartz.
Creating tools to allow page content to be rendered and sent as email.
What I like about the IoC approach is that you naturally tend to
decompose things properly (or at least, it gives you the option). That
mail sending bit is in two pieces: one that's mostly about Tapestry:
rendering a Block, capturing the result, then deferring to a second
service to do the actual mailing. The second service is a wrapper
around javax.mail.Session and Transport, and encapsulates those two
ugly APIs. The job executor allows the app to continue running, with
the mail sending deferred to a pooled thread.
IoC means you can easily break your problems into small and
individually testable pieces, and isolate difficult external
dependencies ... and the container is responsible for assembling
everything at runtime.
On Tue, Dec 1, 2009 at 9:30 PM, Yeargan Yancey <yan...@unt.edu> wrote:
I have a largely academic interest in Tapestry and have been following the list
for several months. I have seen many discussions go by about the technical
issues of implementing and using Tapestry IOC services. Recently, however, I
began to develop a persistent and growing curiosity about the sorts of tasks
that seasoned Tapestry developers decide to implement as IOC services; being
especially curious about complex combinations of such services. I suspect some
have come up with quite clever solutions and are just dying to share. Here's
your chance. I'm asking. What is it that your IOC services do?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
