You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pivot.apache.org by Chris Bartlett <cb...@gmail.com> on 2011/07/10 12:37:10 UTC
Some thoughts on org.apache.pivot.util.Resources / localization
Today is the first time that I really looked into Pivot's localization.
While playing around, I wanted to create a Resources instance and
populate it dynamically, but realised that I couldn't and that
Resources is not sub-class friendly.
I came out of it wondering if it is unreasonable to wish for the following ...
- ability to specify an arbitrary data source
- use of a non-JSON data format
- support for put & remove
This could be made possible through some basic refactoring, along the
lines of...
1) Extract a Resource interface from the current class (potentially renamed)
2) Extract any reuseable guts of the current Resource class into an
abstract base implementation
- handling of parent/child hierarchy
- iteration over locale info naming conventions (resourceName -->
resourceName_en --> resourceName_en_GB)
3) Define some new methods in either the abstract class or interface
- getResource(...) // retrieve data from *somewhere*
- Map parseResource(...) // populate the internal Dictionary with
whatever data was retrieved
4) Create a JSONClasspathResource implementation from what is left of
the original Resource class, building upon the base class (would
remain functionally identical to current class)
5) Change BXMLSerializer, Resolvable, Alert, Prompt etc to use the new
interface & JSONClasspathResource
Or even just making the fields of the current Resource class
protected, would allow subclasses to
- add new constructors (to bypass the classpath & JSON data format)
- override methods (get & put) to add new functionality
(less work, less impact, but ugly)
Note that I'm not suggesting that Pivot needs to *provide* multiple
'Resources' implementations. Just that a user be able to plug in
their own implementation without too much hassle. Keeping just the
JSON/classpath one would be fine if I can create and use my own one.
I haven't yet thought through every detail of either 'solution', as
there may well be no desire for change. This email is just the result
of a 5 min brainstorm.
One more thing...
On this tutorial page, should it be made explicit that the languages
mentioned only apply to the demo applet on the page, and not Pivot as
a whole? (I realise there are very few UI text strings that are not
user specified)
http://pivot.apache.org/tutorials/localization.html
<quote>
The following resource bundles are provided; if your default system
locale is among these, you should see a localized version of the
application. Otherwise, the default locale ("en") will be used:
Localization.json
Localization_cn.json
Localization_de.json
Localization_it.json
Localization_ph.json
</quote>
Chris
Re: Some thoughts on org.apache.pivot.util.Resources / localization
Posted by Chris Bartlett <cb...@gmail.com>.
org.apache.pivot.util.Resources would have to remain as a non-abstract
class in order to prevent breaking downstream code.
On 10 July 2011 17:37, Chris Bartlett <cb...@gmail.com> wrote:
> Today is the first time that I really looked into Pivot's localization.
> While playing around, I wanted to create a Resources instance and
> populate it dynamically, but realised that I couldn't and that
> Resources is not sub-class friendly.
>
> I came out of it wondering if it is unreasonable to wish for the following ...
> - ability to specify an arbitrary data source
> - use of a non-JSON data format
> - support for put & remove
>
>
> This could be made possible through some basic refactoring, along the
> lines of...
> 1) Extract a Resource interface from the current class (potentially renamed)
> 2) Extract any reuseable guts of the current Resource class into an
> abstract base implementation
> - handling of parent/child hierarchy
> - iteration over locale info naming conventions (resourceName -->
> resourceName_en --> resourceName_en_GB)
> 3) Define some new methods in either the abstract class or interface
> - getResource(...) // retrieve data from *somewhere*
> - Map parseResource(...) // populate the internal Dictionary with
> whatever data was retrieved
> 4) Create a JSONClasspathResource implementation from what is left of
> the original Resource class, building upon the base class (would
> remain functionally identical to current class)
> 5) Change BXMLSerializer, Resolvable, Alert, Prompt etc to use the new
> interface & JSONClasspathResource
>
> Or even just making the fields of the current Resource class
> protected, would allow subclasses to
> - add new constructors (to bypass the classpath & JSON data format)
> - override methods (get & put) to add new functionality
> (less work, less impact, but ugly)
>
> Note that I'm not suggesting that Pivot needs to *provide* multiple
> 'Resources' implementations. Just that a user be able to plug in
> their own implementation without too much hassle. Keeping just the
> JSON/classpath one would be fine if I can create and use my own one.
>
> I haven't yet thought through every detail of either 'solution', as
> there may well be no desire for change. This email is just the result
> of a 5 min brainstorm.
>
>
> One more thing...
> On this tutorial page, should it be made explicit that the languages
> mentioned only apply to the demo applet on the page, and not Pivot as
> a whole? (I realise there are very few UI text strings that are not
> user specified)
>
> http://pivot.apache.org/tutorials/localization.html
> <quote>
> The following resource bundles are provided; if your default system
> locale is among these, you should see a localized version of the
> application. Otherwise, the default locale ("en") will be used:
> Localization.json
> Localization_cn.json
> Localization_de.json
> Localization_it.json
> Localization_ph.json
> </quote>
>
> Chris
>
Re: Some thoughts on org.apache.pivot.util.Resources / localization
Posted by Greg Brown <gk...@verizon.net>.
>> When I say "use case", I mean a specific example of something an application developer might want to do with the platform. For example, I might want to support deferred loading of tree view data in my application, since the tree may be large, or it may be expensive to build individual nodes. That's the use case - it doesn't speak to how it will be accomplished, just what it needs to do, and why.
>
> Does this meet that definition?
> - Allow BXMLSerializer *use* localization resource bundles whose data
> comes from an arbitrary data source and is stored in an arbitrary
> format.
> i.e. Not limited to JSON on the classpath, named and located using a
> fully qualified class name.
No - that still describes the *how*. What I'd like to understand is *why* such a feature is required, or *what* it might be used for.
G
Re: Some thoughts on org.apache.pivot.util.Resources / localization
Posted by Chris Bartlett <cb...@gmail.com>.
On 12 July 2011 02:19, Greg Brown <gk...@verizon.net> wrote:
>> If I can find the time tomorrow, I'll read up on UML and then get back
>> to you - assuming you are talking about a UML 'use case'?
>
> When I say "use case", I mean a specific example of something an application developer might want to do with the platform. For example, I might want to support deferred loading of tree view data in my application, since the tree may be large, or it may be expensive to build individual nodes. That's the use case - it doesn't speak to how it will be accomplished, just what it needs to do, and why.
Does this meet that definition?
- Allow BXMLSerializer *use* localization resource bundles whose data
comes from an arbitrary data source and is stored in an arbitrary
format.
i.e. Not limited to JSON on the classpath, named and located using a
fully qualified class name.
A follow up might be
- Allow BXMLSerializer to to create/retrieve such bundles itself as
opposed to just using ones provided to it
Re: Some thoughts on org.apache.pivot.util.Resources / localization
Posted by Chris Bartlett <cb...@gmail.com>.
Sandro,
Thanks for taking the time to follow this thread. I'm interested to
hear how your company handles this kind of thing.
It does sound similar to my experiences, but while I have seen
different methods in different places, there has never been common
solution. However, localization has never been a primary activity for
me, rather something to consider when designing and implementing
solutions. If there is a current localization solution in place, then
that pretty much means we have to adapt and use it.
Chris
On 12 July 2011 05:12, Sandro Martini <sa...@gmail.com> wrote:
> Hi all and sorry for the delay.
> I'm writing from a mobile device so I'll be short for now ... at work we
> have a "localization" server containing all localized resources (and related
> app to handle them, and to let translators, IT and QA people to play with
> those resources). Some app download resources and use them in a static
> (release oriented) way, while others use them dynamically (without having to
> deploy something new). Maybe this could be a use case like the idea proposed
> by Chris ... I'll be happy to discuss this better with all devs, but maybe a
> jira ticket could help. I have to go now.
> Bye to all,
> Sandro
> Il giorno 11/lug/2011 23:51, "Chris Bartlett" <cb...@gmail.com> ha
> scritto:
>> I don't have a background in Swing dev, so that doesn't really help.
>> (I can continue this tomorrow - my morning alarm will go off in about 90
> mins)
>>
>> On 12 July 2011 04:45, Greg Brown <gk...@verizon.net> wrote:
>>>> The primary objective is simply to be able to *choose* where the data
>>>> comes from and not be limited to a single option, especially if it
>>>> means avoiding an otherwise unnecessary build step and duplication of
>>>> data.
>>>
>>> Let me ask the question a different way. If you were building a Swing
> app, which primarily uses properties files for localization, how would you
> solve this problem?
>>>
>>>
>
Re: Some thoughts on org.apache.pivot.util.Resources / localization
Posted by Greg Brown <gk...@verizon.net>.
> I'm writing from a mobile device so I'll be short for now ... at work we
> have a "localization" server containing all localized resources (and related
> app to handle them, and to let translators, IT and QA people to play with
> those resources). Some app download resources and use them in a static
> (release oriented) way, while others use them dynamically (without having to
> deploy something new). Maybe this could be a use case like the idea proposed
> by Chris ...
Yes, quite possibly. But one thing I'd like to know is - are these client-based or server-based apps? I can certainly see an argument for pulling server-side resources from a database, but I'm not sure that would be a good architecture for a client-side app.
Re: Some thoughts on org.apache.pivot.util.Resources / localization
Posted by Sandro Martini <sa...@gmail.com>.
Hi all and sorry for the delay.
I'm writing from a mobile device so I'll be short for now ... at work we
have a "localization" server containing all localized resources (and related
app to handle them, and to let translators, IT and QA people to play with
those resources). Some app download resources and use them in a static
(release oriented) way, while others use them dynamically (without having to
deploy something new). Maybe this could be a use case like the idea proposed
by Chris ... I'll be happy to discuss this better with all devs, but maybe a
jira ticket could help. I have to go now.
Bye to all,
Sandro
Il giorno 11/lug/2011 23:51, "Chris Bartlett" <cb...@gmail.com> ha
scritto:
> I don't have a background in Swing dev, so that doesn't really help.
> (I can continue this tomorrow - my morning alarm will go off in about 90
mins)
>
> On 12 July 2011 04:45, Greg Brown <gk...@verizon.net> wrote:
>>> The primary objective is simply to be able to *choose* where the data
>>> comes from and not be limited to a single option, especially if it
>>> means avoiding an otherwise unnecessary build step and duplication of
>>> data.
>>
>> Let me ask the question a different way. If you were building a Swing
app, which primarily uses properties files for localization, how would you
solve this problem?
>>
>>
Re: Some thoughts on org.apache.pivot.util.Resources / localization
Posted by Greg Brown <gk...@verizon.net>.
Oof. Get some sleep.
On Jul 11, 2011, at 5:51 PM, Chris Bartlett wrote:
> I don't have a background in Swing dev, so that doesn't really help.
> (I can continue this tomorrow - my morning alarm will go off in about 90 mins)
>
> On 12 July 2011 04:45, Greg Brown <gk...@verizon.net> wrote:
>>> The primary objective is simply to be able to *choose* where the data
>>> comes from and not be limited to a single option, especially if it
>>> means avoiding an otherwise unnecessary build step and duplication of
>>> data.
>>
>> Let me ask the question a different way. If you were building a Swing app, which primarily uses properties files for localization, how would you solve this problem?
>>
>>
Re: Some thoughts on org.apache.pivot.util.Resources / localization
Posted by Chris Bartlett <cb...@gmail.com>.
I don't have a background in Swing dev, so that doesn't really help.
(I can continue this tomorrow - my morning alarm will go off in about 90 mins)
On 12 July 2011 04:45, Greg Brown <gk...@verizon.net> wrote:
>> The primary objective is simply to be able to *choose* where the data
>> comes from and not be limited to a single option, especially if it
>> means avoiding an otherwise unnecessary build step and duplication of
>> data.
>
> Let me ask the question a different way. If you were building a Swing app, which primarily uses properties files for localization, how would you solve this problem?
>
>
Re: Some thoughts on org.apache.pivot.util.Resources / localization
Posted by Greg Brown <gk...@verizon.net>.
> The primary objective is simply to be able to *choose* where the data
> comes from and not be limited to a single option, especially if it
> means avoiding an otherwise unnecessary build step and duplication of
> data.
Let me ask the question a different way. If you were building a Swing app, which primarily uses properties files for localization, how would you solve this problem?
Re: Some thoughts on org.apache.pivot.util.Resources / localization
Posted by Chris Bartlett <cb...@gmail.com>.
On 12 July 2011 04:19, Greg Brown <gk...@verizon.net> wrote:
>> I can think of more than one who would not accept being
>> told that they had to use JSON as a data format (even for something as
>> simple as a resource file), and that these resource files must live on
>> the classpath in a location dictated to them.
>
> OK, but that still speaks primarily to personal bias ("I don't like JSON files; I don't like storing my JSON files in such and such a directory"). It doesn't explain (in sufficient detail) what the actual objective is.
(This was just meant as a little real world background, not a use case
or justification)
I agree, but bias or not, the client is who ultimately has the choice.
I have been in a situation where downtime of a global 24/7 app had to
be scheduled 2 weeks ahead of time merely to change the log level in a
log4j config file. Some places have rules which just have to be
adhered to, regardless of how hard they might be to justify.
The primary objective is simply to be able to *choose* where the data
comes from and not be limited to a single option, especially if it
means avoiding an otherwise unnecessary build step and duplication of
data.
What appears to be a clean and simple localization solution in Pivot,
is let down somewhat by what seems like an artificial limitation on
where a simple map of strings must come from. (IMHO)
>> One other point...
>> As you may have noticed - I have a thing for the final keyword.
>
> I'm a fan of "final" as well, but I probably don't use it as often as I should. I definitely see the value in final classes and static final member variables (constants). I'm on the fence about method finality - I feel like it is too easy to misapply, so I usually omit it.
Likewise. If you can forgive the pun, it's use on methods seems *too*
final. Easy to make the wrong call. Variables and classes are
generally more obvious.
My method parameters and variables just don't look right if they are
not prefixed with a nice little 'final', helpfully highlighted in the
IDE.
Re: Some thoughts on org.apache.pivot.util.Resources / localization
Posted by Greg Brown <gk...@verizon.net>.
> I can think of more than one who would not accept being
> told that they had to use JSON as a data format (even for something as
> simple as a resource file), and that these resource files must live on
> the classpath in a location dictated to them.
OK, but that still speaks primarily to personal bias ("I don't like JSON files; I don't like storing my JSON files in such and such a directory"). It doesn't explain (in sufficient detail) what the actual objective is.
> One other point...
> As you may have noticed - I have a thing for the final keyword.
I'm a fan of "final" as well, but I probably don't use it as often as I should. I definitely see the value in final classes and static final member variables (constants). I'm on the fence about method finality - I feel like it is too easy to misapply, so I usually omit it.
Re: Some thoughts on org.apache.pivot.util.Resources / localization
Posted by Chris Bartlett <cb...@gmail.com>.
On 12 July 2011 03:21, Greg Brown <gk...@verizon.net> wrote:
>>> Maybe, but when unchecked those types of changes can destabilize a system.
>> I'm not sure if you noticed the 'locally' bit here.
> I must have overlooked that. But making local changes goes against what we were talking about yesterday. The platform is not going to evolve/improve if committers are not willing to propose and push changes back into the main source tree.
I agree, but sometimes the effort involved far exceeds the personal
and/or karmic benefit.
>> The original didn't go into any detail on the
>> reasoning behind the 'wishes', but that is because I was half
>> expecting to be told that I can just achieve X another way.
>
> Interesting. :-) Often, that is the case, but not here. When we originally created the Resources class, we didn't see a strong case for making it extensible. Maybe there is one and we just overlooked it. Or maybe there is not. That's why I'd like to understand the requirements better.
Sure.
I started investigating localization properly in Pivot for the first
time yesterday, and began thinking about the restrictions I have
previously been required to work within when developing a solution for
a client. I can think of more than one who would not accept being
told that they had to use JSON as a data format (even for something as
simple as a resource file), and that these resource files must live on
the classpath in a location dictated to them.
Nobody would care if that were just the default implementation (which
they didn't have to use), but I can imagine problems trying to justify
an additional build step just to generate the resource files from data
stored elsewhere which was already accessible through different means,
such as a web service.
One other point...
As you may have noticed - I have a thing for the final keyword. It is
perhaps the most used keyword in my java code, and is used liberally
for signifying intent on variables and classes (though bizarrely not
so much for methods)
If I see a non-final class with only private fields my first thought
is that the intent was to allow sub classing, and that the private
fields were probably meant to be protected, but just missed as nobody
had actually created a subclass before now, and spotted them.
That is why I mentioned a possible private -> protected change here
and also in the MessageBus thread. Not necessarily that I think they
*should* be extensible, but just that by not using the final keyword,
a useful piece of intent is potentially lost, and questions of intent
might arise later.
Re: Some thoughts on org.apache.pivot.util.Resources / localization
Posted by Greg Brown <gk...@verizon.net>.
>> Maybe, but when unchecked those types of changes can destabilize a system.
> I'm not sure if you noticed the 'locally' bit here.
I must have overlooked that. But making local changes goes against what we were talking about yesterday. The platform is not going to evolve/improve if committers are not willing to propose and push changes back into the main source tree.
> Perhaps there is a way to use non-JSON resources located
> somewhere other than the classpath that I just missed?
At the moment there is not.
> The original didn't go into any detail on the
> reasoning behind the 'wishes', but that is because I was half
> expecting to be told that I can just achieve X another way.
Interesting. :-) Often, that is the case, but not here. When we originally created the Resources class, we didn't see a strong case for making it extensible. Maybe there is one and we just overlooked it. Or maybe there is not. That's why I'd like to understand the requirements better.
G
Re: Some thoughts on org.apache.pivot.util.Resources / localization
Posted by Chris Bartlett <cb...@gmail.com>.
>> However, this looks like it might be turning into a prime example of
>> when making a quick suggestion becomes a time consuming process which
>> could be avoided by simply making, and maintaining, a single change
>> locally. (1 change of 'private' --> 'protected')
>
> Maybe, but when unchecked those types of changes can destabilize a system.
I'm not sure if you noticed the 'locally' bit here. I was just saying
that maybe I should have kept my mouth shut and just made the change
in my own repository without raising it on the mailing list. It would
have saved time for both of us.
>> In my original email I mentioned that simply loosening the visibility
>> of the private internal map used by 'Resources' would allow different
>> data formats and data sources. Doing so would result in no API change
>> at all.
> Changing a member from private to protected is an API change.
Yes, I suppose it is. Perhaps I should have said breaking change or
somehow indicated that I just meant it is very localised.
>> It also mentioned some simple refactoring to extract an interface to
>> be used by consumers of the resource bundle, along with a possible
>> abstract class containing core reuseable code, such as the
>> hierarchy/resolution stuff. The existing Resources class would extend
>> the abstract class and implement the interface. I was not proposing
>> any new implementations to be supplied with Pivot, or any functional
>> change to the current implementation.
>
> These changes would require the creation of a new interface, and perhaps a new means of instantiating Resources (for example, JDK ResourceBundles don't have a constructor - they use a factory method). It would be helpful to understand how you envision this working.
I haven't thought through any end to end 'solution' for anything, as I
was initially asking about whether the mentioned functionality might
be considered useful/lacking. No point designing a solution for
others who don't have a problem, or for a problem that doesn't even
exist. Perhaps there is a way to use non-JSON resources located
somewhere other than the classpath that I just missed?
>> As the original mail also said, I have not looked into the bowels of
>> Pivot to see if this refactoring would be enough, as I was merely
>> making an initial suggestion to see if there was any interest in the
>> idea.
>
> OK. That was not clear to me from your email (I just took a look again, and I don't see any language indicating that it was meant to gauge developer interest in such a feature).
I thought that posting to the dev list, having established that I had
only just started looking into Pivot's localization, and asking the
question '[is it] unreasonable to wish for the following ...' would be
clear.
Communicating via email is never easy. I'll try harder next time,
although I did try to include 'coulds' and avoid 'shoulds' Although
re-reading it I think I missed out at least one more 'wish'.
> As I mentioned earlier, Pivot's feature set evolved from specific use cases and requirements. When proposing a change or new feature, I'd suggest maybe starting the discussion as follows:
>
> 1) I want to do X
> 2) I have tried doing Y and Z, but neither of those things let me do X [as efficiently as I would like to]
> 3) We could potentially solve this problem if we modified the API as follows: ...
> 3a) Alternatively, we could do it like this, and the tradeoffs would be: ...
>
> I don't know about anyone else, but that would help me better understand the motivation behind any changes you might want to suggest.
Yeah, that is great, and not too dissimilar from the structure of the
original mail. The original didn't go into any detail on the
reasoning behind the 'wishes', but that is because I was half
expecting to be told that I can just achieve X another way.
Re: Some thoughts on org.apache.pivot.util.Resources / localization
Posted by Greg Brown <gk...@verizon.net>.
> If I can find the time tomorrow, I'll read up on UML and then get back
> to you - assuming you are talking about a UML 'use case'?
When I say "use case", I mean a specific example of something an application developer might want to do with the platform. For example, I might want to support deferred loading of tree view data in my application, since the tree may be large, or it may be expensive to build individual nodes. That's the use case - it doesn't speak to how it will be accomplished, just what it needs to do, and why.
> However, this looks like it might be turning into a prime example of
> when making a quick suggestion becomes a time consuming process which
> could be avoided by simply making, and maintaining, a single change
> locally. (1 change of 'private' --> 'protected')
Maybe, but when unchecked those types of changes can destabilize a system.
> In my original email I mentioned that simply loosening the visibility
> of the private internal map used by 'Resources' would allow different
> data formats and data sources. Doing so would result in no API change
> at all.
Changing a member from private to protected is an API change.
> It also mentioned some simple refactoring to extract an interface to
> be used by consumers of the resource bundle, along with a possible
> abstract class containing core reuseable code, such as the
> hierarchy/resolution stuff. The existing Resources class would extend
> the abstract class and implement the interface. I was not proposing
> any new implementations to be supplied with Pivot, or any functional
> change to the current implementation.
These changes would require the creation of a new interface, and perhaps a new means of instantiating Resources (for example, JDK ResourceBundles don't have a constructor - they use a factory method). It would be helpful to understand how you envision this working.
> As the original mail also said, I have not looked into the bowels of
> Pivot to see if this refactoring would be enough, as I was merely
> making an initial suggestion to see if there was any interest in the
> idea.
OK. That was not clear to me from your email (I just took a look again, and I don't see any language indicating that it was meant to gauge developer interest in such a feature).
As I mentioned earlier, Pivot's feature set evolved from specific use cases and requirements. When proposing a change or new feature, I'd suggest maybe starting the discussion as follows:
1) I want to do X
2) I have tried doing Y and Z, but neither of those things let me do X [as efficiently as I would like to]
3) We could potentially solve this problem if we modified the API as follows: ...
3a) Alternatively, we could do it like this, and the tradeoffs would be: ...
I don't know about anyone else, but that would help me better understand the motivation behind any changes you might want to suggest.
G
Re: Some thoughts on org.apache.pivot.util.Resources / localization
Posted by Chris Bartlett <cb...@gmail.com>.
Greg,
If I can find the time tomorrow, I'll read up on UML and then get back
to you - assuming you are talking about a UML 'use case'?
However, this looks like it might be turning into a prime example of
when making a quick suggestion becomes a time consuming process which
could be avoided by simply making, and maintaining, a single change
locally. (1 change of 'private' --> 'protected')
In my original email I mentioned that simply loosening the visibility
of the private internal map used by 'Resources' would allow different
data formats and data sources. Doing so would result in no API change
at all.
It also mentioned some simple refactoring to extract an interface to
be used by consumers of the resource bundle, along with a possible
abstract class containing core reuseable code, such as the
hierarchy/resolution stuff. The existing Resources class would extend
the abstract class and implement the interface. I was not proposing
any new implementations to be supplied with Pivot, or any functional
change to the current implementation.
As the original mail also said, I have not looked into the bowels of
Pivot to see if this refactoring would be enough, as I was merely
making an initial suggestion to see if there was any interest in the
idea.
Chris
On 12 July 2011 00:15, Greg Brown <gk...@verizon.net> wrote:
>>> I think that a lot of what you describe makes sense for application data, but I'm not so
>>> sure it applies to resource bundles.
>> You can't imagine a scenario when someone might want any of the following?
>> - Different data format
>> - Different naming convention
>> - Different location convention (remote/local, classpath/filesystem)
>
> Sure I can imagine it, but that doesn't necessarily mean that the platform needs to support it. That's why I asked about use case. IMO, creating flexibility just for flexibility's sake (i.e. without basing it on specific use cases) simply tends to produce APIs that are more generic than they need to be.
>
> So, what is a concrete use case that cannot be addressed by the current API? And what do you think a new API that does address this use case might look like?
>
> And please don't say "I might want to store my resources on the server". That's not a use case, that's a solution.
>
> G
>
>
Re: Some thoughts on org.apache.pivot.util.Resources / localization
Posted by Greg Brown <gk...@verizon.net>.
>> I think that a lot of what you describe makes sense for application data, but I'm not so
>> sure it applies to resource bundles.
> You can't imagine a scenario when someone might want any of the following?
> - Different data format
> - Different naming convention
> - Different location convention (remote/local, classpath/filesystem)
Sure I can imagine it, but that doesn't necessarily mean that the platform needs to support it. That's why I asked about use case. IMO, creating flexibility just for flexibility's sake (i.e. without basing it on specific use cases) simply tends to produce APIs that are more generic than they need to be.
So, what is a concrete use case that cannot be addressed by the current API? And what do you think a new API that does address this use case might look like?
And please don't say "I might want to store my resources on the server". That's not a use case, that's a solution.
G
Re: Some thoughts on org.apache.pivot.util.Resources / localization
Posted by Chris Bartlett <cb...@gmail.com>.
On 11 July 2011 23:20, Greg Brown <gk...@verizon.net> wrote:
> I think that a lot of what you describe makes sense for application data, but I'm not so
> sure it applies to resource bundles.
You can't imagine a scenario when someone might want any of the following?
- Different data format
- Different naming convention
- Different location convention (remote/local, classpath/filesystem)
> If I pull all of my localized resources from a database and the network or DB server is down, I can't even display an error message to the user telling them what went wrong.
Seriously? :) OK, I will bite for now, but leave it at that...
Of course what you state is true if you get *ALL* resources from a
remote source, but not if the error message is retained/cached in a
local resource file. Perhaps the developer of the Pivot IIA (TM?) had
the forethought to hard code an error message or just show the
underlying stacktrace, or a 'fail whale' graphic etc, etc.
A sane solution would most likely have one default language fully
supported locally, and others available from remove sources as
required.
Some apps might store some of their UI (or even all of it) as BXML on
a remote server, so any missing resource strings required by them
would be moot.
Some apps might not perform any functions without access to remote
servers in any case.
Anyway, if resources are not available (locally or remotely), I
thought they just showed the raw '%key' string?
I'm not convinced that a non-perfect scenario negates the other scenarios.
Chris
>
>
> On Jul 11, 2011, at 12:06 PM, Chris Bartlett wrote:
>
>> On 11 July 2011 19:48, Greg Brown <gk...@verizon.net> wrote:
>>>> I came out of it wondering if it is unreasonable to wish for the following ...
>>>> - ability to specify an arbitrary data source
>>>> - use of a non-JSON data format
>>>
>>> Seems reasonable, though I'd like to understand the use case better.
>> Flexibility, pure and simple.
>>
>> All translations for a company's software might be maintained in a
>> central server/database with its own APIs, web services, caches etc.
>> This 'translation server' might maintain translations for multiple
>> versions of multiple applications destined for multiple clients and/or
>> runtime environments (development, testing, production). Perhaps
>> these translations can be updated/rolled back and published at any
>> time, with an expectation that the data will be propagated quickly and
>> picked up without the need to redeployment of applications.
>>
>> Allowing developers to provide their own custom implementations means
>> they can write one which pulls this data directly from the
>> server/cache/whatever and populates a 'Resources' instance. Any
>> changes in the translation server can be picked up the next time the
>> BXML is processed.
>>
>> It also removes the possibly redundant and unwanted steps of
>> retrieving this data, saving it in JSON format in a data file named
>> and located according to someone else's convention, in order to be
>> packaged into a jar or placed on the class path somehow.
>>
>> Or maybe someone simply hates JSON but loves CSV/XML/ini files? Or
>> someone else loves JSON, but prefers a different naming convention?
>> Yet another person hates the concept of resource *files*, but loves
>> web services because they just read an article telling them that is
>> what Company X does. I'm all for allowing such people the freedom to
>> create and use their own implementation.
>>
>>>> - support for put & remove
>>> I'm not sure this makes sense. AFAIK, even JDK ResourceBundles are not mutable.
>> Absolutely. This is not something that the current (or any future)
>> Pivot Resources class needs if other changes happen.
>>
>> If it were possible to create and use custom 'Resources'
>> implementations, then these would be redundant. However, if there
>> remains only one implementation (JSON on the classpath), then these
>> could be used after loading an empty/dummy 'Resources' file. The data
>> could come from anywhere, so this is a poor 'solution' for the first
>> scenario. Not pretty, but would at least allow some degree of
>> flexibility.
>>
>> Of course, as Resources is non-final, it could be extended if it's
>> internal map were made visible to subclasses. That would be less
>> ugly, but still not a perfect alternative.
>>
>> I only suggested put & remove as Resources implements Dictionary.
>> After some refactoring to allow custom implementations, perhaps a
>> dedicated 'Resources' interface needn't extend Dictionary at all, but
>> would rather just specify the actual methods required for accessing
>> the data. (ie, replace Dictionary with Iterable<String> and the
>> relevant get/contains/whatever methods).
>>
>> Chris
>
>
Re: Some thoughts on org.apache.pivot.util.Resources / localization
Posted by Greg Brown <gk...@verizon.net>.
I think that a lot of what you describe makes sense for application data, but I'm not so sure it applies to resource bundles. If I pull all of my localized resources from a database and the network or DB server is down, I can't even display an error message to the user telling them what went wrong.
On Jul 11, 2011, at 12:06 PM, Chris Bartlett wrote:
> On 11 July 2011 19:48, Greg Brown <gk...@verizon.net> wrote:
>>> I came out of it wondering if it is unreasonable to wish for the following ...
>>> - ability to specify an arbitrary data source
>>> - use of a non-JSON data format
>>
>> Seems reasonable, though I'd like to understand the use case better.
> Flexibility, pure and simple.
>
> All translations for a company's software might be maintained in a
> central server/database with its own APIs, web services, caches etc.
> This 'translation server' might maintain translations for multiple
> versions of multiple applications destined for multiple clients and/or
> runtime environments (development, testing, production). Perhaps
> these translations can be updated/rolled back and published at any
> time, with an expectation that the data will be propagated quickly and
> picked up without the need to redeployment of applications.
>
> Allowing developers to provide their own custom implementations means
> they can write one which pulls this data directly from the
> server/cache/whatever and populates a 'Resources' instance. Any
> changes in the translation server can be picked up the next time the
> BXML is processed.
>
> It also removes the possibly redundant and unwanted steps of
> retrieving this data, saving it in JSON format in a data file named
> and located according to someone else's convention, in order to be
> packaged into a jar or placed on the class path somehow.
>
> Or maybe someone simply hates JSON but loves CSV/XML/ini files? Or
> someone else loves JSON, but prefers a different naming convention?
> Yet another person hates the concept of resource *files*, but loves
> web services because they just read an article telling them that is
> what Company X does. I'm all for allowing such people the freedom to
> create and use their own implementation.
>
>>> - support for put & remove
>> I'm not sure this makes sense. AFAIK, even JDK ResourceBundles are not mutable.
> Absolutely. This is not something that the current (or any future)
> Pivot Resources class needs if other changes happen.
>
> If it were possible to create and use custom 'Resources'
> implementations, then these would be redundant. However, if there
> remains only one implementation (JSON on the classpath), then these
> could be used after loading an empty/dummy 'Resources' file. The data
> could come from anywhere, so this is a poor 'solution' for the first
> scenario. Not pretty, but would at least allow some degree of
> flexibility.
>
> Of course, as Resources is non-final, it could be extended if it's
> internal map were made visible to subclasses. That would be less
> ugly, but still not a perfect alternative.
>
> I only suggested put & remove as Resources implements Dictionary.
> After some refactoring to allow custom implementations, perhaps a
> dedicated 'Resources' interface needn't extend Dictionary at all, but
> would rather just specify the actual methods required for accessing
> the data. (ie, replace Dictionary with Iterable<String> and the
> relevant get/contains/whatever methods).
>
> Chris
Re: Some thoughts on org.apache.pivot.util.Resources / localization
Posted by Chris Bartlett <cb...@gmail.com>.
On 11 July 2011 19:48, Greg Brown <gk...@verizon.net> wrote:
>> I came out of it wondering if it is unreasonable to wish for the following ...
>> - ability to specify an arbitrary data source
>> - use of a non-JSON data format
>
> Seems reasonable, though I'd like to understand the use case better.
Flexibility, pure and simple.
All translations for a company's software might be maintained in a
central server/database with its own APIs, web services, caches etc.
This 'translation server' might maintain translations for multiple
versions of multiple applications destined for multiple clients and/or
runtime environments (development, testing, production). Perhaps
these translations can be updated/rolled back and published at any
time, with an expectation that the data will be propagated quickly and
picked up without the need to redeployment of applications.
Allowing developers to provide their own custom implementations means
they can write one which pulls this data directly from the
server/cache/whatever and populates a 'Resources' instance. Any
changes in the translation server can be picked up the next time the
BXML is processed.
It also removes the possibly redundant and unwanted steps of
retrieving this data, saving it in JSON format in a data file named
and located according to someone else's convention, in order to be
packaged into a jar or placed on the class path somehow.
Or maybe someone simply hates JSON but loves CSV/XML/ini files? Or
someone else loves JSON, but prefers a different naming convention?
Yet another person hates the concept of resource *files*, but loves
web services because they just read an article telling them that is
what Company X does. I'm all for allowing such people the freedom to
create and use their own implementation.
>> - support for put & remove
> I'm not sure this makes sense. AFAIK, even JDK ResourceBundles are not mutable.
Absolutely. This is not something that the current (or any future)
Pivot Resources class needs if other changes happen.
If it were possible to create and use custom 'Resources'
implementations, then these would be redundant. However, if there
remains only one implementation (JSON on the classpath), then these
could be used after loading an empty/dummy 'Resources' file. The data
could come from anywhere, so this is a poor 'solution' for the first
scenario. Not pretty, but would at least allow some degree of
flexibility.
Of course, as Resources is non-final, it could be extended if it's
internal map were made visible to subclasses. That would be less
ugly, but still not a perfect alternative.
I only suggested put & remove as Resources implements Dictionary.
After some refactoring to allow custom implementations, perhaps a
dedicated 'Resources' interface needn't extend Dictionary at all, but
would rather just specify the actual methods required for accessing
the data. (ie, replace Dictionary with Iterable<String> and the
relevant get/contains/whatever methods).
Chris
Re: Some thoughts on org.apache.pivot.util.Resources / localization
Posted by Greg Brown <gk...@verizon.net>.
> While playing around, I wanted to create a Resources instance and
> populate it dynamically, but realised that I couldn't and that
> Resources is not sub-class friendly.
>
> I came out of it wondering if it is unreasonable to wish for the following ...
> - ability to specify an arbitrary data source
> - use of a non-JSON data format
Seems reasonable, though I'd like to understand the use case better.
> - support for put & remove
I'm not sure this makes sense. AFAIK, even JDK ResourceBundles are not mutable.
> One more thing...
> On this tutorial page, should it be made explicit that the languages
> mentioned only apply to the demo applet on the page, and not Pivot as
> a whole? (I realise there are very few UI text strings that are not
> user specified)
I think it's pretty clear that the file applies to the tutorial example only, but feel free to attempt to clarify the text if you think it would help.
G