Re: IOC Service Survey
My latest use of IoC was to rewire my DAOs so that they accept a DbConnectionFactory I @Inject in pages. When a DAO method is called with an ASO holding a user's DB Connection info, the injected factory's getConnection() is used. For some factories, getConnection() will create a small connection pool as necessary, linked to the user's id and some other stuff. Then he can run reports against / select items from one of 160 other databases that all have the same schema (someone stop the madness!!) For other factories, getConnection() will use a application wide connection pool to a central db. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: IOC Service Survey
A Tapestry IoC service is just a bean. If you read up on Spring IoC or Guice IoC they are all the same concepts and fulfill the same purposes. Each might have slightly different features mechanisms, but you get the idea. So if your question is truly academic, you should be reading up on generic IoC concepts, sprint and guice as well. The main design pattern used is around constructing singletons ( mostly: general configuration, dao access, overriding tapestry logic, and business logic with caching ). But you can have the IoC container construct objects according to a scope, so it's not just a singleton pattern, but a new object per request, (business logic that has state specific to the current request only). On 12/1/09 9:30 PM, Yeargan Yancey 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
Re: IOC Service Survey
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 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
Re: IOC Service Survey
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 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 > > -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
IOC Service Survey
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
