> The first would be pushing a performance hit to > startup-time, so the user doesn't suffer from latency while waiting > for some expensive service to be manifested. In practice this is exactly what is happening in the given example.
> At any rate, as HLS suggested, statics are a > design smell, and T5 IoC was designed around IoC patterns, so it's not > that surprising. I can agree with that, and in my case yes it is a workaround. But that is not the issue... Ordered service creation does not depart from the spirit of IoC! Peter ----- Original Message ----- From: "Christian Gruber" <christianedwardgru...@gmail.com> To: "Tapestry users" <users@tapestry.apache.org> Sent: Monday, 27 July, 2009 18:52:29 GMT +02:00 Athens, Beirut, Bucharest, Istanbul Subject: Re: Tapestry 5 IoC Eagerloading and ordering of services On Jul 27, 2009, at 11:40 AM, Peter Stavrinides wrote: >> Create a service wrapper around >> DatabaseConnection.getReadConnection(). This will put the >> eager-loading mechanism on your side. > I will try this, but this is not relevant to the issue in question, > which is how to control the ordering of eagerloaded services. The > very need to eagerload a service already implies that order is > important, not being able to imho is an oversight. Not necessarily, there are two solid cases for eager-loading that don't require order. The first would be pushing a performance hit to startup-time, so the user doesn't suffer from latency while waiting for some expensive service to be manifested. The second would be for services which, if failed, should fail the entire application setup. These should be eagerly loaded so as to ensure you fix the problem before you think of your server as started. "Fail early," in other words. Not that it can't be useful, but it isn't the goal intended, if I understand correctly. At any rate, as HLS suggested, statics are a design smell, and T5 IoC was designed around IoC patterns, so it's not that surprising. Ordered service creation would specifically be a workaround to support legacy code which could not be easily hosted into an IoC situation. cheers, Christian. Christian Edward Gruber christianedwardgru...@gmail.com http://www.geekinasuit.com/ --------------------------------------------------------------------- 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
