RESULT (was Re: [Vote] release for Trinidad Plugins 1.2.6)

[Leonardo Uribe]

Hi,

thanks for voting.

We got 5 +1
Matthias Wessendorf
Bernd Bohmann
Martin Marinschek
Bruno Aranda
Grant Smith

So the release will start now

Tomahawk 1.2 Roadmap

[Cagatay Civici]

Hi,

Recently I've discussed tomahawk 1.2 with Bruno.

For now we thought it's better to make a branch based on 1.2 and do a quick
release and after that for 1.2.x, switch the build to autogeneration with
faces-plugin.

Since the main goal is tomahawk 1.2, autogeneration could wait a little bit.

If this is ok for everyone, I'll create a branch for 1.2 and try to make it
build against 1.2 dependencies.

Cagatay

[jira] Resolved: (TRINIDAD-879) NLS: Translation to always honor view locale not formatting locale

[Jeanne Waldman (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TRINIDAD-879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeanne Waldman resolved TRINIDAD-879.
-

Resolution: Fixed

> NLS: Translation to always honor view locale not formatting locale
> --
>
> Key: TRINIDAD-879
> URL: https://issues.apache.org/jira/browse/TRINIDAD-879
> Project: MyFaces Trinidad
>  Issue Type: Bug
>Reporter: Jeanne Waldman
>Assignee: Jeanne Waldman
>
> Trinidad embedded translations should always honor "view locale".
> Problem:
> 1. Usually Trinidad embedded translations are honoring "view
> locale"
> 2. However, when "formatting locale" is specified, translations will be
> following formatting locale instead.
> In theory, only localization definitions (such as date format
> pattern) should follow formatting locale.
> Here's a testcase.  The idea is:
> - we would like to have formatting support according to locale "Traditional
> Chinese-Hong Kong" (zh-HK).
> - However, language translations in Traditional Chinese (zh-TW) due
> to that fact that we do not provide zh-HK translations.
> facestring.jspx
> ===
> 
> http://java.sun.com/JSP/Page"; version="2.0"
>   xmlns:f="http://java.sun.com/jsf/core";
>   xmlns:tr="http://myfaces.apache.org/trinidad"; >
>   
>   
>  
>  
>   
> 
>   
>   
> 
>   
>   
> 
>  
>   
> 
> faces-config.xml
> 
> ...
>   zh-TW
>   zh-HK
> trinidad-config.xml
> ===
> 
> 
>   
>   zh-HK
> 
> Problem:
> While formatting is presented in zh-HK, language translations are not shown
> in Traditional Chinese.
> Valid example: 98ChineseChar11ChineseChar29ChineseChar
> As a Reference Testcase:
> Remove formatting-locale in trinidad-config.xml  (i.e. only view locale =
> zh-tw below)
> Traditional Chinese translations present and shown correctly.
> ChineseChars "23245" ChineseChars. ChineseChars: "1998/11/29".
> While Trinidad supports more than 130 locales in terms of
> localization formatting (there are 132 files of
> META-INF/adf/jsLibs/resources/LocaleElements_*.js),
> - there are only 32 languages provided for translations (there are 33 files
> of oracle/adfinternal/view/faces/renderkit/rich/resource/RichBundle_*.class)
> A fallback approach will be often required for appropriate i18n support.  For
> example:
>   locale formatting  language translations
>   =  =
>   zh-HK  zh-TW
>   zh-SG  zh-CN
>   zh-MO  zh-TW
>   etc.
> This bug and analysis was found by our NLS expert.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (TRINIDAD-879) NLS: Translation to always honor view locale not formatting locale

[Jeanne Waldman (JIRA)]

[ 
https://issues.apache.org/jira/browse/TRINIDAD-879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12554008
 ] 

Jeanne Waldman commented on TRINIDAD-879:
-

 TRINIDAD-879  NLS: Translation to always honor view locale not formatting 
locale
The fix is to not use the locale that is in the LocaleElements*.js file name 
for the
translation strings for this file. Instead, send a request parameter to the 
server
with the translation locale.
- add a new method protected String getExtraParameters to LibraryScriptlet and 
LocaleInfoScriptlet.java
- in LocaleInfoScriptlet.java, the getExtraParameters set "loc" to
arc.getLocaleContext().getTranslationLocale().toString();
- remove  protected String getLocaleString(FacesContext context) from 
TrTranslationsResourceLoader.java so that instead the superclass's method is 
called, which looks at the "loc" parameter for the locale
to use when getting the message bundle.

committed to trunk.1.2.x
Completed: At revision: 606282  

committed to trunk
Completed: At revision: 606285  




> NLS: Translation to always honor view locale not formatting locale
> --
>
> Key: TRINIDAD-879
> URL: https://issues.apache.org/jira/browse/TRINIDAD-879
> Project: MyFaces Trinidad
>  Issue Type: Bug
>Reporter: Jeanne Waldman
>Assignee: Jeanne Waldman
>
> Trinidad embedded translations should always honor "view locale".
> Problem:
> 1. Usually Trinidad embedded translations are honoring "view
> locale"
> 2. However, when "formatting locale" is specified, translations will be
> following formatting locale instead.
> In theory, only localization definitions (such as date format
> pattern) should follow formatting locale.
> Here's a testcase.  The idea is:
> - we would like to have formatting support according to locale "Traditional
> Chinese-Hong Kong" (zh-HK).
> - However, language translations in Traditional Chinese (zh-TW) due
> to that fact that we do not provide zh-HK translations.
> facestring.jspx
> ===
> 
> http://java.sun.com/JSP/Page"; version="2.0"
>   xmlns:f="http://java.sun.com/jsf/core";
>   xmlns:tr="http://myfaces.apache.org/trinidad"; >
>   
>   
>  
>  
>   
> 
>   
>   
> 
>   
>   
> 
>  
>   
> 
> faces-config.xml
> 
> ...
>   zh-TW
>   zh-HK
> trinidad-config.xml
> ===
> 
> 
>   
>   zh-HK
> 
> Problem:
> While formatting is presented in zh-HK, language translations are not shown
> in Traditional Chinese.
> Valid example: 98ChineseChar11ChineseChar29ChineseChar
> As a Reference Testcase:
> Remove formatting-locale in trinidad-config.xml  (i.e. only view locale =
> zh-tw below)
> Traditional Chinese translations present and shown correctly.
> ChineseChars "23245" ChineseChars. ChineseChars: "1998/11/29".
> While Trinidad supports more than 130 locales in terms of
> localization formatting (there are 132 files of
> META-INF/adf/jsLibs/resources/LocaleElements_*.js),
> - there are only 32 languages provided for translations (there are 33 files
> of oracle/adfinternal/view/faces/renderkit/rich/resource/RichBundle_*.class)
> A fallback approach will be often required for appropriate i18n support.  For
> example:
>   locale formatting  language translations
>   =  =
>   zh-HK  zh-TW
>   zh-SG  zh-CN
>   zh-MO  zh-TW
>   etc.
> This bug and analysis was found by our NLS expert.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [Trinidad] NLS bug re: formatting locale

[Jeanne Waldman]

I'm going to check my fix in today. I can back it out if anyone has any 
objections, which I don't foresee.

thanks!
Jeanne

Jeanne Waldman wrote:

Hi there,
Our local NLS expert brought this bug to my attention. I created a JIRA 
issue https://issues.apache.org/jira/browse/TRINIDAD-879


Here is what I have there. Let me know if you think that this is not a 
bug. I plan to fix it.

Thanks!
Jeanne

Trinidad embedded translations should always honor "view locale".

Problem:
1. Usually Trinidad embedded translations are honoring "view
locale"
2. However, when "formatting locale" is specified, translations will be
following formatting locale instead.

In theory, only localization definitions (such as date format
pattern) should follow formatting locale.

Here's a testcase. The idea is:
- we would like to have formatting support according to locale "Traditional
Chinese-Hong Kong" (zh-HK).
- However, language translations in Traditional Chinese (zh-TW) due
to that fact that we do not provide zh-HK translations.

facestring.jspx
===

http://java.sun.com/JSP/Page"; version="2.0"
  xmlns:f="http://java.sun.com/jsf/core";
  xmlns:tr="http://myfaces.apache.org/trinidad"; >
  
  
 

  

  
  

  
  

 
  


faces-config.xml

...
  zh-TW
  zh-HK

trinidad-config.xml
===



  zh-HK


Problem:
While formatting is presented in zh-HK, language translations are not shown
in Traditional Chinese.
Valid example: 98ChineseChar11ChineseChar29ChineseChar
As a Reference Testcase:

Remove formatting-locale in trinidad-config.xml (i.e. only view locale =
zh-tw below)
Traditional Chinese translations present and shown correctly.
ChineseChars "23245" ChineseChars. ChineseChars: "1998/11/29".

While Trinidad supports more than 130 locales in terms of
localization formatting (there are 132 files of
META-INF/adf/jsLibs/resources/LocaleElements_*.js),
- there are only 32 languages provided for translations (there are 33 files
of 
oracle/adfinternal/view/faces/renderkit/rich/resource/RichBundle_*.class)


A fallback approach will be often required for appropriate i18n support. 
For

example:

  locale formatting language translations
  = =
  zh-HK zh-TW
  zh-SG zh-CN
  zh-MO zh-TW
  etc.

Re: [Build-Tools] java packages

[Andrew Robinson]

+0.5 on maven

I am a bit indifferent, but I think that a package should be version
agnostic, and only be used for area of functionality. The JAR should
be version specific.

Don't you think that it would be invalid to import maven1 and maven2
jars at the same time?

So I would see as the package:
org.apache.myfaces.buildtools.maven

And the release as something like:
apache-myfaces-maven1-1.x.x with dependency on maven 1 and
apache-myfaces-maven2-1.x.x with dependency on maven 2 and
apache-myfaces-maven3-1.x.x with dependency on maven 3.

So the artifact ID would have the maven version somewhere in it.

-Andrew

On Dec 21, 2007 6:48 AM, Manfred Geiler <[EMAIL PROTECTED]> wrote:
> maven2 is ok I think
>
> at least it makes sure we have a namespace for incompatible maven3
> plugins in the future...  ;-)
>
> --Manfred
>
>
>
> On 12/21/07, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > should we always start with this package ?
> >
> > org.apache.myfaces.buildtools.maven2
> >
> > or
> >
> > org.apache.myfaces.buildtools.maven
> >
> > than
> >
> > -plugin.wagon
> > -plugin.jdev
> > -plugin.faces
> > -plugin.javascript
> >
> > that would be similar to the maven-plugins, provided by the maven-folks;
> >
> > not really sure on maven vs maven2
> >
> > thx!
> > Matthias
> >
> > --
> > Matthias Wessendorf
> >
> > further stuff:
> > blog: http://matthiaswessendorf.wordpress.com/
> > sessions: http://www.slideshare.net/mwessendorf
> > mail: matzew-at-apache-dot-org
> >
>
>
> --
> http://www.irian.at
> Your JSF powerhouse - JSF Consulting,
> Development and Courses in English and
> German
>
> Professional Support for Apache MyFaces
>

Re: Question on ValueExpression, with an empty ExpressionString (Jetty vs Tomcat)

[Matthias Wessendorf]

in case of jsf11;
value="" ==> null as well, not valueBinding-object

-M

On Dec 21, 2007 2:53 PM, Manfred Geiler <[EMAIL PROTECTED]> wrote:
> My personal feeling is that getValueExpression should NOT return null
> if explictly called with an empty String.
> However, this is something for the Unified EL (ie. JSP) specification.
> If this behaviour is unclear from the spec, it should be explicitly
> defined there.
>
> --Manfred
>
>
>
> On 12/21/07, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
> > Inside of Trinidad's EditableValueRenderer
> > (org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.EditableValueRenderer)
> >
> > there getReadOnly(...), which is called by all inputXyz Renderers to
> > check if the component should be rendered "readOnly" or not
> > That method checks if the component is readOnly AND it also checks if
> > the underlying EL is readOnly.
> >
> > If that method returns TRUE, the component is readOnly (and there for
> > a inputText isn't editable)...makes sense, so far...
> >
> > Here is a "use-case"
> >
> > 
> > (yes, may be stupid, but can happen...)
> >
> > Since the getReadOnly() checks if the EL is readOnly... it does this as 
> > well:
> >
> > ValueExpression ve = getValueExpression(bean);
> >
> >
> > In Jetty (jetty-6.1.2rc2), which uses Sun/Glassfish/RI EL
> > (com.sun.el.ValueExpressionImpl)
> > ==>
> > It returns an object that is readOnly (which is correct) and the
> > getExpressionString is "" (empty).
> >
> > In tomcat 6. which uses this EL-Impl
> > "org.apache.jasper.el.JspValueExpression", it returns NULL
> >
> >
> > Now, I wonder what the correct EL behavior is.
> > I tend to think, that Tomcat is right, because there is no
> > ExpressionString, so not a "real" Expression,
> > but others could have a different understanding of it.
> >
> > What is your take on that ?
> >
> > --
> > Matthias Wessendorf
> >
> > further stuff:
> > blog: http://matthiaswessendorf.wordpress.com/
> > sessions: http://www.slideshare.net/mwessendorf
> > mail: matzew-at-apache-dot-org
> >
>
>
> --
> http://www.irian.at
> Your JSF powerhouse - JSF Consulting,
> Development and Courses in English and
> German
>
> Professional Support for Apache MyFaces
>



-- 
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

Re: [Build-Tools] java packages

[Manfred Geiler]

maven2 is ok I think

at least it makes sure we have a namespace for incompatible maven3
plugins in the future...  ;-)

--Manfred


On 12/21/07, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
> Hi,
>
> should we always start with this package ?
>
> org.apache.myfaces.buildtools.maven2
>
> or
>
> org.apache.myfaces.buildtools.maven
>
> than
>
> -plugin.wagon
> -plugin.jdev
> -plugin.faces
> -plugin.javascript
>
> that would be similar to the maven-plugins, provided by the maven-folks;
>
> not really sure on maven vs maven2
>
> thx!
> Matthias
>
> --
> Matthias Wessendorf
>
> further stuff:
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> mail: matzew-at-apache-dot-org
>


-- 
http://www.irian.at
Your JSF powerhouse - JSF Consulting,
Development and Courses in English and
German

Professional Support for Apache MyFaces

Re: Question on ValueExpression, with an empty ExpressionString (Jetty vs Tomcat)

[Manfred Geiler]

My personal feeling is that getValueExpression should NOT return null
if explictly called with an empty String.
However, this is something for the Unified EL (ie. JSP) specification.
If this behaviour is unclear from the spec, it should be explicitly
defined there.

--Manfred


On 12/21/07, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
> Inside of Trinidad's EditableValueRenderer
> (org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.EditableValueRenderer)
>
> there getReadOnly(...), which is called by all inputXyz Renderers to
> check if the component should be rendered "readOnly" or not
> That method checks if the component is readOnly AND it also checks if
> the underlying EL is readOnly.
>
> If that method returns TRUE, the component is readOnly (and there for
> a inputText isn't editable)...makes sense, so far...
>
> Here is a "use-case"
>
> 
> (yes, may be stupid, but can happen...)
>
> Since the getReadOnly() checks if the EL is readOnly... it does this as well:
>
> ValueExpression ve = getValueExpression(bean);
>
>
> In Jetty (jetty-6.1.2rc2), which uses Sun/Glassfish/RI EL
> (com.sun.el.ValueExpressionImpl)
> ==>
> It returns an object that is readOnly (which is correct) and the
> getExpressionString is "" (empty).
>
> In tomcat 6. which uses this EL-Impl
> "org.apache.jasper.el.JspValueExpression", it returns NULL
>
>
> Now, I wonder what the correct EL behavior is.
> I tend to think, that Tomcat is right, because there is no
> ExpressionString, so not a "real" Expression,
> but others could have a different understanding of it.
>
> What is your take on that ?
>
> --
> Matthias Wessendorf
>
> further stuff:
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> mail: matzew-at-apache-dot-org
>


-- 
http://www.irian.at
Your JSF powerhouse - JSF Consulting,
Development and Courses in English and
German

Professional Support for Apache MyFaces

[Build-Tools] Wagon plugin

[Matthias Wessendorf]

Hey Börnd,

the wagon plugin has

/**
 * @parameter expression="${project}"
 * @required
 * @readonly
 */
private MavenProject project;


but "project" isn't used in the code.

-M

-- 
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

[Build-Tools] java packages

[Matthias Wessendorf]

Hi,

should we always start with this package ?

org.apache.myfaces.buildtools.maven2

or

org.apache.myfaces.buildtools.maven

than

-plugin.wagon
-plugin.jdev
-plugin.faces
-plugin.javascript

that would be similar to the maven-plugins, provided by the maven-folks;

not really sure on maven vs maven2

thx!
Matthias

-- 
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

[jira] Created: (TOBAGO-581) Sheet component with paging on demand

[Ricardo S. Tanaka (JIRA)]

Sheet component with paging on demand
-

 Key: TOBAGO-581
 URL: https://issues.apache.org/jira/browse/TOBAGO-581
 Project: MyFaces Tobago
  Issue Type: Improvement
  Components: Core
 Environment: All
Reporter: Ricardo S. Tanaka


Create a sheet with pagin on demand, eg.: when click on determining page or on 
next page, call an action to populate the sheet again to avoid load all data on 
session.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Question on ValueExpression, with an empty ExpressionString (Jetty vs Tomcat)

[Matthias Wessendorf]

Inside of Trinidad's EditableValueRenderer
(org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.EditableValueRenderer)

there getReadOnly(...), which is called by all inputXyz Renderers to
check if the component should be rendered "readOnly" or not
That method checks if the component is readOnly AND it also checks if
the underlying EL is readOnly.

If that method returns TRUE, the component is readOnly (and there for
a inputText isn't editable)...makes sense, so far...

Here is a "use-case"


(yes, may be stupid, but can happen...)

Since the getReadOnly() checks if the EL is readOnly... it does this as well:

ValueExpression ve = getValueExpression(bean);


In Jetty (jetty-6.1.2rc2), which uses Sun/Glassfish/RI EL
(com.sun.el.ValueExpressionImpl)
==>
It returns an object that is readOnly (which is correct) and the
getExpressionString is "" (empty).

In tomcat 6. which uses this EL-Impl
"org.apache.jasper.el.JspValueExpression", it returns NULL


Now, I wonder what the correct EL behavior is.
I tend to think, that Tomcat is right, because there is no
ExpressionString, so not a "real" Expression,
but others could have a different understanding of it.

What is your take on that ?

-- 
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

Re: we have a close to final version of MyFaces web interface :)

[Matthias Wessendorf]

the design is cool

I don't like:
http://www.ubuntu.com/

and myfaces has to many "hot" artifacts so a FF-style start-page would
contain "too much" infos;

let's keep the current structure + the a maven-skin that includes your design.

-M

On Dec 21, 2007 10:50 AM, Adonis Raduca <[EMAIL PROTECTED]> wrote:
>
>
> Hello,
>
> We have a close to final version of the MyFaces web interface. All elements
> needed are designed and are included in two design samples. I also added the
> apache feather in the header.
> All graphical elements are designed to achieve an intuitive and minimalist
> interface close to the already existing one. Also I tried to obtain a good
> color balancing between graphical elements for an interesting first look and
> nice for long time use.
>
> Please use the following link to see the snapshots:
> http://people.apache.org/~ckormos/myfaces/
>
> Will be nice if will have some opinions and suggestions regarding MyFaces
> web interface?
> After all we will use this interface more than others :)
>
> I think will be nice if will have a different layout for the first page that
> looks professional, where the visitor can easily find the hottest things. I
> think something like Ubuntu or Firefox first page will be nice.
>
> See you next year :) and Mary Christmas !
> Adonis



