You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@click.apache.org by "Bob Schellink (JIRA)" <ji...@apache.org> on 2010/10/23 07:17:19 UTC
[jira] Resolved: (CLK-241) Table Headers use incorrect title
attribute (table-last-title) when sortable=true
[ https://issues.apache.org/jira/browse/CLK-241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Bob Schellink resolved CLK-241.
-------------------------------
Resolution: Fixed
Assignee: Bob Schellink (was: Malcolm Edgar)
fixed
> Table Headers use incorrect title attribute (table-last-title) when sortable=true
> ---------------------------------------------------------------------------------
>
> Key: CLK-241
> URL: https://issues.apache.org/jira/browse/CLK-241
> Project: Click
> Issue Type: Bug
> Components: core
> Environment: Click 1.4RC1
> Reporter: Patrick Talbot
> Assignee: Bob Schellink
> Priority: Minor
> Fix For: 2.3.0-M1
>
> Attachments: Column.java.patch
>
>
> In the renderTableHeader() method of the Column class, the actionLink is retrieved from getTable().getControlLink().
> This method sends back the ActionLink used for paging, but...
> The problem is that the title of this ActionLinks is already set to getMessage("table-last-title") in the renderPagingControls() method of the Table class if the banner position is TOP or BOTH, and it is not set again in the renderTableHeader() method.
> Proposed solution : at least set the title of the retrieved ActionLink to somehting meaningful in the renderTableHeader() method, like controlLink.setAttribute("title", getMessage("table-sort-links")), where the entry would resolve to "Sort by" in the click-control.properties file ("Trié par" in French).
> Easy to fix for the 1.4 release, I think.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Properties file UTF-8
Posted by Bob Schellink <sa...@gmail.com>.
Ideally we don't have to reinvent the wheel on this. Sounds as if JDK6 solves this in a clean way by
using a reader. While Click itself cannot use this mechanism yet, users could plug in a custom
MessageMap that uses the UTF-8 reader.
Bob
On 3/11/2010 03:47, Lorenzo Simionato wrote:
> If in the next release Click will have a pluggable messages Map this could resolve most
> of the problems, in fact as of now one must modify the click jar!
> If click targets java 1.5 it seems that the only solution is the self made resource bundle (given
> that the hack
> is not a very clean solution).
>
> How the situation is handled in a couple of existing framework:
> -Tapestry:
> properties file encoded in UTF-8 by default.
> They are read using an hack, see http://tinyurl.com/2g5m8zu
>
> -Wicket:
> properties file read using ResourceBundle (so ISO8859)
> Ability to use read XML based properties in UTF-8, see http://tinyurl.com/37frn4m
>
> -Grails:
> properties file encoded in UTF-8 by default
> It seems they are read using an hack, see http://www.grails.org/Internationalization
>
> --
> Lorenzo
>
> On Nov 2, 2010, at 0:58 , Bob Schellink wrote:
>
>> Hi Lorenzo,
>>
>> his has been brought up before but I can't recall if a proper solution was suggested.
>>
>> I know Java 5 introduced XML based properties, but I think key/value properties are preferred as
>> language packs. Java6 introduced more flexibility around loading bundles, but I'm not sure how that
>> works, and Click targets Java5.
>>
>> I'm not familiar with how Wicket and Tapestry solved the issue? Did they reimplement ResourceBundle?
>>
>> The next Click release will have a pluggable messages Map factory to change the default
>> implementation. Still I'd be interested to know if there is an easy way to achieve UTF-8 support.
>>
>> There is this hack[1], but hacks make me nervous.
>>
>> Kind regards
>>
>> Bob
>>
>> [1]: http://www.thoughtsabout.net/blog/archives/000044.html
>>
>
Re: Properties file UTF-8
Posted by Lorenzo Simionato <lo...@simionato.org>.
If in the next release Click will have a pluggable messages Map this could resolve most
of the problems, in fact as of now one must modify the click jar!
If click targets java 1.5 it seems that the only solution is the self made resource bundle (given that the hack
is not a very clean solution).
How the situation is handled in a couple of existing framework:
-Tapestry:
properties file encoded in UTF-8 by default.
They are read using an hack, see http://tinyurl.com/2g5m8zu
-Wicket:
properties file read using ResourceBundle (so ISO8859)
Ability to use read XML based properties in UTF-8, see http://tinyurl.com/37frn4m
-Grails:
properties file encoded in UTF-8 by default
It seems they are read using an hack, see http://www.grails.org/Internationalization
--
Lorenzo
On Nov 2, 2010, at 0:58 , Bob Schellink wrote:
> Hi Lorenzo,
>
> his has been brought up before but I can't recall if a proper solution was suggested.
>
> I know Java 5 introduced XML based properties, but I think key/value properties are preferred as
> language packs. Java6 introduced more flexibility around loading bundles, but I'm not sure how that
> works, and Click targets Java5.
>
> I'm not familiar with how Wicket and Tapestry solved the issue? Did they reimplement ResourceBundle?
>
> The next Click release will have a pluggable messages Map factory to change the default
> implementation. Still I'd be interested to know if there is an easy way to achieve UTF-8 support.
>
> There is this hack[1], but hacks make me nervous.
>
> Kind regards
>
> Bob
>
> [1]: http://www.thoughtsabout.net/blog/archives/000044.html
>
Re: Properties file UTF-8
Posted by Bob Schellink <sa...@gmail.com>.
Hi Lorenzo,
his has been brought up before but I can't recall if a proper solution was suggested.
I know Java 5 introduced XML based properties, but I think key/value properties are preferred as
language packs. Java6 introduced more flexibility around loading bundles, but I'm not sure how that
works, and Click targets Java5.
I'm not familiar with how Wicket and Tapestry solved the issue? Did they reimplement ResourceBundle?
The next Click release will have a pluggable messages Map factory to change the default
implementation. Still I'd be interested to know if there is an easy way to achieve UTF-8 support.
There is this hack[1], but hacks make me nervous.
Kind regards
Bob
[1]: http://www.thoughtsabout.net/blog/archives/000044.html
On 2/11/2010 07:44, Lorenzo Simionato wrote:
> Hi,
> I see that properties file used for i18n must be encoded in ISO-8859-1 as the standard Java class ResourceBundle is used.
> Using ISO-8859-1 is a little annoying, wouldn't be nice to use properties files encoded in UTF-8 as it is done in Tapestry or Wicket ?
>
> P.S. I would open an issue on JIRA but i'm asking here first because maybe this was already discussed.
>
> --
> Lorenzo Simionato
>
>
Properties file UTF-8
Posted by Lorenzo Simionato <lo...@simionato.org>.
Hi,
I see that properties file used for i18n must be encoded in ISO-8859-1 as the standard Java class ResourceBundle is used.
Using ISO-8859-1 is a little annoying, wouldn't be nice to use properties files encoded in UTF-8 as it is done in Tapestry or Wicket ?
P.S. I would open an issue on JIRA but i'm asking here first because maybe this was already discussed.
--
Lorenzo Simionato