A compromise solution: have the request-uri in it's "native" app..and then duplicate those request-uris in a specialized app that centralizes those lookup screens. I don't think there would be much worry about the request-uri/view-map definitions changing all too often, while the underlying screen might.
--- Leon Torres <[EMAIL PROTECTED]> wrote: > Well, the current situation isn't any more "modular" or "natural". > We have to > specify a LookupProduct that points to the product lookup screen in > applications/product/ in a bunch of different web apps that need it. > > The only difference of putting them in one controller.xml is that it > will cut > down code bloat a little and speed up development a small amount. > It's slightly > more pragmatic from the developer's perspective than the present > situation. > > - Leon > > David E. Jones wrote: > > > > I agree with what Adrian wrote on this one... > > > > The lookup screens should be defined in their most natural > component. If > > we were to have an include file for lookups across many components, > > > which component would be put it in? > > > > -David > > > > > > On Feb 8, 2007, at 12:57 PM, Adrian Crum wrote: > > > >> At first glance this would seem like a logical thing to do. The > >> downside is you would lose modularity. In other words, there may > be > >> complications with installations that don't mount all components. > >> > >> > >> Leon Torres wrote: > >>> Hi folks, I saw that an <include> directive is possible in > >>> controller.xml and was wondering if we should put all the Lookups > > >>> like LookupProduct in one xml for convenience. This will allow > >>> applications to take advantage of all available lookups in the > system > >>> without having to duplicate the request and view maps. > >>> It would be nice to start organizing all these requests. :-) > >>> - Leon > > >
