You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Daniel Rall <dl...@finemaltcoding.com> on 2001/10/02 02:36:57 UTC
DefaultTurbineRunData.getDefaultLocale()
Jon Stevens <jo...@latchkey.com> writes:
> Seems like DefaultTurbineRunData.getDefaultLocale() should reference the
> Localizationservice to get its information.
I like this idea, and think the dependency is reasonable. If this
sounds okay to everyone else, I'd like to implement it.
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: DefaultTurbineRunData.getDefaultLocale()
Posted by Jon Stevens <jo...@latchkey.com>.
on 10/2/01 8:24 AM, "Jason van Zyl" <jv...@apache.org> wrote:
> I'm not saying it can't, I'm saying that trends in past have proven to be
> that the non-interface dependencies creep into the interfaces because the
> implementation is done without really thinking about the interface.
> Generally in the past an interface has been created with a single
> implementation already completed. It's just a word of caution.
Hence the reason why DLR asked on the list first. He is trying to break the
trends in the past by making sure that things are ok before going forward.
> In the future projects may use Fulcrum. But that may not be the case, even
> though even in 3.x this is the case.
Exactly.
Summary: There is duplicated code in both Turbine and Fulcrum with regards
to Localization. I noticed this and pointed it out to DLR. DLR turned around
and asked on the list (ie: you) if it would be ok to remove this duplicated
code with a dependency.
-jon
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: DefaultTurbineRunData.getDefaultLocale()
Posted by Jason van Zyl <jv...@apache.org>.
On 10/2/01 11:13 AM, "Jon Stevens" <jo...@latchkey.com> wrote:
>>
>> 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?
I'm not saying it can't, I'm saying that trends in past have proven to be
that the non-interface dependencies creep into the interfaces because the
implementation is done without really thinking about the interface.
Generally in the past an interface has been created with a single
implementation already completed. It's just a word of caution.
> Projects are supposed to use Fulcrum.
In the future projects may use Fulcrum. But that may not be the case, even
though even in 3.x this is the case.
> -jon
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
--
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: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: DefaultTurbineRunData.getDefaultLocale()
Posted by Jon Stevens <jo...@latchkey.com>.
on 10/2/01 8:09 AM, "Daniel Rall" <dl...@finemaltcoding.com> wrote:
> Jason van Zyl <jv...@apache.org> writes:
>
>> On 10/2/01 1:05 AM, "Jon Stevens" <jo...@latchkey.com> wrote:
>>
>>> on 10/1/01 8:22 PM, "Jason van Zyl" <jv...@apache.org> 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: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: DefaultTurbineRunData.getDefaultLocale()
Posted by Jason van Zyl <jv...@apache.org>.
On 10/2/01 12:27 PM, "Daniel Rall" <dl...@finemaltcoding.com> wrote:
> Jason van Zyl <jv...@apache.org> 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: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
--
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: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: DefaultTurbineRunData.getDefaultLocale()
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Jason van Zyl <jv...@apache.org> 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? ;)
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: DefaultTurbineRunData.getDefaultLocale()
Posted by Jason van Zyl <jv...@apache.org>.
On 10/2/01 11:09 AM, "Daniel Rall" <dl...@finemaltcoding.com> wrote:
> Jason van Zyl <jv...@apache.org> writes:
>
>> On 10/2/01 1:05 AM, "Jon Stevens" <jo...@latchkey.com> wrote:
>>
>>> on 10/1/01 8:22 PM, "Jason van Zyl" <jv...@apache.org> 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.
Yes, but things tend to creep back into the interfaces because there is only
one implementation that was usually made first. Just pointing out a trend.
>> 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 ).
To keep the interfaces free of external references is an absolute must, it
might seem ridiculous because we are working backward. From existing
implementation to stable design.
>> 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? And how does placing into a service the
processing of a header easier? Users who choose to use DefaultTurbineRunData
will have to use Fulcrum in order to parse a header. It seems natural now
because turbine is still heavily tied to fulcrum but that may not always be
the case.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
--
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: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: DefaultTurbineRunData.getDefaultLocale()
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Jason van Zyl <jv...@apache.org> writes:
> On 10/2/01 1:05 AM, "Jon Stevens" <jo...@latchkey.com> wrote:
>
>> on 10/1/01 8:22 PM, "Jason van Zyl" <jv...@apache.org> 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).
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: DefaultTurbineRunData.getDefaultLocale()
Posted by Jason van Zyl <jv...@apache.org>.
On 10/2/01 1:05 AM, "Jon Stevens" <jo...@latchkey.com> wrote:
> on 10/1/01 8:22 PM, "Jason van Zyl" <jv...@apache.org> wrote:
>
>> I myself do not like this idea. The API for anything to do with locales
>> should be independent of fulcrum.
>
> 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.
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 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.
> Are you saying that service should also use something external than it as
> well?
I don't understand the question.
> -jon
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
--
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: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: DefaultTurbineRunData.getDefaultLocale()
Posted by Jon Stevens <jo...@latchkey.com>.
on 10/1/01 8:22 PM, "Jason van Zyl" <jv...@apache.org> wrote:
> I myself do not like this idea. The API for anything to do with locales
> should be independent of fulcrum.
Why? We have a nice service in fulcrum that deals with localization.
Are you saying that service should also use something external than it as
well?
-jon
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: DefaultTurbineRunData.getDefaultLocale()
Posted by Jason van Zyl <jv...@apache.org>.
On 10/1/01 8:36 PM, "Daniel Rall" <dl...@finemaltcoding.com> wrote:
> Jon Stevens <jo...@latchkey.com> writes:
>
>> Seems like DefaultTurbineRunData.getDefaultLocale() should reference the
>> Localizationservice to get its information.
>
> I like this idea, and think the dependency is reasonable. If this
> sounds okay to everyone else, I'd like to implement it.
I myself do not like this idea. The API for anything to do with locales
should be independent of fulcrum.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
--
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: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org