-- 
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

we have a close to final version of MyFaces web interface :)

[Adonis Raduca]

Hello,

We have a close to final version of the MyFaces web interface. All elements
needed are designed and are included in two design samples. I also added the
apache feather in the header.
All graphical elements are designed to achieve an intuitive and minimalist
interface close to the already existing one. Also I tried to obtain a good
color balancing between graphical elements for an interesting first look and
nice for long time use.

Please use the following link to see the snapshots:
http://people.apache.org/~ckormos/myfaces/

Will be nice if will have some opinions and suggestions regarding MyFaces
web interface?
After all we will use this interface more than others :)

I think will be nice if will have a different layout for the first page that
looks professional, where the visitor can easily find the hottest things. I
think something like Ubuntu or Firefox first page will be nice.

See you next year :) and Mary Christmas !
Adonis

[jira] Commented: (TRINIDAD-65) The JS e.getFacesMessage method does not work when trinidad was compiled with Java 6 (JSLocaleElementsGenerator does not work with Java6)

[JIRA]

[ 
https://issues.apache.org/jira/browse/TRINIDAD-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553913
 ] 

Matthias Weßendorf commented on TRINIDAD-65:


nevermind;
I noticed that the vmbuild was running w/ JDK6, but the zone is running on 1.5.x

> The JS e.getFacesMessage method does not work when trinidad was compiled with 
> Java 6 (JSLocaleElementsGenerator does not work with Java6)
> -
>
> Key: TRINIDAD-65
> URL: https://issues.apache.org/jira/browse/TRINIDAD-65
> Project: MyFaces Trinidad
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 1.0.0-incubating-plugins, 1.0.0-incubating-core, 
> 1.0.1-plugins
> Environment: Windows XP, Java 6
>Reporter: David Übelacker
>Assignee: Matthias Weßendorf
> Attachments: JSLocaleElementsGenerator.patch, LocaleDataResolver.java
>
>
> If trinidad was compiled with Java 6, you get the JS error "e.getFacesMessage 
> is no Function".
> The reason for this problem is, that the JSLocaleElementsGenerator  of the 
> maven-i18n-plugin does not work with Java 6.
> The JSLocaleElementsGenerator  uses some java resource bundles to generate 
> the LocaleElements files. These resource bundles are part of the rt.jar file 
> until java 5. With java 6 these bundles doesn't exist anymore, are hard coded 
> and can be accessed through sun.util.resources.LocaleData (not on the 
> public API).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.