On 10/2/01 12:27 PM, "Daniel Rall" <[EMAIL PROTECTED]> wrote:
> Jason van Zyl <[EMAIL PROTECTED]> writes: > >>>> 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). >> >> I can't say I understand that sentence. To run the service you need the >> service framework do you not? > > The only thing that the service framework currently provides is > semi-clean singleton access and Service ExtendedProperties. If it > wasn't for the Service getConfiguration() method, one could do the > following: > > LocalizationService localization = new TurbineLocalizationService(); > localization.init(); > Locale defaultLocale = localization.getLocale(null); > > Even using getConfiguration(), one can do Service.setServiceBroker() > to provide a the ExtendedProperties data. > > Not that I'd actually do that, it's just possible, that's all (and it > used to be eaiser, btw). > >> And how does placing into a service the processing of a header >> easier? > > It's a useful place to stick code--a utility class would work just as > well. You love utility classes, right? ;) I suppose it's somewhat subjective as to what a service is, but I would definitely tend toward a locale tool (capability map in jetspeed) being a standalone class that could be used by any webapp. I definitely do like utility classes :-) >> Users who choose to use DefaultTurbineRunData will have to use >> Fulcrum in order to parse a header. > > For parsing a header, the LocaleTokenizer class which I added recently > could be used instead. That would remove any dependency on the > services framework. However, getDefaultLocale() doesn't parse a > header--it just grabs fields from TR.props and creates a Locale > object. As I said in the previous message I don't mind fulcrum's use in a pluggable RunData implementation. I know that you are trying to make things flexible as possible, I'm just floating a sentiment of caution insofar as looking toward the future and not the project at hand. > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl http://tambora.zenplex.org http://jakarta.apache.org/turbine http://jakarta.apache.org/velocity http://jakarta.apache.org/alexandria http://jakarta.apache.org/commons --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
