date:20101013

Re: nesting cc:actionListener

2010-10-13 Thread Ganesh


This is cool, thank you for sending the fixed example! How comes this works, 
though 
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=755 is 
retargeted to 2.2? Do you have one more in your magic box for actions or does 
the spec issue remain valid here? If I do this:

!-- INTERFACE --
composite:interface
composite:attribute name=value/
composite:attribute name=action method-signature=java.lang.String 
action() targets=button1/
/composite:interface

!-- IMPLEMENTATION --
composite:implementation
level2:button id=button1 value=#{cc.attrs.value}/
/composite:implementation

then calling the page gives me:

java.lang.ClassCastException: javax.faces.component.UINamingContainer cannot be 
cast to javax.faces.component.ActionSource2

though level2:button is an ActionSource:

!-- INTERFACE --
composite:interface
composite:attribute name=value/
composite:attribute name=action method-signature=java.lang.String 
action() targets=button2/
/composite:interface

!-- IMPLEMENTATION --
composite:implementation
h:commandButton id=button2 value=#{cc.attrs.value}/
/composite:implementation

but probably not an ActionSource2 :-(

Best regards,
Ganesh

Am 12.10.2010 19:24, schrieb Leonardo Uribe:

Hi

I tried your example and work in this way:

test page calls a composite component in level 1:

xmlns:level1=http://java.sun.com/jsf/composite/level1;

level1:button value=test1
f:actionListener for=button1 binding=#{myBean.action1} /
/level1:button

level1 button passes the action listener on to level 2:

xmlns:level2=http://java.sun.com/jsf/composite/level2;

!-- INTERFACE --
composite:interface
composite:attribute name=value/
composite:actionSource name=button1 targets=button1 / !-- targets here is 
optional --
/composite:interface

!-- IMPLEMENTATION --
composite:implementation
level2:button id=button1 value=#{cc.attrs.value}/
/composite:implementation

   level 2 finally consumes the action:

!-- INTERFACE --
composite:interface
composite:attribute name=value/
composite:actionSource name=button1 targets=button2 /
/composite:interface

!-- IMPLEMENTATION --
composite:implementation
h:commandButton id=button2 value=#{cc.attrs.value} /
/composite:implementation

regards,

Leonardo

2010/10/12 Leonardo Uribe lu4...@gmail.com mailto:lu4...@gmail.com

Hi

I remember this one. Fortunately, MyFaces has many, many tests for composite
components. It also has a test for this specific issue and it works well:

testCompositeActionSource.xhtml

h:form id=testForm1
testComposite:compositeActionSource
f:actionListener for=button2 binding=#{helloWorldBean.actionListener}/
/testComposite:compositeActionSource
/h:form

compositeActionSource.xhtml

composite:interface
composite:actionSource name=button2 targets=button3/
/composite:interface
composite:implementation
testComposite:simpleActionSource id=button3 
f:actionListener for=button binding=#{helloWorldBean.actionListener}/
/testComposite:simpleActionSource
/composite:implementation

simpleActionSource.xhtml

composite:interface
composite:actionSource name=button/
composite:actionSource name=button2 targets=button/
/composite:interface
composite:implementation
h:commandButton id=button value=Press me! /
/composite:implementation

The button finally should have two actionListener. Look the attribute 
targets.
Try set it on your example. It should work without problem.

regards,

Leonardo Uribe


2010/10/12 Jakob Korherr jakob.korh...@gmail.com 
mailto:jakob.korh...@gmail.com

But anyhow, please open an issue for this. Thanks!

Regards,
Jakob

2010/10/12 Jakob Korherr jakob.korh...@gmail.com 
mailto:jakob.korh...@gmail.com:
  Hi Ganesh,
 
  This is a known problem of the JSF 2.0 spec, see [1]. Sadly it was
  (re-)targeted for 2.2.
 
  The problem is that when the ation listener is retargeted (from the
  composite component to the inner (implementation) component), it
  cannot be retargeted to another composite component, because this one
  does not implement ActionSource2. IMO we could try to implement a
  working solution already in MyFaces 2.0.x, but I don't know if this
  stuff is tested by the TCK..
 
  Regards,
  Jakob
 
  [1] 
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=755
 
  2010/10/12 Ganesh gan...@j4fry.org mailto:gan...@j4fry.org:
  Hi,
 
  If my test page calls a composite component in level 1:
 
 xmlns:level1=http://java.sun.com/jsf/composite/level1;

Re: nesting cc:actionListener

2010-10-13 Thread Jakob Korherr

Hi Ganesh,

Sorry, I was too fast in writing the answer. It works if you're using
f:actionListener, but it does not work correctly, if you're using a
parameter like action or actionListener (this is the related spec
issue).

Regards,
Jakob

2010/10/13 Ganesh gan...@j4fry.org:
 This is cool, thank you for sending the fixed example! How comes this works,
 though
 https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=755
 is retargeted to 2.2? Do you have one more in your magic box for actions or
 does the spec issue remain valid here? If I do this:

        !-- INTERFACE --
        composite:interface
                composite:attribute name=value/
                composite:attribute name=action
 method-signature=java.lang.String action() targets=button1/
        /composite:interface

        !-- IMPLEMENTATION --
        composite:implementation
                level2:button id=button1 value=#{cc.attrs.value}/
        /composite:implementation

 then calling the page gives me:

 java.lang.ClassCastException: javax.faces.component.UINamingContainer cannot
 be cast to javax.faces.component.ActionSource2

 though level2:button is an ActionSource:

        !-- INTERFACE --
        composite:interface
                composite:attribute name=value/
                composite:attribute name=action
 method-signature=java.lang.String action() targets=button2/
        /composite:interface

        !-- IMPLEMENTATION --
        composite:implementation
                h:commandButton id=button2 value=#{cc.attrs.value}/
        /composite:implementation

 but probably not an ActionSource2 :-(

 Best regards,
 Ganesh

 Am 12.10.2010 19:24, schrieb Leonardo Uribe:

 Hi

 I tried your example and work in this way:

 test page calls a composite component in level 1:

        xmlns:level1=http://java.sun.com/jsf/composite/level1;

 level1:button value=test1
 f:actionListener for=button1 binding=#{myBean.action1} /
 /level1:button

 level1 button passes the action listener on to level 2:

        xmlns:level2=http://java.sun.com/jsf/composite/level2;

 !-- INTERFACE --
 composite:interface
 composite:attribute name=value/
 composite:actionSource name=button1 targets=button1 / !-- targets
 here is optional --
 /composite:interface

 !-- IMPLEMENTATION --
 composite:implementation
 level2:button id=button1 value=#{cc.attrs.value}/
 /composite:implementation

   level 2 finally consumes the action:

 !-- INTERFACE --
 composite:interface
 composite:attribute name=value/
 composite:actionSource name=button1 targets=button2 /
 /composite:interface

 !-- IMPLEMENTATION --
 composite:implementation
 h:commandButton id=button2 value=#{cc.attrs.value} /
 /composite:implementation

 regards,

 Leonardo

 2010/10/12 Leonardo Uribe lu4...@gmail.com mailto:lu4...@gmail.com

    Hi

    I remember this one. Fortunately, MyFaces has many, many tests for
 composite
    components. It also has a test for this specific issue and it works
 well:

    testCompositeActionSource.xhtml

    h:form id=testForm1
    testComposite:compositeActionSource
    f:actionListener for=button2
 binding=#{helloWorldBean.actionListener}/
    /testComposite:compositeActionSource
    /h:form

    compositeActionSource.xhtml

    composite:interface
    composite:actionSource name=button2 targets=button3/
    /composite:interface
    composite:implementation
    testComposite:simpleActionSource id=button3 
    f:actionListener for=button
 binding=#{helloWorldBean.actionListener}/
    /testComposite:simpleActionSource
    /composite:implementation

    simpleActionSource.xhtml

    composite:interface
    composite:actionSource name=button/
    composite:actionSource name=button2 targets=button/
    /composite:interface
    composite:implementation
    h:commandButton id=button value=Press me! /
    /composite:implementation

    The button finally should have two actionListener. Look the attribute
 targets.
    Try set it on your example. It should work without problem.

    regards,

    Leonardo Uribe


    2010/10/12 Jakob Korherr jakob.korh...@gmail.com
 mailto:jakob.korh...@gmail.com

        But anyhow, please open an issue for this. Thanks!

        Regards,
        Jakob

        2010/10/12 Jakob Korherr jakob.korh...@gmail.com
 mailto:jakob.korh...@gmail.com:
          Hi Ganesh,
         
          This is a known problem of the JSF 2.0 spec, see [1]. Sadly it
 was
          (re-)targeted for 2.2.
         
          The problem is that when the ation listener is retargeted (from
 the
          composite component to the inner (implementation) component), it
          cannot be retargeted to another composite component, because
 this one
          does not implement ActionSource2. IMO we could try to implement
 a
          working solution already in MyFaces 2.0.x, but I don't know if
 this
          stuff is tested by the TCK..
         
          Regards,
          Jakob
         
          [1]

Re: nesting cc:actionListener

2010-10-13 Thread Ganesh


ok, thank you, so I will not open a MyFaces issue on this but comment the spec 
issue instead.

Best regards,
Ganesh

Am 13.10.2010 11:15, schrieb Jakob Korherr:

Hi Ganesh,

Sorry, I was too fast in writing the answer. It works if you're using
f:actionListener, but it does not work correctly, if you're using a
parameter like action or actionListener (this is the related spec
issue).

Regards,
Jakob

2010/10/13 Ganeshgan...@j4fry.org:

This is cool, thank you for sending the fixed example! How comes this works,
though
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=755
is retargeted to 2.2? Do you have one more in your magic box for actions or
does the spec issue remain valid here? If I do this:

!-- INTERFACE --
composite:interface
composite:attribute name=value/
composite:attribute name=action
method-signature=java.lang.String action() targets=button1/
/composite:interface

!-- IMPLEMENTATION --
composite:implementation
level2:button id=button1 value=#{cc.attrs.value}/
/composite:implementation

then calling the page gives me:

java.lang.ClassCastException: javax.faces.component.UINamingContainer cannot
be cast to javax.faces.component.ActionSource2

though level2:button is an ActionSource:

!-- INTERFACE --
composite:interface
composite:attribute name=value/
composite:attribute name=action
method-signature=java.lang.String action() targets=button2/
/composite:interface

!-- IMPLEMENTATION --
composite:implementation
h:commandButton id=button2 value=#{cc.attrs.value}/
/composite:implementation

but probably not an ActionSource2 :-(

Best regards,
Ganesh

Am 12.10.2010 19:24, schrieb Leonardo Uribe:


Hi

I tried your example and work in this way:

test page calls a composite component in level 1:

xmlns:level1=http://java.sun.com/jsf/composite/level1;

level1:button value=test1
f:actionListener for=button1 binding=#{myBean.action1} /
/level1:button

level1 button passes the action listener on to level 2:

xmlns:level2=http://java.sun.com/jsf/composite/level2;

!-- INTERFACE --
composite:interface
composite:attribute name=value/
composite:actionSource name=button1 targets=button1 /  !-- targets
here is optional --
/composite:interface

!-- IMPLEMENTATION --
composite:implementation
level2:button id=button1 value=#{cc.attrs.value}/
/composite:implementation

   level 2 finally consumes the action:

!-- INTERFACE --
composite:interface
composite:attribute name=value/
composite:actionSource name=button1 targets=button2 /
/composite:interface

!-- IMPLEMENTATION --
composite:implementation
h:commandButton id=button2 value=#{cc.attrs.value} /
/composite:implementation

regards,

Leonardo

2010/10/12 Leonardo Uribelu4...@gmail.commailto:lu4...@gmail.com

Hi

I remember this one. Fortunately, MyFaces has many, many tests for
composite
components. It also has a test for this specific issue and it works
well:

testCompositeActionSource.xhtml

h:form id=testForm1
testComposite:compositeActionSource
f:actionListener for=button2
binding=#{helloWorldBean.actionListener}/
/testComposite:compositeActionSource
/h:form

compositeActionSource.xhtml

composite:interface
composite:actionSource name=button2 targets=button3/
/composite:interface
composite:implementation
testComposite:simpleActionSource id=button3
f:actionListener for=button
binding=#{helloWorldBean.actionListener}/
/testComposite:simpleActionSource
/composite:implementation

simpleActionSource.xhtml

composite:interface
composite:actionSource name=button/
composite:actionSource name=button2 targets=button/
/composite:interface
composite:implementation
h:commandButton id=button value=Press me! /
/composite:implementation

The button finally should have two actionListener. Look the attribute
targets.
Try set it on your example. It should work without problem.

regards,

Leonardo Uribe


2010/10/12 Jakob Korherrjakob.korh...@gmail.com
mailto:jakob.korh...@gmail.com

But anyhow, please open an issue for this. Thanks!

Regards,
Jakob

2010/10/12 Jakob Korherrjakob.korh...@gmail.com
mailto:jakob.korh...@gmail.com:
   Hi Ganesh,
 
   This is a known problem of the JSF 2.0 spec, see [1]. Sadly it
was
   (re-)targeted for 2.2.
 
   The problem is that when the ation listener is retargeted (from
the
   composite component to the inner (implementation) component), it
   cannot be retargeted to another composite component, because
this one
   does not implement ActionSource2. IMO we could try to implement
a
   working solution already in MyFaces 2.0.x, but I don't know if
this
   stuff is tested by the

[RESULTS] Release Portlet bridge 2.0.0-beta

2010-10-13 Thread Michael Freedman


 Sorry for the delay in making this announcement.
The vote for the release of Portlet Bridge 2.0.0-beta was approved in 
July. [1]


+1: Werner Punz, Mike Freedman, Scott O'Bryan, Matthias Wessendorf
+0: none
-1: none

Thanks to everyone who voted.
Michael Freedman

[1] http://www.mail-archive.com/dev@myfaces.apache.org/msg47436.html

[jira] Commented: (TRINIDAD-1887) Javascript failure with tr:NumberConverter type=currency

2010-10-13 Thread Yee-Wah Lee (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-1887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12920811#action_12920811
 ] 

Yee-Wah Lee commented on TRINIDAD-1887:
---

With ar_sa locale, the curency symbols defined in locale.js are:
CurrencyElements:[\u0631.\u0633.\u200f, SAR, \u0631.\u0633.\u200f , , 
\u0631.\u0633.\u200f , -], 

The error message when incrementing/decrementing is:
value, stepSize, min, and max must all be numbers. value: ر.س.‏ 9, stepSize: 2, 
min: 1, max: 100

 Javascript failure with tr:NumberConverter type=currency
 

 Key: TRINIDAD-1887
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1887
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 1.2.13-core 
Reporter: Yee-Wah Lee
Priority: Minor

 1. Create an inputNumberSpinbox with type currency.
  tr:inputNumberSpinbox  label=Label 1 id=ins1 
 value=#{clientValidation.integer}
minimum=1 maximum=100 stepSize=2
   tr:convertNumber type=currency/ 
   /tr:inputNumberSpinbox
 2. Run the demo. Notice the value contains generic currency symbol 78,57 ¤. 
 Press the up arrow to increment value. Get a message:
 value, stepSize, min, and max must all be numbers. value: 78,57 ¤, stepSize: 
 1, min: 1, max: 2147483647
 Tried for different locales - en, fr, ar

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

[jira] Created: (TOMAHAWK-1551) f:ajax doesn't work in t:selectOneRadio layout=spread

2010-10-13 Thread Bauke Scholtz (JIRA)

f:ajax doesn't work in t:selectOneRadio layout=spread
---

 Key: TOMAHAWK-1551
 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1551
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: selectOneRadio / radio
Affects Versions: 1.1.10
 Environment: Mojarra 2.0.3, Tomcat 6.0.29, Eclipse 3.6, Windows XP
Reporter: Bauke Scholtz


The f:ajax doesn't work in t:selectOneRadio layout=spread. Judging the HTML 
source, it incorrectly obtains the client ID of t:selectOneRadio instead of the 
one of the t:radio (or just this) as first argument of the ajax function. 
This is been used in document.getElementById() which in turns returns 
null/undefinied and breaks the ajax function.

XHTML source:
t:selectOneRadio id=item value=#{bean.item} layout=spread
f:selectItems value=#{bean.items} /
f:ajax event=click /
/t:selectOneRadio
t:radio for=item index=0 /
t:radio for=item index=0 /

Generated HTML source (labels omitted):
input id=form:item:0 type=radio name=form:item value=item1 
onclick=mojarra.ab('form:item',event,'click',0,0) /
input id=form:item:1 type=radio name=form:item value=item2 
onclick=mojarra.ab('form:item',event,'click',0,0) /

Expected HTML source (labels omitted):
input id=form:item:0 type=radio name=form:item value=item1 
onclick=mojarra.ab('form:item:0',event,'click',0,0) /
input id=form:item:1 type=radio name=form:item value=item2 
onclick=mojarra.ab('form:item:1',event,'click',0,0) /
OR
input id=form:item:0 type=radio name=form:item value=item1 
onclick=mojarra.ab(this,event,'click',0,0) /
input id=form:item:1 type=radio name=form:item value=item2 
onclick=mojarra.ab(this,event,'click',0,0) /


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

Re: nesting cc:actionListener

Re: nesting cc:actionListener

Re: nesting cc:actionListener

[RESULTS] Release Portlet bridge 2.0.0-beta

[jira] Commented: (TRINIDAD-1887) Javascript failure with tr:NumberConverter type=currency

[jira] Created: (TOMAHAWK-1551) f:ajax doesn't work in t:selectOneRadio layout=spread

6 matches

Site Navigation

Mail list logo

Footer information