Which one should be used : Mojarra vs. MyFaces
Hi, We are also using myfaces for JSF 1.2 reference implementation in our UI framwork project. Now we have a push that we should replace it with Mojarra project implementaion. What do you suggest about these two implemenations w.r.t. JSF 2.0. thanks, Agam
[jira] Commented: (MYFACES-2452) Myfaces doesn't provide support for "Enable RestoreView 1.1 Compatibility" like sun ri implementation
[
https://issues.apache.org/jira/browse/MYFACES-2452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787394#action_12787394
]
Agam Dass commented on MYFACES-2452:
Introduce flag org.apache.myfaces.enableRestoreView11Compatibility which can be
used to work in compatibility mode if set to true.
public boolean execute(FacesContext facesContext)
{
if (facesContext == null)
{
throw new FacesException("FacesContext is null");
}
// init the View
Application application = facesContext.getApplication();
ViewHandler viewHandler = application.getViewHandler();
viewHandler.initView(facesContext);
UIViewRoot viewRoot = facesContext.getViewRoot();
RestoreViewSupport restoreViewSupport = getRestoreViewSupport();
if (viewRoot != null)
{
if (log.isTraceEnabled())
log.trace("View already exists in the FacesContext");
viewRoot.setLocale(facesContext.getExternalContext().getRequestLocale());
restoreViewSupport.processComponentBinding(facesContext, viewRoot);
return false;
}
String viewId = restoreViewSupport.calculateViewId(facesContext);
// Determine if this request is a postback or initial request
if (restoreViewSupport.isPostback(facesContext))
{
if (log.isTraceEnabled())
log.trace("Request is a postback");
viewRoot = viewHandler.restoreView(facesContext, viewId);
if (viewRoot == null)
{
// check the new flag
org.apache.myfaces.enableRestoreView11Compatibility to execute the below logic.
// See : https://issues.apache.org/jira/browse/MYFACES-2452
// To run the restore view in compatibility mode we need to
make sure that
// in case of view is not found in the LRUMap; create a new
view and flag that
// the response should be immediately rendered
if (log.isTraceEnabled())
log.trace("Postback: recreating a view for " + viewId);
viewRoot = viewHandler.createView(facesContext, viewId);
facesContext.renderResponse();
}
if (viewRoot == null)
{
throw new ViewExpiredException(
"No saved view state could be found for the view
identifier: "
+ viewId, viewId);
}
restoreViewSupport.processComponentBinding(facesContext, viewRoot);
}
else
{
if (log.isTraceEnabled())
log.trace("Request is not a postback. New UIViewRoot will be
created");
viewRoot = viewHandler.createView(facesContext, viewId);
facesContext.renderResponse();
}
facesContext.setViewRoot(viewRoot);
return false;
}
> Myfaces doesn't provide support for "Enable RestoreView 1.1 Compatibility"
> like sun ri implementation
> --
>
> Key: MYFACES-2452
> URL: https://issues.apache.org/jira/browse/MYFACES-2452
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 1.2.8
> Environment: Window, Linux, AIX, JBoss and WAS app server, AJAX4JSF,
> Jsf1.2, Facelets 1.1.14
>Reporter: Agam Dass
>
> JSF 1.2
> Facelets 1.1.14
> AJAX4JSF [richfaces-ui-3.3.2.SR1]
> State Saving : Server
> Myfaces implementation doesn't provide support for the compatibility
> RestoreView according to JSF1.1 where if viewroot is null, it will be
> created again instead of throw ViewExpiredException. Sun JSF RI provides a
> compatibility mode using parameter
> com.sun.faces.enableRestoreView11Compatibility in the web.xml and then if
> configured it will be consulted while taking decision to create the view
> again or throw the ViewExpired exception.
> Due to this after moving to JSF 1.2 it keep on throwing VewExpiredException
> if couldn't be found in the session map, when state saving method is server.
> Please refer to the code in class
> com.sun.faces.lifecycle.RestoreViewPhase#execute method
> ---
> public void execute(FacesContext facesContext) throws FacesException {
> :
> boolean isPostBack = (facesContext.isPostback() &&
> !isErrorPage(facesContext));
> 196 if (isPostBack)
[jira] Updated: (MYFACES-2452) Myfaces doesn't provide support for "Enable RestoreView 1.1 Compatibility" like sun ri implementation
[
https://issues.apache.org/jira/browse/MYFACES-2452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Agam Dass updated MYFACES-2452:
---
Status: Patch Available (was: Open)
> Myfaces doesn't provide support for "Enable RestoreView 1.1 Compatibility"
> like sun ri implementation
> --
>
> Key: MYFACES-2452
> URL: https://issues.apache.org/jira/browse/MYFACES-2452
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
>Affects Versions: 1.2.8
> Environment: Window, Linux, AIX, JBoss and WAS app server, AJAX4JSF,
> Jsf1.2, Facelets 1.1.14
>Reporter: Agam Dass
>
> JSF 1.2
> Facelets 1.1.14
> AJAX4JSF [richfaces-ui-3.3.2.SR1]
> State Saving : Server
> Myfaces implementation doesn't provide support for the compatibility
> RestoreView according to JSF1.1 where if viewroot is null, it will be
> created again instead of throw ViewExpiredException. Sun JSF RI provides a
> compatibility mode using parameter
> com.sun.faces.enableRestoreView11Compatibility in the web.xml and then if
> configured it will be consulted while taking decision to create the view
> again or throw the ViewExpired exception.
> Due to this after moving to JSF 1.2 it keep on throwing VewExpiredException
> if couldn't be found in the session map, when state saving method is server.
> Please refer to the code in class
> com.sun.faces.lifecycle.RestoreViewPhase#execute method
> ---
> public void execute(FacesContext facesContext) throws FacesException {
> :
> boolean isPostBack = (facesContext.isPostback() &&
> !isErrorPage(facesContext));
> 196 if (isPostBack) {
> 197 facesContext.setProcessingEvents(false);
> 198 // try to restore the view
> 199 viewRoot = viewHandler.restoreView(facesContext, viewId);
> 200 if (viewRoot == null) {
> 201 if (is11CompatEnabled(facesContext)) {
> 202 // 1.1 -> create a new view and flag that the
> response should
> 203 //be immediately rendered
> 204 if (LOGGER.isLoggable(Level.FINE)) {
> 205 LOGGER.fine("Postback: recreating a view for
> " + viewId);
> 206 }
> 207 viewRoot = viewHandler.createView(facesContext,
> viewId);
> 208 facesContext.renderResponse();
> 209
> 210 } else {
> 211 Object[] params = {viewId};
> 212 throw new ViewExpiredException(
> 213 MessageUtils.getExceptionMessageString(
> 214
> MessageUtils.RESTORE_VIEW_ERROR_MESSAGE_ID,
> 215 params),
> 216 viewId);
> 217 }
> 218 }
> 219
> 220 facesContext.setViewRoot(viewRoot);
> 221 facesContext.setProcessingEvents(true);
> 222 if (LOGGER.isLoggable(Level.FINE)) {
> 223 LOGGER.fine("Postback: restored view for " + viewId);
> 224 }
> 225 }
> -
> Similar support should be provided by Mayfaces also. With sate saving as
> server, the state saving/restoring is not very reliable and throw VEE many a
> times. RichFaces also uses the parameter
> com.sun.faces.enableRestoreView11Compatibility to run its test suite.
> This is really a blocking issue until the problem of state saving at server
> is not fully solved and made reliable.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2452) Myfaces doesn't provide support for "Enable RestoreView 1.1 Compatibility" like sun ri implementation
Myfaces doesn't provide support for "Enable RestoreView 1.1 Compatibility" like
sun ri implementation
--
Key: MYFACES-2452
URL: https://issues.apache.org/jira/browse/MYFACES-2452
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 1.2.8
Environment: Window, Linux, AIX, JBoss and WAS app server, AJAX4JSF,
Jsf1.2, Facelets 1.1.14
Reporter: Agam Dass
JSF 1.2
Facelets 1.1.14
AJAX4JSF [richfaces-ui-3.3.2.SR1]
State Saving : Server
Myfaces implementation doesn't provide support for the compatibility
RestoreView according to JSF1.1 where if viewroot is null, it will be created
again instead of throw ViewExpiredException. Sun JSF RI provides a
compatibility mode using parameter
com.sun.faces.enableRestoreView11Compatibility in the web.xml and then if
configured it will be consulted while taking decision to create the view again
or throw the ViewExpired exception.
Due to this after moving to JSF 1.2 it keep on throwing VewExpiredException if
couldn't be found in the session map, when state saving method is server.
Please refer to the code in class
com.sun.faces.lifecycle.RestoreViewPhase#execute method
---
public void execute(FacesContext facesContext) throws FacesException {
:
boolean isPostBack = (facesContext.isPostback() &&
!isErrorPage(facesContext));
196 if (isPostBack) {
197 facesContext.setProcessingEvents(false);
198 // try to restore the view
199 viewRoot = viewHandler.restoreView(facesContext, viewId);
200 if (viewRoot == null) {
201 if (is11CompatEnabled(facesContext)) {
202 // 1.1 -> create a new view and flag that the
response should
203 //be immediately rendered
204 if (LOGGER.isLoggable(Level.FINE)) {
205 LOGGER.fine("Postback: recreating a view for "
+ viewId);
206 }
207 viewRoot = viewHandler.createView(facesContext,
viewId);
208 facesContext.renderResponse();
209
210 } else {
211 Object[] params = {viewId};
212 throw new ViewExpiredException(
213 MessageUtils.getExceptionMessageString(
214
MessageUtils.RESTORE_VIEW_ERROR_MESSAGE_ID,
215 params),
216 viewId);
217 }
218 }
219
220 facesContext.setViewRoot(viewRoot);
221 facesContext.setProcessingEvents(true);
222 if (LOGGER.isLoggable(Level.FINE)) {
223 LOGGER.fine("Postback: restored view for " + viewId);
224 }
225 }
-
Similar support should be provided by Mayfaces also. With sate saving as
server, the state saving/restoring is not very reliable and throw VEE many a
times. RichFaces also uses the parameter
com.sun.faces.enableRestoreView11Compatibility to run its test suite.
This is really a blocking issue until the problem of state saving at server is
not fully solved and made reliable.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1550) convertDateTime handles type="date" incorrectly
[
https://issues.apache.org/jira/browse/TRINIDAD-1550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12770388#action_12770388
]
Agam Dass commented on TRINIDAD-1550:
-
I think this change was done to preserve the time portion (like time zone which
could change the date itself) but this doesn't seem to be correct to store
information related to time from previous date.
> convertDateTime handles type="date" incorrectly
> ---
>
> Key: TRINIDAD-1550
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1550
> Project: MyFaces Trinidad
> Issue Type: Bug
> Components: Components
>Affects Versions: 1.2.10-core
> Environment: Linux 64-bit, Java 1.5.0_11
>Reporter: Eric Price
>Priority: Minor
>
> I have a backing bean that contains two HtmlInputText components. One stores
> the "date" part of a Date, the other stores the "time" part of a Date. When
> the user enters the information, the "date" and "time" are combined to form
> the actual Date.
> The bean has the following declarations:
> public class DateTestBean {
> private HtmlInputText dateInput = null;
> private HtmlInputText timeInput = null;
> private Date date = null;
> private Date time = null;
>
>
> public DateTestBean() {
> dateInput = new HtmlInputText();
> timeInput = new HtmlInputText();
>
> date = Calendar.getInstance( TimeZone.getTimeZone( "GMT" ) );
> time = (Date)date.clone();
> }
> }
> For my sample program, I have a button on the jsp that calls the action
> method setDateAction() to update the date/time values with current values.
> That method is shown below:
> public String setDateAction() {
> Calendar dateCal = Calendar.getInstance( TimeZone.getTimeZone( "GMT" ) );
> Calendar timeCal = (Calendar)dateCal.clone();
>
> dateInput.setValue( dateCal.getTime() );
> timeInput.setValue( timeCal.getTime() );
>
> date = dateCal.getTime();
> time = timeCal.getTime();
> return "success";
> }
> There is a corresponding action method associated with a submit button on the
> jsp that prints the date/time values when the page is submitted.
> public String displayDateAction() {
> Object valObj = this.dateInput.getValue();
>
> if (valObj instanceof Date) {
> System.out.println(" date=" + formatDate( (Date)valObj ) );
> }
>
> valObj = this.timeInput.getValue();
> if (valObj instanceof Date) {
> System.out.println( " time=" + formatDate( (Date)valObj ) );
> }
> }
> Here is the code snipit from the jsp:
>
>immediate="true" value="#{dateTestBean.date}" title="-MM-dd"
> id="dateInput">
>
>
>
>immediate="true" value="#{dateTestBean.time}" title="HH:mm:ss"
> id="timeUpStartTimeInput">
>
>
>
>
>
> action="#{dateTestBean.displayDateAction}"/>
>
> When I submit the page, I see different values for the date and time
> depending on whether or not I'm using the trinidad rendering kit.
> When the page loads the date and time fields are set to the correct "date"
> and "time" values. When the page is submitted, I see the following:
> Under MyFaces 1.1.4 (or JSF 1.1), Java 1.5, tomahawk 1.1.3 and assuming the
> date was 12:20:32 on Aug 4th 2009, I get:
> date = '2009-08-04 00:00:00'
> time= '1970-01-01 12:20:32'
> Similarly, under MyFaces 1.2.6 (or JSF 1.2), Java 1.5, tomahawk 12-1.1.8 and
> assuming the date was 12:20:32 on Aug 4th 2009, I get:
> date = '2009-08-04 00:00:00'
> time= '1970-01-01 12:20:32'
> So if I combine the two values when the page is submitted, I end up with
> '2009-08-04 12:20:32', which is the correct submit date/time.
> Under MyFaces 1.2.6 (or JSF 1.2), Java 1.5, trinidad-1.2.10, and assuming the
> same date/time values are set, I get:
> date= '2009-08-04 12:20:32'
> time= '1970-01-01 12:20:32'
> So the convertDateTime with type="date" is not zero-ing out the time field
> values, but the one with type="time" is zero-ing out the date field values.
> I've done a lot of testing and originally thought the problem with with
> myFaces 1.2. But I eventually discovered that the problem occurs if I
> include the following in the faces-confg.xml regardless of whether or not I
> have any trinidad components in the page:
>
> org.apache.myfaces.trinidad.core
>
> This inclusion in the faces-config.xml also requires me to include the
> trinidad-1.2.10 libraries in my web app.
> Including these two items leads to the errant behavior of the convertDateTime
> with type="date" not zero-ing out the time fields of the date.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1407) DateTimeConverter doesn't convert correctly as per the expectedDataType
[ https://issues.apache.org/jira/browse/TRINIDAD-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Agam Dass updated TRINIDAD-1407: Status: Patch Available (was: Reopened) > DateTimeConverter doesn't convert correctly as per the expectedDataType > --- > > Key: TRINIDAD-1407 > URL: https://issues.apache.org/jira/browse/TRINIDAD-1407 > Project: MyFaces Trinidad > Issue Type: Bug >Affects Versions: 1.2.10-core >Reporter: Agam Dass >Assignee: Matthias Weßendorf >Priority: Blocker > Fix For: 1.2.12-core > > Attachments: conversion.patch > > > In the > org.apache.myfaces.trinidadinternal.convert.DateTimeConverter#getAsObject() > retrieves the date by parsing the String and then it calls > DateTimeConverter.__typeConvert() to convert this type to the expected type. > But in the method __typeConvert() it gets the expectedType by calling the > type instead of getting the expectedType(). > So it should be changed to expression.getExpectedType() instead of > expression.getType() > Class : org.apache.myfaces.trinidadinternal.convert.DateTimeConverter > Method : >static Object __typeConvert(FacesContext context, Converter converter, > UIComponent component, > String strValue, Object > value) > Line # 123 > Remove : Class expectedType = > expression.getType(context.getELContext()); > Add : Class expectedType = expression.getExpectedType(); > === > This need to be fixed in Trinidad 1.2.10.1 and then forward-port to Trinidad > 1.2.11.1. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1407) DateTimeConverter doesn't convert correctly as per the expectedDataType
[ https://issues.apache.org/jira/browse/TRINIDAD-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Agam Dass updated TRINIDAD-1407: Status: Patch Available (was: Open) > DateTimeConverter doesn't convert correctly as per the expectedDataType > --- > > Key: TRINIDAD-1407 > URL: https://issues.apache.org/jira/browse/TRINIDAD-1407 > Project: MyFaces Trinidad > Issue Type: Bug >Affects Versions: 1.2.10-core >Reporter: Agam Dass >Priority: Blocker > > In the > org.apache.myfaces.trinidadinternal.convert.DateTimeConverter#getAsObject() > retrieves the date by parsing the String and then it calls > DateTimeConverter.__typeConvert() to convert this type to the expected type. > But in the method __typeConvert() it gets the expectedType by calling the > type instead of getting the expectedType(). > So it should be changed to expression.getExpectedType() instead of > expression.getType() > Class : org.apache.myfaces.trinidadinternal.convert.DateTimeConverter > Method : >static Object __typeConvert(FacesContext context, Converter converter, > UIComponent component, > String strValue, Object > value) > Line # 123 > Remove : Class expectedType = > expression.getType(context.getELContext()); > Add : Class expectedType = expression.getExpectedType(); > === > This need to be fixed in Trinidad 1.2.10.1 and then forward-port to Trinidad > 1.2.11.1. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (TRINIDAD-1407) DateTimeConverter doesn't convert correctly as per the expectedDataType
[ https://issues.apache.org/jira/browse/TRINIDAD-1407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12675298#action_12675298 ] agdass edited comment on TRINIDAD-1407 at 2/20/09 1:43 AM: -- Change should be made to Trinidad 1.2.10.1 and then forward-port to Trinidad 1.2.11.1. was (Author: agdass): Should be made to Trinidad 1.2.10.1 and then forward-port to Trinidad 1.2.11.1. > DateTimeConverter doesn't convert correctly as per the expectedDataType > --- > > Key: TRINIDAD-1407 > URL: https://issues.apache.org/jira/browse/TRINIDAD-1407 > Project: MyFaces Trinidad > Issue Type: Bug >Affects Versions: 1.2.10-core >Reporter: Agam Dass >Priority: Blocker > Fix For: 1.2.10-sandbox > > > In the > org.apache.myfaces.trinidadinternal.convert.DateTimeConverter#getAsObject() > retrieves the date by parsing the String and then it calls > DateTimeConverter.__typeConvert() to convert this type to the expected type. > But in the method __typeConvert() it gets the expectedType by calling the > type instead of getting the expectedType(). > So it should be changed to expression.getExpectedType() instead of > expression.getType() > Class : org.apache.myfaces.trinidadinternal.convert.DateTimeConverter > Method : >static Object __typeConvert(FacesContext context, Converter converter, > UIComponent component, > String strValue, Object > value) > Line # 123 > Remove : Class expectedType = > expression.getType(context.getELContext()); > Add : Class expectedType = expression.getExpectedType(); > === > This need to be fixed in Trinidad 1.2.10.1 and then forward-port to Trinidad > 1.2.11.1. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1407) DateTimeConverter doesn't convert correctly as per the expectedDataType
DateTimeConverter doesn't convert correctly as per the expectedDataType --- Key: TRINIDAD-1407 URL: https://issues.apache.org/jira/browse/TRINIDAD-1407 Project: MyFaces Trinidad Issue Type: Bug Reporter: Agam Dass Priority: Blocker In the org.apache.myfaces.trinidadinternal.convert.DateTimeConverter#getAsObject() retrieves the date by parsing the String and then it calls DateTimeConverter.__typeConvert() to convert this type to the expected type. But in the method __typeConvert() it gets the expectedType by calling the type instead of getting the expectedType(). So it should be changed to expression.getExpectedType() instead of expression.getType() Class : org.apache.myfaces.trinidadinternal.convert.DateTimeConverter Method : static Object __typeConvert(FacesContext context, Converter converter, UIComponent component, String strValue, Object value) Line # 123 Remove : Class expectedType = expression.getType(context.getELContext()); Add : Class expectedType = expression.getExpectedType(); === This need to be fixed in Trinidad 1.2.10.1 and then forward-port to Trinidad 1.2.11.1. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1218) children of tr:commandNavigationItem within a tr:navigationPane don't get rendered
[ https://issues.apache.org/jira/browse/TRINIDAD-1218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12658829#action_12658829 ] Agam Dass commented on TRINIDAD-1218: - Could you please attach just the snippet of the jsp tag code you are using and explain your usecase where you need multiple action listener. I know usecases where I can register a single actionListener and can support multiple cases for different outcome in that listener. > children of tr:commandNavigationItem within a tr:navigationPane don't get > rendered > -- > > Key: TRINIDAD-1218 > URL: https://issues.apache.org/jira/browse/TRINIDAD-1218 > Project: MyFaces Trinidad > Issue Type: Bug > Components: Components >Affects Versions: 1.0.9-core, 1.2.9-core >Reporter: Gerhard Petracek > > children of tr:commandNavigationItem within a tr:navigationPane don't get > rendered, if e.g. hint="tabs" is used > (possible child: e.g. an action-listener) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1218) children of tr:commandNavigationItem within a tr:navigationPane don't get rendered
[ https://issues.apache.org/jira/browse/TRINIDAD-1218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12655540#action_12655540 ] Agam Dass commented on TRINIDAD-1218: - You can define the actionListener in the tag itself as below :- > children of tr:commandNavigationItem within a tr:navigationPane don't get > rendered > -- > > Key: TRINIDAD-1218 > URL: https://issues.apache.org/jira/browse/TRINIDAD-1218 > Project: MyFaces Trinidad > Issue Type: Bug > Components: Components >Affects Versions: 1.0.9-core, 1.2.9-core >Reporter: Gerhard Petracek > > children of tr:commandNavigationItem within a tr:navigationPane don't get > rendered, if e.g. hint="tabs" is used > (possible child: e.g. an action-listener) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1218) children of tr:commandNavigationItem within a tr:navigationPane don't get rendered
[ https://issues.apache.org/jira/browse/TRINIDAD-1218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12655538#action_12655538 ] Agam Dass commented on TRINIDAD-1218: - Could you please explain the problem and copy the jsp tag source which you are using for this. > children of tr:commandNavigationItem within a tr:navigationPane don't get > rendered > -- > > Key: TRINIDAD-1218 > URL: https://issues.apache.org/jira/browse/TRINIDAD-1218 > Project: MyFaces Trinidad > Issue Type: Bug > Components: Components >Affects Versions: 1.0.9-core, 1.2.9-core >Reporter: Gerhard Petracek > > children of tr:commandNavigationItem within a tr:navigationPane don't get > rendered, if e.g. hint="tabs" is used > (possible child: e.g. an action-listener) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1265) safari:buttons in navigation pane display only vertically
safari:buttons in navigation pane display only vertically - Key: TRINIDAD-1265 URL: https://issues.apache.org/jira/browse/TRINIDAD-1265 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.9-core Environment: Windows and linux Reporter: Agam Dass Priority: Minor Problem --- Safari: commandNavigationItems are always displayed vertically when placed inside a NavigationPane The same buttons are displayed horizontally in FIrefox To Reproduce 1. use the foll in the page 2. Run the page and note the items are displayed vertically -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1265) safari:buttons in navigation pane display only vertically
[ https://issues.apache.org/jira/browse/TRINIDAD-1265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Agam Dass updated TRINIDAD-1265: Status: Patch Available (was: Open) > safari:buttons in navigation pane display only vertically > - > > Key: TRINIDAD-1265 > URL: https://issues.apache.org/jira/browse/TRINIDAD-1265 > Project: MyFaces Trinidad > Issue Type: Bug > Components: Components >Affects Versions: 1.2.9-core > Environment: Windows and linux >Reporter: Agam Dass >Priority: Minor > > Problem > --- > Safari: commandNavigationItems are always displayed vertically when placed > inside a NavigationPane > The same buttons are displayed horizontally in FIrefox > To Reproduce > > 1. use the foll in the page > > > > > > > > > > > > > > > 2. Run the page and note the items are displayed vertically -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
