Re: Formatting locale vs. translation locale
Simon Lessard wrote: I'm so divided on this issue that I think I'll call a +0 on my side. When I go on a site in English, I expect the date to be formatted accordingly. On I couldn't tell from the comment what you meant exactly. It may be obvious when you switch languages, but you may not switch languages. If I'm in the UK running in English I will expect UK date formatting, which I think means day-month-year, and not month-day-year. I think it's pretty subtle that you're actually running in en-us and not en-gb, I don't expect the user to know that. the other hand, some user are... well... hmmm... not so comfortable with computers and could completely ignore that date can even appear in more than one format. Anyway, whatever decision is taken, I agree with Martin that we'll need to indicate it clearly. So I suggested we use a config param, the default is 1, but you can 'buy in' and set it to 2. What do people think of that? Thanks, Gab Regards, ~ Simon On 10/25/06, Martin Marinschek [EMAIL PROTECTED] wrote: I believe that #1 is what we should do. If you do #2, then the locale will be changed away from what the view-root offers (and which might be derived from the accept-header of the request, so you have the possibility to implement #2) somehow automagically - without the developer really knowing. - First (that's the same issue as you had) - existing applications behave differently. - Second - also as a user, I'm expecting US-date format when I'm looking at an application I18nized in en-US. If you give me German date formats, you'll need to indicate this clearly, and that's something a developer has to do manually and consciously (except Trinidad has some automatic way of indicating date, time and number-format to the user). So as a German-speaking user, this is not the way I'd want the application to behave automatically. regards, Martin On 10/25/06, Gabrielle Crawford [EMAIL PROTECTED] wrote: Arjuna Wijeyekoon wrote: On 10/24/06, Adam Winer [EMAIL PROTECTED] wrote: On 10/24/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: I like #2 because: 1. no new public apis. Maybe I didn't explain #2: in either case, we have a new public API. There's no way to add this feature without adding a public API. The question is entirely what the behavior of that public API is. ok, I see. you will still need the RequestContext.getFormattingLocale but not the setFormattingLocale. 2. correct behaviour out-of-the-box But what is correct behavior? Is it the current JSF behavior (formatting locale is always exactly translation locale), or is it that formatting locale is always exactly the user's locale, irrespective of the translation locale. ok, I see the problem. Personally, I feel that the user's locale is always correct. But if it is in conflict with the translation locale, I am not sure what to do. Using a date field as an example, often there is a hint underneath the field indicating what the pattern is. does this hint come from a translation bundle? If so, then it would be wrong to use the user's locale instead of the translation locale. That's a very good point. If they only have US translations, the help uses US formatting, now we come along and actually use UK formatting, so the help is wrong. That does seem like a major problem for #2. Could we have a config setting to switch on #2, because I think #2 is very useful, but maybe they need to buy in, it's still a much less painful buy in than they have now with the converter 'locale' attribute Thanks, Gab 3. we won't get into a weird state where locale is english_uk, but someone programmatically sets formatting locale to english_us. That's a complete legal state; maybe unusual, but legal. It is more than unusual. It is completely wrong. If I expect my dates to be in (UK) dd-MM-, and I am actually getting (US) MM-dd-, that could cause me to miss my flight. --arjuna -- Adam --arjuna On 10/23/06, Adam Winer [EMAIL PROTECTED] wrote: Arash, ViewHandler.calculateLocale() is used to set the Locale on the UIViewRoot; so no conflicts really. They're different Locales. There's two possibilities here, though, for the default behavior: (1) RequestContext.getFormattingLocale() defaults to just returning null; so, UIViewRoot.getLocale() - and, therefore, ViewHandler.calculateLocale() - always wins, unless someone explicitly calls setFormattingLocale() for a given request. (2) The formatting locale defaults independently of ViewHandler.calculateLocale() and the supported-languages list, based on the user agent Accepts. So, for example, if you only had English as a supported language, a German user would see English text, but German-formatted dates
Re: Formatting locale vs. translation locale
It's true that en_US and en_GB can cause a problem. However this will hold true only if the language is the same. So, if we implements that maybe we can limit the valid formatting locales to those sharing the same language and only switch the country? That way it will be impossible to get in a state of German translation with fr_ca formatting. On 10/25/06, Gabrielle Crawford [EMAIL PROTECTED] wrote: Simon Lessard wrote: I'm so divided on this issue that I think I'll call a +0 on my side. When I go on a site in English, I expect the date to be formatted accordingly. On I couldn't tell from the comment what you meant exactly. It may be obvious when you switch languages, but you may not switch languages. If I'm in the UK running in English I will expect UK date formatting, which I think means day-month-year, and not month-day-year. I think it's pretty subtle that you're actually running in en-us and not en-gb, I don't expect the user to know that. the other hand, some user are... well... hmmm... not so comfortable with computers and could completely ignore that date can even appear in more than one format. Anyway, whatever decision is taken, I agree with Martin that we'll need to indicate it clearly. So I suggested we use a config param, the default is 1, but you can 'buy in' and set it to 2. What do people think of that? Thanks, Gab Regards, ~ Simon On 10/25/06, Martin Marinschek [EMAIL PROTECTED] wrote: I believe that #1 is what we should do. If you do #2, then the locale will be changed away from what the view-root offers (and which might be derived from the accept-header of the request, so you have the possibility to implement #2) somehow automagically - without the developer really knowing. - First (that's the same issue as you had) - existing applications behave differently. - Second - also as a user, I'm expecting US-date format when I'm looking at an application I18nized in en-US. If you give me German date formats, you'll need to indicate this clearly, and that's something a developer has to do manually and consciously (except Trinidad has some automatic way of indicating date, time and number-format to the user). So as a German-speaking user, this is not the way I'd want the application to behave automatically. regards, Martin On 10/25/06, Gabrielle Crawford [EMAIL PROTECTED] wrote: Arjuna Wijeyekoon wrote: On 10/24/06, Adam Winer [EMAIL PROTECTED] wrote: On 10/24/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: I like #2 because: 1. no new public apis. Maybe I didn't explain #2: in either case, we have a new public API. There's no way to add this feature without adding a public API. The question is entirely what the behavior of that public API is. ok, I see. you will still need the RequestContext.getFormattingLocale but not the setFormattingLocale. 2. correct behaviour out-of-the-box But what is correct behavior? Is it the current JSF behavior (formatting locale is always exactly translation locale), or is it that formatting locale is always exactly the user's locale, irrespective of the translation locale. ok, I see the problem. Personally, I feel that the user's locale is always correct. But if it is in conflict with the translation locale, I am not sure what to do. Using a date field as an example, often there is a hint underneath the field indicating what the pattern is. does this hint come from a translation bundle? If so, then it would be wrong to use the user's locale instead of the translation locale. That's a very good point. If they only have US translations, the help uses US formatting, now we come along and actually use UK formatting, so the help is wrong. That does seem like a major problem for #2. Could we have a config setting to switch on #2, because I think #2 is very useful, but maybe they need to buy in, it's still a much less painful buy in than they have now with the converter 'locale' attribute Thanks, Gab 3. we won't get into a weird state where locale is english_uk, but someone programmatically sets formatting locale to english_us. That's a complete legal state; maybe unusual, but legal. It is more than unusual. It is completely wrong. If I expect my dates to be in (UK) dd-MM-, and I am actually getting (US) MM-dd-, that could cause me to miss my flight. --arjuna -- Adam --arjuna On 10/23/06, Adam Winer [EMAIL PROTECTED] wrote: Arash, ViewHandler.calculateLocale() is used to set the Locale on the UIViewRoot; so no conflicts really. They're different Locales. There's two possibilities here, though, for the default behavior: (1) RequestContext.getFormattingLocale() defaults to just returning null; so,
Re: panelNavigation bug in Firefox 2.0 RC3
Hmm little follow-up. I can reproduce the issue only when tabs are placed in a panelBox (HTML table imbrication issue maybe?) Works fine in IE On 10/24/06, Simon Lessard [EMAIL PROTECTED] wrote: Even if it is a Firefox bug, we would still have to tweak the component to work, unless they fix it really fast. Considering how much IE patching we do it's not that bad. On 10/24/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote: why not report this bug to firefox developers? On 10/25/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: this same problem (of needing nbsp to display empty table cells) occurred back in the days of Netscape 4.7. It would suck if they've regressed back to that. Back then, we had to solve this by having a special ResponseWriter. The special ResponseWriter would detect if a TD was followed by a /TD with no intervening non-whitespace character, and automatically insert an NBSP for netscape. --arjuna On 10/24/06, Matt Cooper [EMAIL PROTECTED] wrote: Hi Simon, I've seen similar issues to this but not yet with Firefox 2.0. It can be a pretty annoying issue because placing text into something that didn't contain text before may alter its dimensions--even if a specific width and height are specified. When that was the case, I believe we worked around it by specifying either a line-height: 1px; style or possibly an overflow: hidden; style. If the container is larger than a character, then there is nothing to worry about. On a somewhat related note, I'm not sure the DOM structure of the tabs in the navigationPane are even in a format that is very flexible for alternative appearances. I'd be happy to see it restructured to be less reliant on tables--possibly even structured so the DOM elements actually overlap instead of having graphics to give the illusion of overlapping tabs. Thanks, Matt On 10/24/06, Simon Lessard [EMAIL PROTECTED] wrote: Hello all, There's a small bug with panelNavigation in tab mode in Firefox 2.0 (didn't check 1.5) where the tab borders are not rendered. I think it's because Firefox renders some elements only if they contain something. Since tabs structure only use some td for background image, it fails. I think I had the same problem with panelBox and I ended adding a small nbsp; I might have to check. Anyone else has experience with this or comments for the potential fix? Regards, ~ Simon -- Arash Rajaeeyan
Re: panelNavigation bug in Firefox 2.0 RC3
One last comment. The issue occurs in tableLayout as well as panelBox. The mouse down trick always works. It really looks like a table imbrication issue with Firefox. On 10/25/06, Simon Lessard [EMAIL PROTECTED] wrote: Oh yeah and if I send a mousePress event, then mouseOut before mouseUp (thus not clicking and launching the navigation) then the image show correctly... strange... On 10/25/06, Simon Lessard [EMAIL PROTECTED] wrote: Hmm little follow-up. I can reproduce the issue only when tabs are placed in a panelBox (HTML table imbrication issue maybe?) Works fine in IE On 10/24/06, Simon Lessard [EMAIL PROTECTED] wrote: Even if it is a Firefox bug, we would still have to tweak the component to work, unless they fix it really fast. Considering how much IE patching we do it's not that bad. On 10/24/06, Arash Rajaeeyan [EMAIL PROTECTED] wrote: why not report this bug to firefox developers? On 10/25/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: this same problem (of needing nbsp to display empty table cells) occurred back in the days of Netscape 4.7. It would suck if they've regressed back to that. Back then, we had to solve this by having a special ResponseWriter. The special ResponseWriter would detect if a TD was followed by a /TD with no intervening non-whitespace character, and automatically insert an NBSP for netscape. --arjuna On 10/24/06, Matt Cooper [EMAIL PROTECTED] wrote: Hi Simon, I've seen similar issues to this but not yet with Firefox 2.0. It can be a pretty annoying issue because placing text into something that didn't contain text before may alter its dimensions--even if a specific width and height are specified. When that was the case, I believe we worked around it by specifying either a line-height: 1px; style or possibly an overflow: hidden; style. If the container is larger than a character, then there is nothing to worry about. On a somewhat related note, I'm not sure the DOM structure of the tabs in the navigationPane are even in a format that is very flexible for alternative appearances. I'd be happy to see it restructured to be less reliant on tables--possibly even structured so the DOM elements actually overlap instead of having graphics to give the illusion of overlapping tabs. Thanks, Matt On 10/24/06, Simon Lessard [EMAIL PROTECTED] wrote: Hello all, There's a small bug with panelNavigation in tab mode in Firefox 2.0 (didn't check 1.5) where the tab borders are not rendered. I think it's because Firefox renders some elements only if they contain something. Since tabs structure only use some td for background image, it fails. I think I had the same problem with panelBox and I ended adding a small nbsp; I might have to check. Anyone else has experience with this or comments for the potential fix? Regards, ~ Simon -- Arash Rajaeeyan
Re: Formatting locale vs. translation locale
What's the problem with running in German with fr_ca formatting locale? Basically if you're entering dates you want to let the user enter them in the way they are used to, if the help can support it. If I'm German and go to an English page, I think I would be quite happy if I could enter the date, numbers, etc in the way I'm used to. I guess I think the reason locale was put on converters was to let users format data in the way they are used to, even if the language/country is different. Thanks, Gab Simon Lessard wrote: It's true that en_US and en_GB can cause a problem. However this will hold true only if the language is the same. So, if we implements that maybe we can limit the valid formatting locales to those sharing the same language and only switch the country? That way it will be impossible to get in a state of German translation with fr_ca formatting. On 10/25/06, Gabrielle Crawford [EMAIL PROTECTED] wrote: Simon Lessard wrote: I'm so divided on this issue that I think I'll call a +0 on my side. When I go on a site in English, I expect the date to be formatted accordingly. On I couldn't tell from the comment what you meant exactly. It may be obvious when you switch languages, but you may not switch languages. If I'm in the UK running in English I will expect UK date formatting, which I think means day-month-year, and not month-day-year. I think it's pretty subtle that you're actually running in en-us and not en-gb, I don't expect the user to know that. the other hand, some user are... well... hmmm... not so comfortable with computers and could completely ignore that date can even appear in more than one format. Anyway, whatever decision is taken, I agree with Martin that we'll need to indicate it clearly. So I suggested we use a config param, the default is 1, but you can 'buy in' and set it to 2. What do people think of that? Thanks, Gab Regards, ~ Simon On 10/25/06, Martin Marinschek [EMAIL PROTECTED] wrote: I believe that #1 is what we should do. If you do #2, then the locale will be changed away from what the view-root offers (and which might be derived from the accept-header of the request, so you have the possibility to implement #2) somehow automagically - without the developer really knowing. - First (that's the same issue as you had) - existing applications behave differently. - Second - also as a user, I'm expecting US-date format when I'm looking at an application I18nized in en-US. If you give me German date formats, you'll need to indicate this clearly, and that's something a developer has to do manually and consciously (except Trinidad has some automatic way of indicating date, time and number-format to the user). So as a German-speaking user, this is not the way I'd want the application to behave automatically. regards, Martin On 10/25/06, Gabrielle Crawford [EMAIL PROTECTED] wrote: Arjuna Wijeyekoon wrote: On 10/24/06, Adam Winer [EMAIL PROTECTED] wrote: On 10/24/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: I like #2 because: 1. no new public apis. Maybe I didn't explain #2: in either case, we have a new public API. There's no way to add this feature without adding a public API. The question is entirely what the behavior of that public API is. ok, I see. you will still need the RequestContext.getFormattingLocale but not the setFormattingLocale. 2. correct behaviour out-of-the-box But what is correct behavior? Is it the current JSF behavior (formatting locale is always exactly translation locale), or is it that formatting locale is always exactly the user's locale, irrespective of the translation locale. ok, I see the problem. Personally, I feel that the user's locale is always correct. But if it is in conflict with the translation locale, I am not sure what to do. Using a date field as an example, often there is a hint underneath the field indicating what the pattern is. does this hint come from a translation bundle? If so, then it would be wrong to use the user's locale instead of the translation locale. That's a very good point. If they only have US translations, the help uses US formatting, now we come along and actually use UK formatting, so the help is wrong. That does seem like a major problem for #2. Could we have a config setting to switch on #2, because I think #2 is very useful, but maybe they need to buy in, it's still a much less painful buy in than they have now with the converter 'locale' attribute Thanks, Gab 3. we won't get into a weird state where locale is english_uk, but someone programmatically sets formatting locale to english_us. That's a complete legal state; maybe unusual, but legal. It is more than unusual. It is completely wrong. If I expect my dates to be
Re: Formatting locale vs. translation locale
Yes, and no... It depends on your users really. When I buy something from USA I know how to enter the date because I'm used to it, all other sites work that way. If the site was somehow intelligent enough to see that I'm French Canadian and to switch its date format accordingly, I would be quite lost if the application was not giving any clue about the format used. However, new Internet users will probably find it nice because they won't be used to usual behavior. My 2ยข, ~ Simon On 10/25/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Right! I am able to read english content, but I have no idea how english speaking guys enter their dates. Or more true, I don't care. In a *corperate* application, I am fine w/ reading english content, but want my German date format :) -M On 10/25/06, Gabrielle Crawford [EMAIL PROTECTED] wrote: What's the problem with running in German with fr_ca formatting locale? Basically if you're entering dates you want to let the user enter them in the way they are used to, if the help can support it. If I'm German and go to an English page, I think I would be quite happy if I could enter the date, numbers, etc in the way I'm used to. I guess I think the reason locale was put on converters was to let users format data in the way they are used to, even if the language/country is different. Thanks, Gab Simon Lessard wrote: It's true that en_US and en_GB can cause a problem. However this will hold true only if the language is the same. So, if we implements that maybe we can limit the valid formatting locales to those sharing the same language and only switch the country? That way it will be impossible to get in a state of German translation with fr_ca formatting. On 10/25/06, Gabrielle Crawford [EMAIL PROTECTED] wrote: Simon Lessard wrote: I'm so divided on this issue that I think I'll call a +0 on my side. When I go on a site in English, I expect the date to be formatted accordingly. On I couldn't tell from the comment what you meant exactly. It may be obvious when you switch languages, but you may not switch languages. If I'm in the UK running in English I will expect UK date formatting, which I think means day-month-year, and not month-day-year. I think it's pretty subtle that you're actually running in en-us and not en-gb, I don't expect the user to know that. the other hand, some user are... well... hmmm... not so comfortable with computers and could completely ignore that date can even appear in more than one format. Anyway, whatever decision is taken, I agree with Martin that we'll need to indicate it clearly. So I suggested we use a config param, the default is 1, but you can 'buy in' and set it to 2. What do people think of that? Thanks, Gab Regards, ~ Simon On 10/25/06, Martin Marinschek [EMAIL PROTECTED] wrote: I believe that #1 is what we should do. If you do #2, then the locale will be changed away from what the view-root offers (and which might be derived from the accept-header of the request, so you have the possibility to implement #2) somehow automagically - without the developer really knowing. - First (that's the same issue as you had) - existing applications behave differently. - Second - also as a user, I'm expecting US-date format when I'm looking at an application I18nized in en-US. If you give me German date formats, you'll need to indicate this clearly, and that's something a developer has to do manually and consciously (except Trinidad has some automatic way of indicating date, time and number-format to the user). So as a German-speaking user, this is not the way I'd want the application to behave automatically. regards, Martin On 10/25/06, Gabrielle Crawford [EMAIL PROTECTED] wrote: Arjuna Wijeyekoon wrote: On 10/24/06, Adam Winer [EMAIL PROTECTED] wrote: On 10/24/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: I like #2 because: 1. no new public apis. Maybe I didn't explain #2: in either case, we have a new public API. There's no way to add this feature without adding a public API. The question is entirely what the behavior of that public API is. ok, I see. you will still need the RequestContext.getFormattingLocale but not the setFormattingLocale. 2. correct behaviour out-of-the-box But what is correct behavior? Is it the current JSF behavior (formatting locale is always exactly translation locale), or is it that formatting locale is always exactly the user's locale, irrespective of the translation locale. ok, I see the problem. Personally, I feel that the user's locale is always correct. But if it is in conflict with the translation locale, I am not sure what to
Re: Re: Re: Re: Formatting locale vs. translation locale
On 10/24/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: On 10/24/06, Adam Winer [EMAIL PROTECTED] wrote: On 10/24/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: I like #2 because: 1. no new public apis. Maybe I didn't explain #2: in either case, we have a new public API. There's no way to add this feature without adding a public API. The question is entirely what the behavior of that public API is. ok, I see. you will still need the RequestContext.getFormattingLocale but not the setFormattingLocale. Not sure I follow. There's no way we can get away with having only one behavior here; we need to support both the original JSF behavior and this new customized behavior, per webapp developer decision. So, getFormattingLocale() has to be customizable. The two logical APIs here are: - setFormattingLocale() - EL: like readingDirection, use trinidad-config to set up EL that drives the formatting locale 2. correct behaviour out-of-the-box But what is correct behavior? Is it the current JSF behavior (formatting locale is always exactly translation locale), or is it that formatting locale is always exactly the user's locale, irrespective of the translation locale. ok, I see the problem. Personally, I feel that the user's locale is always correct. But if it is in conflict with the translation locale, I am not sure what to do. Using a date field as an example, often there is a hint underneath the field indicating what the pattern is. does this hint come from a translation bundle? If so, then it would be wrong to use the user's locale instead of the translation locale. Hints will have to be clever, that's true. Not sure I have a good solution for this. 3. we won't get into a weird state where locale is english_uk, but someone programmatically sets formatting locale to english_us. That's a complete legal state; maybe unusual, but legal. It is more than unusual. It is completely wrong. If I expect my dates to be in (UK) dd-MM-, and I am actually getting (US) MM-dd-, that could cause me to miss my flight. No, not the point of this: locale is en_UK, but formatting locale is en_US could mean an English website is showing dates to an American user. Unusual, not not illegal. Obviously, showing the wrong formats is a problem, or we wouldn't be having this discussion! I don't need to be reminded of that. :) -- Adam
Re: [PORTAL] Custom lifecycle?
You know you can do that all in one phase listener, right? It's really not much code at all to implement an algorithm like this. Yes, but even the code in 10.1.3.2 which doesn't take phases into account is somewhat scary. :) Adding logic to figure out what phase is next is a lot more scary. And as you said, in 1.1, there is no guarantee that the endPhaseListener gets called. Hrm, I'm confused - I thought you were talking about implementing a custom Lifecycle object. Do you mean a custom Lifecycle, or just a custom Filter? A Filter + a PhaseListener is fine. It's just implementing Lifecycle itself that is a bit scary. I'm trying to eliminate the filter all together. I can put code in the bridge which calls a particular listener before/after the execute and render methods are executed in the bridge, or I can make a custom lifecycle which requires NO changes to the bridge and executes the initialization code at the beginning and end of the lifecycle itself. The object itself wouldn't be too scary as it would do it's initialization and then deligate to the underlying lifecycle object. Code wise, it allows us to take advantage of the JSF ExternalContext abstractions much easier and eliminates the need for special handling of the Portal usecases. -- Adam Scott Adam Winer wrote: On 10/20/06, Scott O'Bryan [EMAIL PROTECTED] wrote: My question is this, is there any reason we can't provide our own custom lifecycle object that decorates the default one and allows us to run our initialization code on the execute and render? If so, the code to manage things like the TrinidadFacesContext becomes a LOT easier and we can rely on some of the stuff already build in to the Bridge Portlets. What's the advantage of a custom lifecycle over using a phase listener? --Adam
new validator: dateRestrictionValidator
Hi, I'd like to add a new validator. My proposed name is DateRestrictionValidator, other suggestions welcome. This would support attributes like: invalidMonths - example: dates in April are invalid invalidDaysOfWeek - example: Saturdays and Sundays are invalid invalidDays - example: 12-25-06 and 1-1-07 are invalid The exact api's will be discussed further as the implemenation is worked out. Does anyone oppose this or can I open an issue? Thanks, Gabrielle
Re: new validator: dateRestrictionValidator
That would be a great improvement to all the inputDate / calendar (Tomahawk) components. I am also fine w/ the name. Opening an issue in jira does never hurt, when discussing an enhancement. :) -M On 10/25/06, Gabrielle Crawford [EMAIL PROTECTED] wrote: Hi, I'd like to add a new validator. My proposed name is DateRestrictionValidator, other suggestions welcome. This would support attributes like: invalidMonths - example: dates in April are invalid invalidDaysOfWeek - example: Saturdays and Sundays are invalid invalidDays - example: 12-25-06 and 1-1-07 are invalid The exact api's will be discussed further as the implemenation is worked out. Does anyone oppose this or can I open an issue? Thanks, Gabrielle -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: new validator: dateRestrictionValidator
I would love it. On 10/25/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: That would be a great improvement to all the inputDate / calendar (Tomahawk) components. I am also fine w/ the name. Opening an issue in jira does never hurt, when discussing an enhancement. :) -M On 10/25/06, Gabrielle Crawford [EMAIL PROTECTED] wrote: Hi, I'd like to add a new validator. My proposed name is DateRestrictionValidator, other suggestions welcome. This would support attributes like: invalidMonths - example: dates in April are invalid invalidDaysOfWeek - example: Saturdays and Sundays are invalid invalidDays - example: 12-25-06 and 1-1-07 are invalid The exact api's will be discussed further as the implemenation is worked out. Does anyone oppose this or can I open an issue? Thanks, Gabrielle -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: new validator: dateRestrictionValidator
Thanks Matthias. Okay, this is issue 258 https://issues.apache.org/jira/browse/ADFFACES-258 Thanks, Gab Matthias Wessendorf wrote: That would be a great improvement to all the inputDate / calendar (Tomahawk) components. I am also fine w/ the name. Opening an issue in jira does never hurt, when discussing an enhancement. :) -M On 10/25/06, Gabrielle Crawford [EMAIL PROTECTED] wrote: Hi, I'd like to add a new validator. My proposed name is DateRestrictionValidator, other suggestions welcome. This would support attributes like: invalidMonths - example: dates in April are invalid invalidDaysOfWeek - example: Saturdays and Sundays are invalid invalidDays - example: 12-25-06 and 1-1-07 are invalid The exact api's will be discussed further as the implemenation is worked out. Does anyone oppose this or can I open an issue? Thanks, Gabrielle
Re: api cleanup for UIXCollection
+1 for me - I've always found the word currency to be incredibly confusing. -- Adam On 10/24/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: Hi, Currently UIXCollection has the following methods: public String getCurrencyString() public void setCurrencyString(String currency) protected void clearCurrencyStringCache() Now that issue 210 (http://issues.apache.org/jira/browse/ADFFACES-210) has been implemented and we have a ClientRowKeyManager class that handles the object-rowkey-string-key mapping, I'd like to propose the following changes: 1. rename get/setCurrentString to get/setClientRowKey 2. remove the clearCurrencyStringCache method (ie: make it package-private). what do you think? If we do decide to implement these changes, I'd like to do them in two parts: 1. first add the new methods and deprecate the old ones. 2. give a few days for dependent projects to upgrade and then remove the old deprecated methods. is that ok? thanks Arjuna
Re: make ValueMap public
I guess both are useful; but what is the underlying storage? If it's a HashMap, then this should be called something like ReverseHashMap. (Or ReversibleHashMap?) -- Adam On 10/24/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: Hi, I'd like to make org.apache.myfaces.trinidad.component.ValueMap a public utility class. This class maintains a mapping from key to value, and also from value to key. It is useful to create ClientRowKeyManager implementations (See http://issues.apache.org/jira/browse/ADFFACES-210). I'd like to call it org.apache.myfaces.trinidad.util.ReverseMap And I will cleanup the api so that the Map interface is fully implemented (along with the remove operations). What do you think about making this class public? ?? If we do make this public, which of the following apis is better? ReverseMapK,V map; V value; K key = map.getKey(value);// option 1 or MapV,K valuemap = map.getReverseMap(); // option 2 K Key = valuemap.get(value); ??? or should we have both? --arjuna
Re: api cleanup for UIXCollection
+1 as well, when I first saw that method I thought about money. On 10/25/06, Adam Winer [EMAIL PROTECTED] wrote: +1 for me - I've always found the word currency to be incredibly confusing. -- Adam On 10/24/06, Arjuna Wijeyekoon [EMAIL PROTECTED] wrote: Hi, Currently UIXCollection has the following methods: public String getCurrencyString() public void setCurrencyString(String currency) protected void clearCurrencyStringCache() Now that issue 210 (http://issues.apache.org/jira/browse/ADFFACES-210) has been implemented and we have a ClientRowKeyManager class that handles the object-rowkey-string-key mapping, I'd like to propose the following changes: 1. rename get/setCurrentString to get/setClientRowKey 2. remove the clearCurrencyStringCache method (ie: make it package-private). what do you think? If we do decide to implement these changes, I'd like to do them in two parts: 1. first add the new methods and deprecate the old ones. 2. give a few days for dependent projects to upgrade and then remove the old deprecated methods. is that ok? thanks Arjuna
Re: Re: Re: making IntegerUtils part of API ?
mmm, not really. the util package for instance has StreamUtils, ComponentUtils oder LocaleUtils. But nothing related to numbers... Anyone else know a better place? Otherwise, I move the IntegerUtils up. -M On 10/18/06, Adam Winer [EMAIL PROTECTED] wrote: Definitely +1 to removing getInteger(). Is there anywhere better in the API to move the IntegerUtils methods other than having a bonus class? -- Adam On 10/18/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: so, should I remove that one and *refactor* the calls ? so I can make it public, since getString is useful On 10/18/06, Adam Winer [EMAIL PROTECTED] wrote: Oops, I meant getString(int) and getString(long). Those are useful. It's getInteger() that is not useful anymore. -- Adam On 10/18/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: toString() ? no in there. I use getString(long) for my stuff. -M On 10/17/06, Adam Winer [EMAIL PROTECTED] wrote: I'm partly -1 on this. We should just be using autoboxing for int - Integer, which is required to already cache the same object for integers from -128 to 127 inclusive. The part of IntegerUtils that is still useful is the cache of toString()'d versions of the integers, but I'm not sure how widely used that is. One thing is for sure - we should do a pass for any instances of Bali (an old Oracle code name) to clean that up. -- Adam On 10/17/06, Jeanne Waldman [EMAIL PROTECTED] wrote: +1 Matthias Wessendorf wrote: +1 On 10/17/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hey, any one care to make IntegerUtils from trinidad-impl part of the public API? I like to use it in the api, when working on the validator/converter *overhaul* issue(s). the javadoc says: Class containing various integer utilities. It caches commonly used Integer objects and String representations of Integers to avoid expensive object creations. (and also...) IntegerUtils is used throughout most Bali projects, and clients are also encouraged to use it for increased performance. :-) Thanks, Matthias -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: new validator: dateRestrictionValidator
Great idea! regards, Martin On 10/25/06, Gabrielle Crawford [EMAIL PROTECTED] wrote: Thanks Matthias. Okay, this is issue 258 https://issues.apache.org/jira/browse/ADFFACES-258 Thanks, Gab Matthias Wessendorf wrote: That would be a great improvement to all the inputDate / calendar (Tomahawk) components. I am also fine w/ the name. Opening an issue in jira does never hurt, when discussing an enhancement. :) -M On 10/25/06, Gabrielle Crawford [EMAIL PROTECTED] wrote: Hi, I'd like to add a new validator. My proposed name is DateRestrictionValidator, other suggestions welcome. This would support attributes like: invalidMonths - example: dates in April are invalid invalidDaysOfWeek - example: Saturdays and Sundays are invalid invalidDays - example: 12-25-06 and 1-1-07 are invalid The exact api's will be discussed further as the implemenation is worked out. Does anyone oppose this or can I open an issue? Thanks, Gabrielle -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: new validator: dateRestrictionValidator
I bet! On 10/25/06, Martin Marinschek [EMAIL PROTECTED] wrote: P.S.: will it be client-side enabled as well? regards, Martin On 10/26/06, Martin Marinschek [EMAIL PROTECTED] wrote: Great idea! regards, Martin On 10/25/06, Gabrielle Crawford [EMAIL PROTECTED] wrote: Thanks Matthias. Okay, this is issue 258 https://issues.apache.org/jira/browse/ADFFACES-258 Thanks, Gab Matthias Wessendorf wrote: That would be a great improvement to all the inputDate / calendar (Tomahawk) components. I am also fine w/ the name. Opening an issue in jira does never hurt, when discussing an enhancement. :) -M On 10/25/06, Gabrielle Crawford [EMAIL PROTECTED] wrote: Hi, I'd like to add a new validator. My proposed name is DateRestrictionValidator, other suggestions welcome. This would support attributes like: invalidMonths - example: dates in April are invalid invalidDaysOfWeek - example: Saturdays and Sundays are invalid invalidDays - example: 12-25-06 and 1-1-07 are invalid The exact api's will be discussed further as the implemenation is worked out. Does anyone oppose this or can I open an issue? Thanks, Gabrielle -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
