on 10/2/01 8:09 AM, "Daniel Rall" <[EMAIL PROTECTED]> wrote:
> Jason van Zyl <[EMAIL PROTECTED]> writes: > >> On 10/2/01 1:05 AM, "Jon Stevens" <[EMAIL PROTECTED]> wrote: >> >>> on 10/1/01 8:22 PM, "Jason van Zyl" <[EMAIL PROTECTED]> wrote: >>> >>> Why? We have a nice service in fulcrum that deals with localization. >> >> That's great, just don't directly couple it to turbine. I've spent an >> enormous amount of time splitting out the parts of turbine and I would >> really prefer not to see more of this coupling happen. In short I see >> turbine being an API for a web application and as such the final set of >> interfaces should be free of references to external packages. > > The LocalizationService would not become part of the interface. It > would only be used in the implementation. > >> That being said DefaultTurbineRunData is pluggable so it probably >> isn't that big of a deal to couple fulcrum to a pluggable class but >> I don't want to see things creeping into the RunData interface due >> to the use of Fulcrum in DefaultTurbineRunData. > > I would also like to keep the Fulcrum classes out of the interface > since I have also gone through so much pain to date doing so (even in > cases where I think doing so borders on the ridiculous ;P ). > >> I also feel that a service to pick off the locale is a bit of >> overkill in that there is a requirement for a service framework to >> process a header. > > There would not be a requirement for the complete service framework, > only for a single service (though the framework sure does make things > easier). +1 Jason, if Turbine can't have (non-interface) dependencies on Fulcrum, then what is the point of Fulcrum? Projects are supposed to use Fulcrum. -jon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
