[jira] [Created] (TOBAGO-1417) TabGroup: tabChangeListener is never invoked

2014-08-11 Thread Volker Weber (JIRA)
Volker Weber created TOBAGO-1417:


 Summary: TabGroup: tabChangeListener is never invoked
 Key: TOBAGO-1417
 URL: https://issues.apache.org/jira/browse/TOBAGO-1417
 Project: MyFaces Tobago
  Issue Type: Bug
  Components: Core
Affects Versions: 2.0.0
Reporter: Volker Weber
Assignee: Volker Weber






--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Resolved] (TOBAGO-1417) TabGroup: tabChangeListener is never invoked

2014-08-11 Thread Volker Weber (JIRA)

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

Volker Weber resolved TOBAGO-1417.
--

   Resolution: Fixed
Fix Version/s: 2.0.2

 TabGroup: tabChangeListener is never invoked
 

 Key: TOBAGO-1417
 URL: https://issues.apache.org/jira/browse/TOBAGO-1417
 Project: MyFaces Tobago
  Issue Type: Bug
  Components: Core
Affects Versions: 2.0.0
Reporter: Volker Weber
Assignee: Volker Weber
 Fix For: 2.0.2






--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Commented] (TRINIDAD-2507) Allow CoreRenderer to take part in broadcast of a FacesEvent

2014-08-11 Thread Andrew Robinson (JIRA)

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

Andrew Robinson commented on TRINIDAD-2507:
---

Committed revision 1617320.

 Allow CoreRenderer to take part in broadcast of a FacesEvent
 

 Key: TRINIDAD-2507
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2507
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Components
Affects Versions: 2.1.1-core
Reporter: Andrew Robinson
Assignee: Andrew Robinson
 Fix For: 2.1.1-core


 There are times that a renderer (especially during decode) could want a 
 callback during a later lifecycle. For example, a renderer may want to queue 
 an event and handle that event itself when broadcast. JSF does not make this 
 easy, keeping all the FacesEvent logic in the component and making 
 addFacesListener a protected, instead of public, method. 
 We can improve this for Trinidad by adding a method to CoreRenderer (public 
 void broadcast(UIXComponent component, FacesEvent event)) that the 
 UIXComponentBase could call. The default implementation would be a no-op but 
 could be overwritten to provide the necessary functionality.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Resolved] (TRINIDAD-2507) Allow CoreRenderer to take part in broadcast of a FacesEvent

2014-08-11 Thread Andrew Robinson (JIRA)

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

Andrew Robinson resolved TRINIDAD-2507.
---

   Resolution: Fixed
Fix Version/s: 2.1.1-core

 Allow CoreRenderer to take part in broadcast of a FacesEvent
 

 Key: TRINIDAD-2507
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2507
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Components
Affects Versions: 2.1.1-core
Reporter: Andrew Robinson
Assignee: Andrew Robinson
 Fix For: 2.1.1-core


 There are times that a renderer (especially during decode) could want a 
 callback during a later lifecycle. For example, a renderer may want to queue 
 an event and handle that event itself when broadcast. JSF does not make this 
 easy, keeping all the FacesEvent logic in the component and making 
 addFacesListener a protected, instead of public, method. 
 We can improve this for Trinidad by adding a method to CoreRenderer (public 
 void broadcast(UIXComponent component, FacesEvent event)) that the 
 UIXComponentBase could call. The default implementation would be a no-op but 
 could be overwritten to provide the necessary functionality.



--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Commented] (TOBAGO-1417) TabGroup: tabChangeListener is never invoked

2014-08-11 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/TOBAGO-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14092951#comment-14092951
 ] 

Hudson commented on TOBAGO-1417:


SUCCESS: Integrated in tobago-trunk #1246 (See 
[https://builds.apache.org/job/tobago-trunk/1246/])
TOBAGO-1417 - TabGroup: tabChangeListener is never invoked (weber: 
http://svn.apache.org/viewvc/?view=revrev=1617310)
* 
/myfaces/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/component/AbstractUITabGroup.java


 TabGroup: tabChangeListener is never invoked
 

 Key: TOBAGO-1417
 URL: https://issues.apache.org/jira/browse/TOBAGO-1417
 Project: MyFaces Tobago
  Issue Type: Bug
  Components: Core
Affects Versions: 2.0.0
Reporter: Volker Weber
Assignee: Volker Weber
 Fix For: 2.0.2






--
This message was sent by Atlassian JIRA
(v6.2#6252)


[jira] [Updated] (TRINIDAD-2499) ChangeManager provides incorrect document location for dynamic components

2014-08-11 Thread Prakash Udupa (JIRA)

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

Prakash Udupa updated TRINIDAD-2499:


Status: Patch Available  (was: Open)

 ChangeManager provides incorrect document location for dynamic components
 -

 Key: TRINIDAD-2499
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2499
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Archetype
Affects Versions: 2.1.0-core
Reporter: Prakash Udupa
 Attachments: TRINIDAD-2499.patch

   Original Estimate: 2h
  Remaining Estimate: 2h

 In TRINIDAD-2397, enhancement was provided to obtain the document location of 
 components are are dynamically added. There is a bug in this code that in 
 some cases the location is not provided correctly, as explained in the 
 following example:
 Consider this page structure:
 jsp:root
   foo:three
 foo:insertingComponent = Step #2: This subtree is inserted from 
 fragment2.jsff
   jsp:root
 foo:dynamicLayout
   foo:two = Step #1: defined in fargment1.jsff
 foo:one = Customization target, this inserted component is 
 defined in fragment1.jsff
 In this example, the search for location is expected to stop at step #1 and 
 location returned as 'fragment1.jsff', instead the look up extends until step 
 #2 and returns incorrect location 'fragment2.jsff'.
 This causes the wrong document being searched for the customization target 
 here, customization failed therefore.
 The bug is in 
 org.apache.myfaces.trinidad.util.ComponentUtils.getDocumentLocationForComponent()
 Will provide a fix patch soon.



--
This message was sent by Atlassian JIRA
(v6.2#6252)