On 4/27/05, Joe Germuska <[EMAIL PROTECTED]> wrote: > At 5:46 PM +0100 4/27/05, Niall Pemberton wrote: > >Sounds good to me. > > > >I've realized the wiki is incorrect - since if you don't specify a > >"chainConfig" parameter then it uses the default one shipped. Maybe we can > >make it all automatic if no chainConfig is specified. - if theres a tiles > >chain config present (i.e. they ship the tiles jar) then use that one, > >otherwise the default? > > Two independent things: first, the bigger one: I'm not that excited > about the current bootstrapping mechanism for the chain. It doesn't > play well with the possibility that you don't want to use Digester to > create your CatalogFactory; maybe we should shift the responsibility > for initializing the chains into the RequestProcessor instead -- that > provides a very tidy place to drop in instead a > "SpringComposableRequestProcessor" which could retrieve its > CatalogFactory from a Spring ApplicationContext instead of digester > -- which provides a good way to provide collaborators to individual > chain commands.
Perhaps I'm missing something, but I don't think moving initialisation into the *request processor* is tidy at all. Initialisation should happen before any requests come in. I do believe that we should be splitting out the whole config / init mechanism so that we can provide alternative ways of doing that. That's something that's been on my personal to-do list for some time, but hasn't bubbled to the top yet. > More immediately, though, whether we change it or move it into the > default RequestProcessor, I have no problem with having it check > first for the presence of the tiles version of the chain config and > then for the default; since it's just a String value (for the > classpath URI), it's not a true dependency, and I think the value for > users would be considerable. > > Does anyone object to testing for the tiles config first? And does > anyone have any strong feelings about where the chain initialization > code lives? I do, I guess. The goal should be *no* knowledge of Tiles outside of Tiles itself. If we can't do that, then we're not properly extensible. I know we're not there yet, but testing for Tiles first is a step in the opposite direction, IMO. -- Martin Cooper > Joe > > > >Niall > > > >----- Original Message ----- > >From: "Joe Germuska" <[EMAIL PROTECTED]> > >Sent: Wednesday, April 27, 2005 5:22 PM > > > > > >> Niall, and everyone else:: > >> > >> This update made me realize that I still haven't gotten an answer > >> about what happened to the "Tiles" chain-config, and made me also > >> realize that for typical users, we can and should make this easier > >> than as Niall described it. > >> > >> I believe we should keep a chain-config.xml in the tiles JAR which is > >> all people need, so that they can simply specify an alternate chain > >> config with no editing. I will create and add this. Note that we'll > >> have a little extra burden to make sure it maintains synch with the > >> version in struts-core, but I think that's reasonable; I don't think > >> people should have to muck around to extract and edit an XML file > >> just to use Tiles. (Of course, I can't imagine writing an app where > >> I'm not mucking around with a customized chain-config.xml any more > >> anyway, but still, we should keep from making that a requirement for > >> people.) > > > > > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > -- > Joe Germuska > [EMAIL PROTECTED] > http://blog.germuska.com > "Narrow minds are weapons made for mass destruction" -The Ex > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
