Re: xmlmenumodel not displaying sub menus with trinidad/jsf
Hi Abhi,
I am using trinidad 1.2.12. I made changes that you suggested, am still
getting the same output.
modified metadata file is as below.
?xml version=1.0 encoding=windows-1252 ?
menu xmlns=http://myfaces.apache.org/trinidad/menu;
itemNode id=department label=department
action=__dept_adfMenu_action__ focusViewId=/dept/
itemNode id=employees_tree label=employees
action=__emp_adfMenu_action__ focusViewId=/emp
itemNode id=sndTb1 label=innerTb action=dummy
focusViewId=/emp1/
itemNode id=sndTb2 label=innerTb2 action=dummy
focusViewId=/emp2/
/itemNode
itemNode id=employees_dnd label=employees dnd
action=__emp_dnd_adfMenu_action__ focusViewId=/emp_dnd/
/menu
modified jspx code is as below.
!-- First level tabs --
tr:navigationPane var=menuInfo value=#{root_menu}
level=0
hint=tabs id=navigationPane1
f:facet name=nodeStamp
tr:commandNavigationItem text=#{menuInfo.label}
action=#{menuInfo.doAction}
id=pt_cni2/
/f:facet
/tr:navigationPane
!-- Second level bars --
tr:navigationPane var=menuInfo value=#{root_menu}
level=1
hint=bar id=pt_np3
f:facet name=nodeStamp
tr:commandNavigationItem text=#{menuInfo.label}
action=#{menuInfo.doAction}
id=pt_cni3/
/f:facet
/tr:navigationPane
Do I need to code anything at the server side?
Thanks,
UR
Abhijit Ghosh wrote:
Please let us know what version of trinidad you are using.Your tag
code seems fine.The menu metadata xml has the same focusViewId for the
parent and two of it's children,I don't think that is correct.Also
selected=true is not needed on the commandNavigationItems,though I
doubt it would cause the problem you are describing.Can you make the
above changes and try it out.
Thanks,
Abhi
On Tue, Oct 6, 2009 at 3:00 AM, ADFUR arved.r...@gmail.com wrote:
I am trying to display two level menus in my application. I am getting
top
level menu at the sub level.
Am I missing anything?
Here is my (meta data) root_menu.xml file.
?xml version=1.0 encoding=windows-1252 ?
menu xmlns=http://myfaces.apache.org/trinidad/menu;
itemNode id=department label=department
action=__dept_adfMenu_action__ focusViewId=/dept/
itemNode id=employees_tree label=employees
action=__emp_adfMenu_action__ focusViewId=/emp
itemNode id=sndTb1 label=innerTb1 action=dummy
focusViewId=/emp/
itemNode id=sndTb2 label=innerTb2 action=dummy
focusViewId=/emp/
/itemNode
itemNode id=employees_dnd label=employees dnd
action=__emp_dnd_adfMenu_action__ focusViewId=/emp_dnd/
/menu
My faces-config.xml has following bean defined.
managed-bean
description
Menu Model Managed Bean
/description
managed-bean-nameroot_menu/managed-bean-name
managed-bean-classorg.apache.myfaces.trinidad.model.XMLMenuModel/managed-bean-class
managed-bean-scoperequest/managed-bean-scope
managed-property
property-namecreateHiddenNodes/property-name
valuetrue/value
/managed-property
managed-property
property-namesource/property-name
value/WEB-INF/root_menu.xml/value
/managed-property
/managed-bean
My jsf code is as below.
tr:navigationPane var=menuInfo value=#{root_menu} level=0
hint=tabs id=navigationPane1
f:facet name=nodeStamp
tr:commandNavigationItem text=#{menuInfo.label}
action=#{menuInfo.doAction}
icon=#{menuInfo.icon}
destination=#{menuInfo.destination}
rendered=#{menuInfo.rendered}
selected=true
id=pt_cni2/
/f:facet
/tr:navigationPane
!-- Second level bars --
tr:navigationPane var=menuInfo value=#{root_menu}
level=1
hint=bar id=pt_np3
f:facet name=nodeStamp
tr:commandNavigationItem text=#{menuInfo.label}
action=#{menuInfo.doAction}
icon=#{menuInfo.icon}
destination=#{menuInfo.destination}
rendered=#{menuInfo.rendered}
selected=true
id=pt_cni3/
/f:facet
/tr:navigationPane
I am getting tabs as below
department employees employess_dnd
[jira] Created: (TRINIDAD-1588) NullPointerException using labelAndAccessKey Attribute in XMLMenuModel itemNode Definition
NullPointerException using labelAndAccessKey Attribute in XMLMenuModel itemNode
Definition
--
Key: TRINIDAD-1588
URL: https://issues.apache.org/jira/browse/TRINIDAD-1588
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 1.2.12-core
Reporter: Markus Dreher
With Trinidad 1.2.12 i've got the an Exception using the following definition,
which worked very well in Version before 1.2.12:
itemNode id= administration immediate=true
labelAndAccessKey=Administration rendered=true disabled=true
/itemNode
The labelAndAccessKey Value uses no AccessKey Notation (), which results in
the following NullpointerException:
java.lang.NullPointerException
at
org.apache.myfaces.trinidadinternal.menu.ImmutableItemNode._joinLabelAndAccessKey(ImmutableItemNode.java:569)
at
org.apache.myfaces.trinidadinternal.menu.ImmutableItemNode.getLabelAndAccessKey(ImmutableItemNode.java:522)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at javax.el.BeanELResolver.getValue(BeanELResolver.java:62)
at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:53)
at
com.sun.faces.el.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:72)
at org.apache.el.parser.AstValue.getValue(AstValue.java:97)
at
org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:186)
at
com.sun.facelets.el.TagValueExpression.getValue(TagValueExpression.java:71)
There should be a check for a null accessKey like in ImmutableGroupNode and
MenuNode since this is a legal condition.
add before line 522:
if(accessKey == null) {
return label;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [Trinidad] JSF 2.0
Good! Looking forward that :) Cheers, Bruno 2009/10/8 Matthias Wessendorf mwessend...@gmail.com Sure! Let me create such à branch. you create jira tickets for all the issues. -Matthias Sent from my iPod. On 08.10.2009, at 02:37, Andy Schwartz andy.g.schwa...@gmail.com wrote: Gang - I am interested in taking a closer look at Trinidad/JSF 2.0 integration. I suspect that there are other folks who are interested in this as well. Would it be possible to create a Trinidad branch for JSF 2.0-related work? For the moment, I think that an experimental/sandbox-type branch that we could use for prototyping purposes would be helpful/would facilitate collaboration on this effort. Thoughts? Andy
Re: [Trinidad] JSF 2.0
Hello Andy, I created the experimental branch on this location: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/trinidad-2.0.x Greetings, Matthias On Thu, Oct 8, 2009 at 2:37 AM, Andy Schwartz andy.g.schwa...@gmail.com wrote: Gang - I am interested in taking a closer look at Trinidad/JSF 2.0 integration. I suspect that there are other folks who are interested in this as well. Would it be possible to create a Trinidad branch for JSF 2.0-related work? For the moment, I think that an experimental/sandbox-type branch that we could use for prototyping purposes would be helpful/would facilitate collaboration on this effort. Thoughts? Andy -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Created: (TRINIDAD-1589) Light Weight Dialog adjustment to standard window behaviour
Light Weight Dialog adjustment to standard window behaviour --- Key: TRINIDAD-1589 URL: https://issues.apache.org/jira/browse/TRINIDAD-1589 Project: MyFaces Trinidad Issue Type: New Feature Components: Skinning Reporter: Radek Hodain Priority: Trivial Attachments: patch.txt Add Minimize and the Restore-down buttons into light weight dialog to better adjustment to standard window behavior. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
unsubscribe
From: Radek Hodain (JIRA) [mailto:d...@myfaces.apache.org] Sent: Thu 08/10/2009 10:39 To: dev@myfaces.apache.org Subject: [jira] Created: (TRINIDAD-1589) Light Weight Dialog adjustment to standard window behaviour Light Weight Dialog adjustment to standard window behaviour --- Key: TRINIDAD-1589 URL: https://issues.apache.org/jira/browse/TRINIDAD-1589 Project: MyFaces Trinidad Issue Type: New Feature Components: Skinning Reporter: Radek Hodain Priority: Trivial Attachments: patch.txt Add Minimize and the Restore-down buttons into light weight dialog to better adjustment to standard window behavior. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: xmlmenumodel not displaying sub menus with trinidad/jsf
Your focusViewId should be something like '/dept.jspx' and '/emp.jspx'
and not '/dept' and '/emp'.
Try putting an outputText on your page to see what the focusViewId is
for that page:
tr:outputText value=#{facesContext.viewRoot.viewId}/
Thanks,
Abhi
On Thu, Oct 8, 2009 at 12:00 PM, ADFUR arved.r...@gmail.com wrote:
Hi Abhi,
I am using trinidad 1.2.12. I made changes that you suggested, am still
getting the same output.
modified metadata file is as below.
?xml version=1.0 encoding=windows-1252 ?
menu xmlns=http://myfaces.apache.org/trinidad/menu;
itemNode id=department label=department
action=__dept_adfMenu_action__ focusViewId=/dept/
itemNode id=employees_tree label=employees
action=__emp_adfMenu_action__ focusViewId=/emp
itemNode id=sndTb1 label=innerTb action=dummy
focusViewId=/emp1/
itemNode id=sndTb2 label=innerTb2 action=dummy
focusViewId=/emp2/
/itemNode
itemNode id=employees_dnd label=employees dnd
action=__emp_dnd_adfMenu_action__ focusViewId=/emp_dnd/
/menu
modified jspx code is as below.
!-- First level tabs --
tr:navigationPane var=menuInfo value=#{root_menu}
level=0
hint=tabs id=navigationPane1
f:facet name=nodeStamp
tr:commandNavigationItem text=#{menuInfo.label}
action=#{menuInfo.doAction}
id=pt_cni2/
/f:facet
/tr:navigationPane
!-- Second level bars --
tr:navigationPane var=menuInfo value=#{root_menu}
level=1
hint=bar id=pt_np3
f:facet name=nodeStamp
tr:commandNavigationItem text=#{menuInfo.label}
action=#{menuInfo.doAction}
id=pt_cni3/
/f:facet
/tr:navigationPane
Do I need to code anything at the server side?
Thanks,
UR
Abhijit Ghosh wrote:
Please let us know what version of trinidad you are using.Your tag
code seems fine.The menu metadata xml has the same focusViewId for the
parent and two of it's children,I don't think that is correct.Also
selected=true is not needed on the commandNavigationItems,though I
doubt it would cause the problem you are describing.Can you make the
above changes and try it out.
Thanks,
Abhi
On Tue, Oct 6, 2009 at 3:00 AM, ADFUR arved.r...@gmail.com wrote:
I am trying to display two level menus in my application. I am getting
top
level menu at the sub level.
Am I missing anything?
Here is my (meta data) root_menu.xml file.
?xml version=1.0 encoding=windows-1252 ?
menu xmlns=http://myfaces.apache.org/trinidad/menu;
itemNode id=department label=department
action=__dept_adfMenu_action__ focusViewId=/dept/
itemNode id=employees_tree label=employees
action=__emp_adfMenu_action__ focusViewId=/emp
itemNode id=sndTb1 label=innerTb1 action=dummy
focusViewId=/emp/
itemNode id=sndTb2 label=innerTb2 action=dummy
focusViewId=/emp/
/itemNode
itemNode id=employees_dnd label=employees dnd
action=__emp_dnd_adfMenu_action__ focusViewId=/emp_dnd/
/menu
My faces-config.xml has following bean defined.
managed-bean
description
Menu Model Managed Bean
/description
managed-bean-nameroot_menu/managed-bean-name
managed-bean-classorg.apache.myfaces.trinidad.model.XMLMenuModel/managed-bean-class
managed-bean-scoperequest/managed-bean-scope
managed-property
property-namecreateHiddenNodes/property-name
valuetrue/value
/managed-property
managed-property
property-namesource/property-name
value/WEB-INF/root_menu.xml/value
/managed-property
/managed-bean
My jsf code is as below.
tr:navigationPane var=menuInfo value=#{root_menu} level=0
hint=tabs id=navigationPane1
f:facet name=nodeStamp
tr:commandNavigationItem text=#{menuInfo.label}
action=#{menuInfo.doAction}
icon=#{menuInfo.icon}
destination=#{menuInfo.destination}
rendered=#{menuInfo.rendered}
selected=true
id=pt_cni2/
/f:facet
/tr:navigationPane
!-- Second level bars --
tr:navigationPane var=menuInfo value=#{root_menu}
level=1
hint=bar id=pt_np3
f:facet name=nodeStamp
tr:commandNavigationItem text=#{menuInfo.label}
action=#{menuInfo.doAction}
icon=#{menuInfo.icon}
destination=#{menuInfo.destination}
rendered=#{menuInfo.rendered}
Re: [Trinidad] JSF 2.0
Hi, I'm using trinidad with mojarra 2.0. These are steps to get trinidad compiled and running on JSF 2.0: 1) Since 2.0 all method on wrappers are public. In this case it is: - org.apache.myfaces.trinidadinternal.application.StateManagerImpl - make getWrapped public - org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl - make getWrapped - public Those changes are backward compatible with 1.2. 2) Make NavigationHandlerImpl child of javax.faces.application.ConfigurableNavigationHandler 3) Use javax.faces.context.ExternalContextWrapper instead of ExternalContextDecorator and make changes: - SessionSerializationChecker - add method getWrapped - XmlHttpPortletExternalContext -add method getWrapped - OverrideDispatch - add method getWrapped - ClearRequestExternalContext - add method getWrapped 4) Use Facelets API from javax.faces instead of com.sun I'll create patches - can you add version 2.0 to JIRA please? Matthias Wessendorf píše v Čt 08. 10. 2009 v 10:24 +0200: Hello Andy, I created the experimental branch on this location: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/trinidad-2.0.x Greetings, Matthias On Thu, Oct 8, 2009 at 2:37 AM, Andy Schwartz andy.g.schwa...@gmail.com wrote: Gang - I am interested in taking a closer look at Trinidad/JSF 2.0 integration. I suspect that there are other folks who are interested in this as well. Would it be possible to create a Trinidad branch for JSF 2.0-related work? For the moment, I think that an experimental/sandbox-type branch that we could use for prototyping purposes would be helpful/would facilitate collaboration on this effort. Thoughts? Andy
Re: [Trinidad] JSF 2.0
done; added 2.0.0-core -Matthias On Thu, Oct 8, 2009 at 12:50 PM, Matthias Wessendorf mat...@apache.org wrote: oh, yes. I will add a new version :-) Thanks for the feedback! On Thu, Oct 8, 2009 at 12:50 PM, Matthias Wessendorf mat...@apache.org wrote: the goal is not only to make it running with JSF 2.0; the goal is to support JSF 2.0 features w/in Trinidad. -Matthias On Thu, Oct 8, 2009 at 12:55 PM, Martin Kočí martin.k...@aura.cz wrote: Hi, I'm using trinidad with mojarra 2.0. These are steps to get trinidad compiled and running on JSF 2.0: 1) Since 2.0 all method on wrappers are public. In this case it is: - org.apache.myfaces.trinidadinternal.application.StateManagerImpl - make getWrapped public - org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl - make getWrapped - public Those changes are backward compatible with 1.2. 2) Make NavigationHandlerImpl child of javax.faces.application.ConfigurableNavigationHandler 3) Use javax.faces.context.ExternalContextWrapper instead of ExternalContextDecorator and make changes: - SessionSerializationChecker - add method getWrapped - XmlHttpPortletExternalContext -add method getWrapped - OverrideDispatch - add method getWrapped - ClearRequestExternalContext - add method getWrapped 4) Use Facelets API from javax.faces instead of com.sun I'll create patches - can you add version 2.0 to JIRA please? Matthias Wessendorf píše v Čt 08. 10. 2009 v 10:24 +0200: Hello Andy, I created the experimental branch on this location: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/trinidad-2.0.x Greetings, Matthias On Thu, Oct 8, 2009 at 2:37 AM, Andy Schwartz andy.g.schwa...@gmail.com wrote: Gang - I am interested in taking a closer look at Trinidad/JSF 2.0 integration. I suspect that there are other folks who are interested in this as well. Would it be possible to create a Trinidad branch for JSF 2.0-related work? For the moment, I think that an experimental/sandbox-type branch that we could use for prototyping purposes would be helpful/would facilitate collaboration on this effort. Thoughts? Andy -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Updated: (TRINIDAD-1589) Light Weight Dialog adjustment to standard window behaviour
[ https://issues.apache.org/jira/browse/TRINIDAD-1589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Radek Hodain updated TRINIDAD-1589: --- Status: Patch Available (was: Open) Light Weight Dialog adjustment to standard window behaviour --- Key: TRINIDAD-1589 URL: https://issues.apache.org/jira/browse/TRINIDAD-1589 Project: MyFaces Trinidad Issue Type: New Feature Components: Skinning Reporter: Radek Hodain Priority: Trivial Attachments: icons.zip, maxSize.png, patch.txt, userSize.png Original Estimate: 1h Remaining Estimate: 1h Add Minimize and the Restore-down buttons into light weight dialog to better adjustment to standard window behavior. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOMAHAWK-1461) WARNING: Invalid tag found: unexpected input while looking for attr name or '/' at line 10. Surroundings: ' name=form_SUBMIT value=1'.
WARNING: Invalid tag found: unexpected input while looking for attr name or '/' at line 10. Surroundings: ' name=form_SUBMIT value=1'. Key: TOMAHAWK-1461 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1461 Project: MyFaces Tomahawk Issue Type: Bug Components: Examples Affects Versions: 1.1.9, 1.1.7 Environment: Tomcat 6, myfaces-impl-1.1.7, myfaces-api-1.1.7 and tomahawk-1.1.9. Working on myfaces-example-blank-1.1.9 war file in eclipse. Reporter: khushwinder Priority: Critical I am trying to run following jsp page : %@ taglib uri=http://java.sun.com/jsf/html; prefix=h % %@ taglib uri=http://java.sun.com/jsf/core; prefix=f% html head titleHello World/title /head body f:view h:form id=form h:panelGrid id=grid h:inputText id=input1 value=D:\\spool\\test_receiver11\\ required=true/ /h:panelGrid /h:form /f:view /body /html Because thaevalue of inputText value box is ending with \\ slashes i am getting the following warning: WARNING: Invalid tag found: unexpected input while looking for attr name or '/' at line 10. Surroundings: ' name=form_SUBMIT value=1'. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Trinidad] JSF 2.0
Matthias Wessendorf píše v Čt 08. 10. 2009 v 12:50 +0200:
the goal is not only to make it running with JSF 2.0;
the goal is to support JSF 2.0 features w/in Trinidad.
Yes, I understand that. Right now I'm working on Resource API support -
I'll provide some patches for #{resource['image.jpg']} etc.
Martin
-Matthias
On Thu, Oct 8, 2009 at 12:55 PM, Martin Kočí martin.k...@aura.cz wrote:
Hi,
I'm using trinidad with mojarra 2.0. These are steps to get trinidad
compiled and running on JSF 2.0:
1) Since 2.0 all method on wrappers are public. In this case it is:
- org.apache.myfaces.trinidadinternal.application.StateManagerImpl -
make getWrapped public
- org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl - make
getWrapped - public
Those changes are backward compatible with 1.2.
2) Make NavigationHandlerImpl child of
javax.faces.application.ConfigurableNavigationHandler
3) Use javax.faces.context.ExternalContextWrapper instead of
ExternalContextDecorator
and make changes:
- SessionSerializationChecker - add method getWrapped
- XmlHttpPortletExternalContext -add method getWrapped
- OverrideDispatch - add method getWrapped
- ClearRequestExternalContext - add method getWrapped
4) Use Facelets API from javax.faces instead of com.sun
I'll create patches - can you add version 2.0 to JIRA please?
Matthias Wessendorf píše v Čt 08. 10. 2009 v 10:24 +0200:
Hello Andy,
I created the experimental branch on this location:
https://svn.apache.org/repos/asf/myfaces/trinidad/branches/trinidad-2.0.x
Greetings,
Matthias
On Thu, Oct 8, 2009 at 2:37 AM, Andy Schwartz andy.g.schwa...@gmail.com
wrote:
Gang -
I am interested in taking a closer look at Trinidad/JSF 2.0
integration. I suspect that there are other folks who are interested
in this as well. Would it be possible to create a Trinidad branch for
JSF 2.0-related work? For the moment, I think that an
experimental/sandbox-type branch that we could use for prototyping
purposes would be helpful/would facilitate collaboration on this
effort.
Thoughts?
Andy
Re: [Trinidad] JSF 2.0
On Thu, Oct 8, 2009 at 1:33 PM, Martin Kočí martin.k...@aura.cz wrote:
Matthias Wessendorf píše v Čt 08. 10. 2009 v 12:50 +0200:
the goal is not only to make it running with JSF 2.0;
the goal is to support JSF 2.0 features w/in Trinidad.
Yes, I understand that. Right now I'm working on Resource API support -
I'll provide some patches for #{resource['image.jpg']} etc.
cool :)
Martin
-Matthias
On Thu, Oct 8, 2009 at 12:55 PM, Martin Kočí martin.k...@aura.cz wrote:
Hi,
I'm using trinidad with mojarra 2.0. These are steps to get trinidad
compiled and running on JSF 2.0:
1) Since 2.0 all method on wrappers are public. In this case it is:
- org.apache.myfaces.trinidadinternal.application.StateManagerImpl -
make getWrapped public
- org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl - make
getWrapped - public
Those changes are backward compatible with 1.2.
2) Make NavigationHandlerImpl child of
javax.faces.application.ConfigurableNavigationHandler
3) Use javax.faces.context.ExternalContextWrapper instead of
ExternalContextDecorator
and make changes:
- SessionSerializationChecker - add method getWrapped
- XmlHttpPortletExternalContext -add method getWrapped
- OverrideDispatch - add method getWrapped
- ClearRequestExternalContext - add method getWrapped
4) Use Facelets API from javax.faces instead of com.sun
I'll create patches - can you add version 2.0 to JIRA please?
Matthias Wessendorf píše v Čt 08. 10. 2009 v 10:24 +0200:
Hello Andy,
I created the experimental branch on this location:
https://svn.apache.org/repos/asf/myfaces/trinidad/branches/trinidad-2.0.x
Greetings,
Matthias
On Thu, Oct 8, 2009 at 2:37 AM, Andy Schwartz andy.g.schwa...@gmail.com
wrote:
Gang -
I am interested in taking a closer look at Trinidad/JSF 2.0
integration. I suspect that there are other folks who are interested
in this as well. Would it be possible to create a Trinidad branch for
JSF 2.0-related work? For the moment, I think that an
experimental/sandbox-type branch that we could use for prototyping
purposes would be helpful/would facilitate collaboration on this
effort.
Thoughts?
Andy
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
TRINIDAD-1558 - NPE w/ Googlebot
Hi, there were several issues in the past regarding exceptions w/ the Googlebot engine. Does one know if this: https://issues.apache.org/jira/browse/TRINIDAD-1558 has been fixed with the recent checkins ? Thanks! Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Updated: (TRINIDAD-1558) java.lang.NullPointerException: version must be non-null with Googlebot agent (trindad trunk)
[ https://issues.apache.org/jira/browse/TRINIDAD-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Weßendorf updated TRINIDAD-1558: - Resolution: Duplicate Fix Version/s: 1.2.13-core Status: Resolved (was: Patch Available) this is a duplicate of TRINIDAD-1520. The bug has been fixed with the fix for TRINIDAD-1520 java.lang.NullPointerException: version must be non-null with Googlebot agent (trindad trunk) -- Key: TRINIDAD-1558 URL: https://issues.apache.org/jira/browse/TRINIDAD-1558 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.13-core Environment: Linux 2.6 Java(TM) SE Runtime Environment (build 1.6.0_16-b01) tomcat 6.0.18 myfaces-api/impl-1.2.7 trinidad-api/impl 1.2.13-SNAPSHOT (trunk) Reporter: Angel Priority: Critical Fix For: 1.2.13-core when request with the header of Googlebots comes org/apache/myfaces/trinidadinternal/agent/AgentImpl.java gets initialized with String _agent = NULL; and String _agentVersion = NULL; and a NPE is thrown: java.lang.NullPointerException: version must be non-null at org.apache.myfaces.trinidad.context.Version._checkNonEmptyString(Version.java:197) at org.apache.myfaces.trinidad.context.Version.init(Version.java:69) at org.apache.myfaces.trinidad.context.Version.init(Version.java:54) at org.apache.myfaces.trinidadinternal.style.util.NameUtils._isBrowserAndVersionMatch(NameUtils.java:640) at org.apache.myfaces.trinidadinternal.style.util.NameUtils.getContextName(NameUtils.java:344) at org.apache.myfaces.trinidadinternal.style.cache.FileSystemStyleCache.getTargetStyleSheetName(FileSystemStyleCache.java:325) at org.apache.myfaces.trinidadinternal.skin.SkinStyleProvider.getTargetStyleSheetName(SkinStyleProvider.java:199) at org.apache.myfaces.trinidadinternal.style.cache.FileSystemStyleCache._getOutputFiles(FileSystemStyleCache.java:879) at org.apache.myfaces.trinidadinternal.style.cache.FileSystemStyleCache._createStyleSheetFiles(FileSystemStyleCache.java:757) at org.apache.myfaces.trinidadinternal.style.cache.FileSystemStyleCache._createEntry(FileSystemStyleCache.java:542) at org.apache.myfaces.trinidadinternal.style.cache.FileSystemStyleCache._getEntry(FileSystemStyleCache.java:445) at org.apache.myfaces.trinidadinternal.style.cache.FileSystemStyleCache.getStyleSheetURIs(FileSystemStyleCache.java:165) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.StyleSheetRenderer.encodeAll(StyleSheetRenderer.java:97) at org.apache.myfaces.trinidad.render.CoreRenderer.delegateRenderer(CoreRenderer.java:446) at org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.HeadRenderer.encodeBegin(HeadRenderer.java:80) at org.apache.myfaces.trinidad.render.CoreRenderer.encodeBegin(CoreRenderer.java:311) at org.apache.myfaces.trinidad.component.UIXComponentBase.encodeBegin(UIXComponentBase.java:718) at org.apache.myfaces.trinidad.component.UIXComponentBase.__encodeRecursive(UIXComponentBase.java:1478) at org.apache.myfaces.trinidad.component.UIXComponentBase.__encodeRecursive(UIXComponentBase.java:1489) at org.apache.myfaces.trinidad.component.UIXComponentBase.encodeAll(UIXComponentBase.java:771) at javax.faces.component.UIComponent.encodeAll(UIComponent.java:257) at org.apache.myfaces.application.jsp.JspViewHandlerImpl.actuallyRenderView(JspViewHandlerImpl.java:427) at org.apache.myfaces.application.jsp.JspViewHandlerImpl.renderView(JspViewHandlerImpl.java:383) at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:48) at org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:193) at org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:41) at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:140) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:155) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Unknown Source) at org.apache.catalina.core.ApplicationFilterChain.doFilter(Unknown Source) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl(TrinidadFilterImpl.java:247) at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:157) at org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Unknown Source) at
[jira] Commented: (MYFACES-2378) Use java util logging on 2.0.x branch
[ https://issues.apache.org/jira/browse/MYFACES-2378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12763536#action_12763536 ] Leonardo Uribe commented on MYFACES-2378: - Ok. After take a look at these arguments, I think it is better to keep the full class name as the key for now, because it is more simple. Use java util logging on 2.0.x branch - Key: MYFACES-2378 URL: https://issues.apache.org/jira/browse/MYFACES-2378 Project: MyFaces Core Issue Type: Task Components: JSR-314 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Attachments: MYFACES-2378-core.patch, MYFACES-2378-shared-core.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1590) maven-jdev-plugin: added ability to set JVM Java Options. Default is -ea to enable assertions
maven-jdev-plugin: added ability to set JVM Java Options. Default is -ea to
enable assertions
---
Key: TRINIDAD-1590
URL: https://issues.apache.org/jira/browse/TRINIDAD-1590
Project: MyFaces Trinidad
Issue Type: New Feature
Affects Versions: 1.2.10-plugins
Reporter: Gary Kind
In Jdeveloper under Project Properties - Run/Debug/Profile, edit a selected
profile and you will see a Java Options input text field to the right of the
selected JVM. An attribute has been added to the maven-jdev-plugin to set
these Java Options. Here is a sample of how it would be set in a maven pom.xml
file:
plugin
groupIdorg.apache.myfaces.trinidadbuild/groupId
artifactIdmaven-jdev-plugin/artifactId
configuration
javaOptions-ea/javaOptions
projectHasTests${jdev.project.has.tests}/projectHasTests
testSourceRoots
file${project.basedir}/src/test/file
/testSourceRoots
/configuration
/plugin
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1590) maven-jdev-plugin: added ability to set JVM Java Options. Default is -ea to enable assertions
[
https://issues.apache.org/jira/browse/TRINIDAD-1590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Kind updated TRINIDAD-1590:
Status: Patch Available (was: Open)
maven-jdev-plugin: added ability to set JVM Java Options. Default is -ea to
enable assertions
---
Key: TRINIDAD-1590
URL: https://issues.apache.org/jira/browse/TRINIDAD-1590
Project: MyFaces Trinidad
Issue Type: New Feature
Affects Versions: 1.2.10-plugins
Reporter: Gary Kind
In Jdeveloper under Project Properties - Run/Debug/Profile, edit a selected
profile and you will see a Java Options input text field to the right of the
selected JVM. An attribute has been added to the maven-jdev-plugin to set
these Java Options. Here is a sample of how it would be set in a maven
pom.xml file:
plugin
groupIdorg.apache.myfaces.trinidadbuild/groupId
artifactIdmaven-jdev-plugin/artifactId
configuration
javaOptions-ea/javaOptions
projectHasTests${jdev.project.has.tests}/projectHasTests
testSourceRoots
file${project.basedir}/src/test/file
/testSourceRoots
/configuration
/plugin
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1591) [Trinidad2] Make trinidad runnable on JSF 2.0
[ https://issues.apache.org/jira/browse/TRINIDAD-1591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Koci updated TRINIDAD-1591: -- Status: Patch Available (was: Open) [Trinidad2] Make trinidad runnable on JSF 2.0 - Key: TRINIDAD-1591 URL: https://issues.apache.org/jira/browse/TRINIDAD-1591 Project: MyFaces Trinidad Issue Type: Task Components: Build Affects Versions: 2.0.0-core Environment: trinidad 2.0 branch, JSF 2.0 Mojarra Reporter: Martin Koci - org.apache.myfaces.trinidadinternal.application.StateManagerImpl - make getWrapped public - org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl - make getWrapped public - make NavigationHandlerImpl child of javax.faces.application.ConfigurableNavigationHandler - use javax.faces.context.ExternalContextWrapper instead of ExternalContextDecorator and make changes: - SessionSerializationChecker - add method getWrapped - XmlHttpPortletExternalContext -add method getWrapped - OverrideDispatch - add method getWrapped - ClearRequestExternalContext - add method getWrapped - Use Facelets API from javax.faces instead of com.sun -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1591) [Trinidad2] Make trinidad runnable on JSF 2.0
[Trinidad2] Make trinidad runnable on JSF 2.0 - Key: TRINIDAD-1591 URL: https://issues.apache.org/jira/browse/TRINIDAD-1591 Project: MyFaces Trinidad Issue Type: Task Components: Build Affects Versions: 2.0.0-core Environment: trinidad 2.0 branch, JSF 2.0 Mojarra Reporter: Martin Koci - org.apache.myfaces.trinidadinternal.application.StateManagerImpl - make getWrapped public - org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl - make getWrapped public - make NavigationHandlerImpl child of javax.faces.application.ConfigurableNavigationHandler - use javax.faces.context.ExternalContextWrapper instead of ExternalContextDecorator and make changes: - SessionSerializationChecker - add method getWrapped - XmlHttpPortletExternalContext -add method getWrapped - OverrideDispatch - add method getWrapped - ClearRequestExternalContext - add method getWrapped - Use Facelets API from javax.faces instead of com.sun -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2340) Get basic-ezcomp 2.0 sample working
[ https://issues.apache.org/jira/browse/MYFACES-2340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12763669#action_12763669 ] Leonardo Uribe commented on MYFACES-2340: - Committed fix partial state saving suscribe add/remove components view listener after relocate components. Get basic-ezcomp 2.0 sample working - Key: MYFACES-2340 URL: https://issues.apache.org/jira/browse/MYFACES-2340 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Curtiss Howard Fix For: 2.0.0-alpha Get the basic-ezcomp Mojarra 2.0 sample working. This sample makes extensive use of composite components. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Trinidad] JSF 2.0
I don't believe that SessionSerializationChecker should have a getWrapped method yet. This class follows the pattern of the Collections decorators which don't have getWrapped(). -- Blake Sullivan Martin Kočí said the following On 10/8/2009 3:55 AM PT: Hi, I'm using trinidad with mojarra 2.0. These are steps to get trinidad compiled and running on JSF 2.0: 1) Since 2.0 all method on wrappers are public. In this case it is: - org.apache.myfaces.trinidadinternal.application.StateManagerImpl - make getWrapped public - org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl - make getWrapped - public Those changes are backward compatible with 1.2. 2) Make NavigationHandlerImpl child of javax.faces.application.ConfigurableNavigationHandler 3) Use javax.faces.context.ExternalContextWrapper instead of ExternalContextDecorator and make changes: - SessionSerializationChecker - add method getWrapped - XmlHttpPortletExternalContext -add method getWrapped - OverrideDispatch - add method getWrapped - ClearRequestExternalContext - add method getWrapped 4) Use Facelets API from javax.faces instead of com.sun I'll create patches - can you add version 2.0 to JIRA please? Matthias Wessendorf píše v Čt 08. 10. 2009 v 10:24 +0200: Hello Andy, I created the experimental branch on this location: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/trinidad-2.0.x Greetings, Matthias On Thu, Oct 8, 2009 at 2:37 AM, Andy Schwartz andy.g.schwa...@gmail.com wrote: Gang - I am interested in taking a closer look at Trinidad/JSF 2.0 integration. I suspect that there are other folks who are interested in this as well. Would it be possible to create a Trinidad branch for JSF 2.0-related work? For the moment, I think that an experimental/sandbox-type branch that we could use for prototyping purposes would be helpful/would facilitate collaboration on this effort. Thoughts? Andy
[jira] Resolved: (MYFACES-2340) Get basic-ezcomp 2.0 sample working
[ https://issues.apache.org/jira/browse/MYFACES-2340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-2340. - Resolution: Fixed Assignee: Leonardo Uribe At this time everything is working well, so I'll close this issue. We can reopen it later if necessary (more examples here...) Get basic-ezcomp 2.0 sample working - Key: MYFACES-2340 URL: https://issues.apache.org/jira/browse/MYFACES-2340 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Curtiss Howard Assignee: Leonardo Uribe Fix For: 2.0.0-alpha Get the basic-ezcomp Mojarra 2.0 sample working. This sample makes extensive use of composite components. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2330) Get basic-ajax 2.0 sample app working
[ https://issues.apache.org/jira/browse/MYFACES-2330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-2330. - Resolution: Fixed Fix Version/s: 2.0.0-alpha Assignee: Leonardo Uribe At this time everything is working well, so I'll close this issue. We can reopen it later if necessary (more examples here...) Get basic-ajax 2.0 sample app working --- Key: MYFACES-2330 URL: https://issues.apache.org/jira/browse/MYFACES-2330 Project: MyFaces Core Issue Type: Task Components: JSR-314 Affects Versions: 2.0.0-alpha Reporter: Curtiss Howard Assignee: Leonardo Uribe Fix For: 2.0.0-alpha Get the Mojarra basic-ajax sample app working. This app tests UI templating and AJAX. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2136) UISelectMany
[ https://issues.apache.org/jira/browse/MYFACES-2136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe updated MYFACES-2136: Resolution: Fixed Fix Version/s: 2.0.0-alpha Assignee: Leonardo Uribe Status: Resolved (was: Patch Available) Thanks to Jakob Korherr for provide this patch UISelectMany Key: MYFACES-2136 URL: https://issues.apache.org/jira/browse/MYFACES-2136 Project: MyFaces Core Issue Type: Task Components: JSR-314 Reporter: Simon-Pierre Béliveau Assignee: Leonardo Uribe Fix For: 2.0.0-alpha Attachments: uiselectmany_conversion.patch The currently selected items can be stored in a Collection. Store the result of each conversion in a data structure, called targetForConvertedValues for discussion. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2370) 'invokeOnComponent' method in UIData does not properly process h:column header/footer facets
[ https://issues.apache.org/jira/browse/MYFACES-2370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe updated MYFACES-2370: Resolution: Fixed Fix Version/s: 1.2.8-SNAPSHOT Assignee: Leonardo Uribe Status: Resolved (was: Patch Available) Thanks to Jakob Korherr for provide this patch 'invokeOnComponent' method in UIData does not properly process h:column header/footer facets -- Key: MYFACES-2370 URL: https://issues.apache.org/jira/browse/MYFACES-2370 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.2.7 Reporter: Kennard Consulting Assignee: Leonardo Uribe Fix For: 1.2.8-SNAPSHOT Attachments: uidata.patch A bug that was originally reported to the RichFaces project here (includes simple test case)... https://jira.jboss.org/jira/browse/RF-7700 ...was identifed by the RichFaces team as being caused by failure to process h:column header/footer facets in 'invokeOnComponent'. The RichFaces team reported this to the Mojarra guys... https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1308 ...who fixed it in their implementation (as of 1.2_14) I then put together a MyFaces version of the same test case (attached as suggestionMyFaces.zip)... https://jira.jboss.org/jira/browse/RF-7700 ...and it appears MyFaces (as of 1.2.7) has the same bug? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2370) 'invokeOnComponent' method in UIData does not properly process h:column header/footer facets
[ https://issues.apache.org/jira/browse/MYFACES-2370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12763736#action_12763736 ] Kennard Consulting commented on MYFACES-2370: - Terrific. Thanks for the quick turnaround guys. Look forward to trying it. 'invokeOnComponent' method in UIData does not properly process h:column header/footer facets -- Key: MYFACES-2370 URL: https://issues.apache.org/jira/browse/MYFACES-2370 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 1.2.7 Reporter: Kennard Consulting Assignee: Leonardo Uribe Fix For: 1.2.8-SNAPSHOT Attachments: uidata.patch A bug that was originally reported to the RichFaces project here (includes simple test case)... https://jira.jboss.org/jira/browse/RF-7700 ...was identifed by the RichFaces team as being caused by failure to process h:column header/footer facets in 'invokeOnComponent'. The RichFaces team reported this to the Mojarra guys... https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1308 ...who fixed it in their implementation (as of 1.2_14) I then put together a MyFaces version of the same test case (attached as suggestionMyFaces.zip)... https://jira.jboss.org/jira/browse/RF-7700 ...and it appears MyFaces (as of 1.2.7) has the same bug? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ORCHESTRA-45) Support for JSF 2.0
Support for JSF 2.0 --- Key: ORCHESTRA-45 URL: https://issues.apache.org/jira/browse/ORCHESTRA-45 Project: MyFaces Orchestra Issue Type: Improvement Components: FrameworkAdapter Affects Versions: 1.3.1 Reporter: Martin Marinschek Orchestra should support JSF 2.0. The supplied patch changes the decorators in Orchestra to allow this, however, the patch is not backwards compatible with the 1.2/1.1 version (and contrary to supporting both 1.1 and 1.2 in one version, this is not possible with 2.0 anymore, as the interfaces have new methods which in turn have parameters/return types which are only available in JSF 2.0). The question will be how we will be able to continue. I see two options: a) a branch, and two independent releases b) adding a common JSF 1.2 compatibility library, which would allow to a certain extent to mimick basic JSF 2.0 infrastructure (it would not try to reimplement features from 2.0, however) I will also post this question to the MyFaces mailing-list, and we will see how to proceed from here. regards, Martin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (ORCHESTRA-41) NullPointerException in method findConversationContextId
[ https://issues.apache.org/jira/browse/ORCHESTRA-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Marinschek resolved ORCHESTRA-41. Resolution: Cannot Reproduce Assignee: Martin Marinschek NullPointerException in method findConversationContextId Key: ORCHESTRA-41 URL: https://issues.apache.org/jira/browse/ORCHESTRA-41 Project: MyFaces Orchestra Issue Type: Bug Components: Conversation, FrameworkAdapter Affects Versions: 1.3.1 Environment: Windows XP SP2, Tomcat 6.0.20 Reporter: Bozhidar Bozhanov Assignee: Martin Marinschek Original Estimate: 0.08h Remaining Estimate: 0.08h After some time, (probably when a thread times-out) the following appears: Exception in thread org.apache.myfaces.orchestra.conversation.ConversationWiperThread java.lang.NullPointerException at org.apache.myfaces.orchestra.conversation.ConversationManager.findConversationContextId(ConversationManager.java:140) at org.apache.myfaces.orchestra.conversation.ConversationManager.removeAndInvalidateConversationContext(ConversationManager.java:343) at org.apache.myfaces.orchestra.conversation.ConversationManager.checkTimeouts(ConversationManager.java:626) at org.apache.myfaces.orchestra.conversation.ConversationWiperThread._run(ConversationWiperThread.java:113) at org.apache.myfaces.orchestra.conversation.ConversationWiperThread.run(ConversationWiperThread.java:90) It doesn't bring any trouble to the front-end, but still, it is an exception :) The problem, I think is that the ThreadLocal variable (after the thread has timed-out) return null, so no conversationContext anymore. A little anti-NPE check in the findConversaionContextId would get rid of the exception. I'm not sure whether this happens in 1.3.1, I checked the source code in the repository and there was no NPE check, so I presume the issue is still there. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ORCHESTRA-40) A transaction token component inspired by the struts transaction processor
[ https://issues.apache.org/jira/browse/ORCHESTRA-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12763785#action_12763785 ] Martin Marinschek commented on ORCHESTRA-40: Ok, so there was a lot of action here, but not really a lot of discussion. Let's discuss about the base first: Bernd's (and by the way also Manfred's and mine) point of view is that a JSF application should have a way to be informed of back-button clicks, forward-button clicks, refreshes, double-submits, etc. As I see it, an interface implemented by the application should provide a hook which needs to be called in such cases. Now for me this is highly conversation-context (=tab or window) related: a back-button is always clicked within a tab or window. If you want to indicate to the user that the back-button has been pressed you will need to store a list of tokens (one per request) and again, I think that should be stored per conversation-context (not in the session). If it is not for this, Orchestra should provide ways to handle these problems cause a solution is desperately needed in the JSF space. AFAIK, only Spring Webflow provides something out of the box, and with Spring Webflow you are moving pretty far off the JSF standard, both from a configuration perspective and a usage perspective (however, I am not saying that Spring Webflow is bad - it is indeed a very good framework - just not very close to JSF if you take a deeper look at it). regards, Martin A transaction token component inspired by the struts transaction processor -- Key: ORCHESTRA-40 URL: https://issues.apache.org/jira/browse/ORCHESTRA-40 Project: MyFaces Orchestra Issue Type: New Feature Components: Conversation Affects Versions: 1.3.1 Reporter: Bernd Bohmann Assignee: Simon Kitching Attachments: ORCHESTRA-40-CacheControl+TransactionToken-before-restore-View2.patch, ORCHESTRA-40-CacheControl+TransactionTokenListener-after-restore-View3.patch, ORCHESTRA-40-CacheControl.patch, ORCHESTRA-40-TransactionToken.patch A transactionToken Component for orchestra inspired by the struts transaction processor. The transaction token is to be used for enforcing a single request for a particular transaction. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (MYFACES-2309) Add new attributes to f:selectItems
[ https://issues.apache.org/jira/browse/MYFACES-2309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe reopened MYFACES-2309: - UISelectItems javadoc does not have getter and setters for them, so we have to ask EG for this and if is true, update our code. Add new attributes to f:selectItems --- Key: MYFACES-2309 URL: https://issues.apache.org/jira/browse/MYFACES-2309 Project: MyFaces Core Issue Type: Task Components: JSR-314 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 2.0.0-alpha Attachments: selectitems_new_attributes.patch New attributes where added to f:selectItems tag. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jsf 2.0] UISelectItems does not implement getter and setter for attributes added on f:selectItems
Hi Checking some stuff about jsf 2.0, I have seen that f:selectItems added some new attributes, but UISelectItems javadoc does not have getter and setters for them. In theory, every attribute defined for a component should have getter and setter (with some exceptions like binding). On myfaces, we add getter and setter without notice it. Is this a typo error, or this is intentional? regards Leonardo Uribe
[jira] Commented: (ORCHESTRA-40) A transaction token component inspired by the struts transaction processor
[ https://issues.apache.org/jira/browse/ORCHESTRA-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12763854#action_12763854 ] Mario Ivankovits commented on ORCHESTRA-40: --- I think we all agree, having a decent handling for this thing is a long missing feature here in JSF land. I also agree that it is much more a virulent problem when you use a conversation framework as it is much likely that you run into problems with the database else. The question is if we need it strongly integrated into Orchestra. I've looked at the patch, and beside that something gets stored into the conversationContext I can not see anything which can not be solved using normal JSF phase listeners. And for storing into the conversationContext we can create a scope which does this (instead of accessing it directly). You also gain the ability to decide on which level the tokens are kept. If you do not use Orchestra you simply can the manager bean into the session then. I'd say this component qualifies for its own project, e.g. within our ext (sorry, lost the name) project. On the other hand, I understand that - compared to seam and webflow - people await such functionality from Orchestra too. If we add this to Orchestra, I'd like to see it in a separated module, e.g. orchestra-jsfext. Would this be feasible? As for the technical aspect of this patch, I have some notes: 1) Does this solution work with ajax, or will an ajax request trigger a DOUBLE_SUBMIT_OR_RELOAD_TYPE notification? I think ajax detection needs to be added, at least to detect JSF 2.0 alike ajax requests. 2) I see you store the token in the request parameter. Probably - in the context of ajax - storing it as attribute on the UIViewRoot might be better. If you have to deal with ajax requests you are able to update this value then with the new token. I am also constantly thinking about moving the conversationContext paramter into the UIViewRoot - but this is another story. 3) We should also add a default TransactionTokenListener which behaves in a way we think an application should react on these events.People than can use it to jump start the system. Probably something like MyTransactionTokenListener with a faces message added so the user will get some feedback. 4) I'd like to have a way to ignore some requests. E.g. if you issue an jsf action which will just stream a PDF to the user (without page change), the browser stay on the page, but the token has been used then. The current token needs to be added to the list of used tokens at the end of the request then. Probably an API like TransactionTokenManager.getInstance().ignoreRequest() suppress this addittion then for the current request. The token can then be used again. Also trinidad has at least two components which open a window and just report the value back to the main window. Probably we also need a way to ignore requests based on an URL pattern to deal with that? Ciao, Mario A transaction token component inspired by the struts transaction processor -- Key: ORCHESTRA-40 URL: https://issues.apache.org/jira/browse/ORCHESTRA-40 Project: MyFaces Orchestra Issue Type: New Feature Components: Conversation Affects Versions: 1.3.1 Reporter: Bernd Bohmann Assignee: Simon Kitching Attachments: ORCHESTRA-40-CacheControl+TransactionToken-before-restore-View2.patch, ORCHESTRA-40-CacheControl+TransactionTokenListener-after-restore-View3.patch, ORCHESTRA-40-CacheControl.patch, ORCHESTRA-40-TransactionToken.patch A transactionToken Component for orchestra inspired by the struts transaction processor. The transaction token is to be used for enforcing a single request for a particular transaction. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
